Microsoft

Blog Categories

Subscribe to RSS feed

Archives

Facing Social Malware in a Collaborative World

If you missed the recent story in the New York Times about the compromise of over 1,000 computers affiliated with the Office of His Holiness the Dalai Lama (OHHDL), read it. Or better yet, read the report published by the University of Cambridge Computer Laboratory. I promise you it will be one of the best spent (and perhaps scariest) 30 minutes of your week.

After reading this, one can surmise that social malware represents the future of computer-based crime. If you’ve been paying attention to the way attacks have been evolving over the last couple of years, I don’t think this comes as much of a surprise. The security community is working to address this threat. In fact, the primary theme of this year’s ChicagoCon is social engineering. In any event, here are some of my thoughts after reading the report, taken from a corporate, Microsoft-centric perspective:

If you operate your computer as a local administrator, you’re crazy

This fact has been well established in the Unix / Linux realm for a long time, but Windows users, even the best of us, still hold on to naive assumptions about the computers we operate. The attack vector in this case involved fooling users into clicking (and thereby installing) email attachments that looked like documents but turned out to be a sophisticated rootkit. Its common for Windows XP users to have local administrative access to their computers because "it’s just easier that way" given all the legacy applications that "require" full administrative access to even run. This model is no longer tenable. In this day and age, even surfing the ‘net this way == Game Over.

User Account Control (UAC) in Windows Vista provides a foundation to help address this situation. I don’t have time to get into the mechanics of the underlying security model here, but I will say that with UAC two important things change:

  • When you log in with an account that is a member of the local Administrators group, two tokens are generated: a standard token with only basic rights and an administrative token with administrative rights. The entire user environment is loaded with the standard token. Any process that needs to execute under an administrative context requires consent.
  • User Interface Process Isolation is enabled. Windows Vista implements Mandatory Integrity Controls, which enables things like Internet Explorer Protected Mode to function (IEPM). This case involved an email-based attack vectors. But web-based attacks are already common today.

If these users were running Windows Vista with User Account Control (UAC) enabled, they would have been alerted that their action requires administrative privileges when clicking that email attachment. Yes, I realize UAC can be annoying, and Windows 7 will include changes to improve it, but its benefits far outweigh the drawbacks. For starters, it offers the user a chance to make a decision….and when given a bit of basic security training, he would have had a good chance of making the correct decision. In addition, any future attempts for malware to run in elevated mode would also prompt the user to approve the elevation.

Companies skipped out on Vista due to all the negative press, deserved or not, that it received from the technical community. Plus, it came with a high price tag in terms of deployment costs, compatibility, user training, and hardware requirements. Microsoft has learned and I’m confident Windows 7 will offer no such excuses. UAC is certainly no silver bullet, but it does provide the infrastructure for mitigating and potentially thwarting malware attacks such as this. Like it or not, the reality is that desktop modernization is going to need to happen in order for organizations to have any chance of protecting their data.

An email server is a [BLEEP]ing valuable thing!

I could help but notice this event comes on the heels of the 10th anniversary of the Melissa virus, the granddaddy of all email-based attacks. Ahhh, email. Based on 1982 technology. Simple. Reliable. Taken for granted. Relegated to the status of a "utility services". Prone to outsourcing.

In the Microsoft world, it used to be that "email security" involved protecting your mail servers from becoming email relays and getting yourself blacklisted, turning off POP3, and trying to lock down Outlook. Then it evolved to fighting SPAM and implementing Sender Policy Framework (SPF). I really think its high time for folks to take a timeout to seriously evaluate availability and access control to mailboxes. Think about it: mail servers contain all the deepest, darkest secrets of your organization. It contains your organization’s style. Its substance. Access to email provides a malicious entity everything needed to socially engineer his way into your network. And then some. I was particularly struck by this quote from the report:

"An interesting and very effective twist was that the attackers did not just use the social information they gained from their initial attack to send plausible phish. They also stole mail in transit and replaced the attachments with toxic ones. Figure 1 shows an email whose body was stolen from the mailbox of a user and then used to construct the attack by attaching a malicious payload."

So a compromised mailbox can be a perfect source for corporate identity theft. Corporations need to start protecting their email as the strategic asset it is. A good place to start would be to evaluate how remote access is achieved. Restricting access to only trusted computers (in the strictest of terms) should be end-goal here. Obviously, all connections should be encrypted and strong password policies should be strictly observed. Secondly, access to email really does need to be logged and periodically audited. By the way, this goes double for mail-enabled smart phones.

We need a better means to establish trust and identity

In the corporate world nowadays, folks are expected to be able to collaborate anywhere at any time, often with entities outside of the immediate company. We’re supposed to blog, post on message boards, use Twitter, etc. We’re supposed to reach out. Make connections. However, this kind of "social networking" causes us to disclose things about ourselves and our work that we may not normally want or intend to disclose. After a while, one can become careless about this sort of thing. We start to believe anything we see on the screen and assume what we read in blogs and in our inboxes to be true. Its in our nature (and perhaps the "corporate DNA") to trust and be helpful.

Social networking and collaboration are great and positive things and these concepts are here to stay. But we need to build in a healthy degree of skepticism into our collaboration tools. For example, I would like to see Outlook / Exchange functionality that classifies email from authenticated users as an "authenticated message". Would this protect an organization from social engineered messages sent from a fully compromised computer with full access to a mailbox? No. But it would at least help protect against garden variety phishing and spoofing attacks that impersonate an employee. K
eeping with email as an example, organizations can further protect themselves by implementing digital signature technologies like S/MIME with private keys stored on a physical token like a smart card. Again, Windows Vista has broken down a lot of barriers in this department. S/MIME is a nice example because it provides a clear sign (through an easy to see icon with certificate validation) that a message was indeed sent from a legitimate user and not an anonymous connection from the Internet. I’m not saying S/MIME is the only road to solve "the email problem", but I do think email needs to evolve and implement some kind of trust model.

I could go on and on here, but that point I want to make is that we need to teach users to exercise a reasonable level of doubt about communications with external parties. And users need tools to help them better distinguish between information coming from a trusted connection verses other sources. And trusted connections better be trustworthy.

Anyhow, folks at Microsoft are working very hard to re-shape and reform the mechanisms of online identity. They’re integrating with technologies like OpenID to help make things like claims-based authentication a reality for both the Microsoft platform and others. Collaboration tools are going to have to evolve along these lines.

Leave a Reply

Facing Social Malware in a Collaborative World

If you missed the recent story in the New York Times about the compromise of over 1,000 computers affiliated with the Office of His Holiness the Dalai Lama (OHHDL), read it. Or better yet, read the report published by the University of Cambridge Computer Laboratory. I promise you it will be one of the best spent (and perhaps scariest) 30 minutes of your week.

After reading this, one can surmise that social malware represents the future of computer-based crime. If you’ve been paying attention to the way attacks have been evolving over the last couple of years, I don’t think this comes as much of a surprise. The security community is working to address this threat. In fact, the primary theme of this year’s ChicagoCon is social engineering. In any event, here are some of my thoughts after reading the report, taken from a corporate, Microsoft-centric perspective:

If you operate your computer as a local administrator, you’re crazy

This fact has been well established in the Unix / Linux realm for a long time, but Windows users, even the best of us, still hold on to naive assumptions about the computers we operate. The attack vector in this case involved fooling users into clicking (and thereby installing) email attachments that looked like documents but turned out to be a sophisticated rootkit. Its common for Windows XP users to have local administrative access to their computers because "it’s just easier that way" given all the legacy applications that "require" full administrative access to even run. This model is no longer tenable. In this day and age, even surfing the ‘net this way == Game Over.

User Account Control (UAC) in Windows Vista provides a foundation to help address this situation. I don’t have time to get into the mechanics of the underlying security model here, but I will say that with UAC two important things change:

  • When you log in with an account that is a member of the local Administrators group, two tokens are generated: a standard token with only basic rights and an administrative token with administrative rights. The entire user environment is loaded with the standard token. Any process that needs to execute under an administrative context requires consent.
  • User Interface Process Isolation is enabled. Windows Vista implements Mandatory Integrity Controls, which enables things like Internet Explorer Protected Mode to function (IEPM). This case involved an email-based attack vectors. But web-based attacks are already common today.

If these users were running Windows Vista with User Account Control (UAC) enabled, they would have been alerted that their action requires administrative privileges when clicking that email attachment. Yes, I realize UAC can be annoying, and Windows 7 will include changes to improve it, but its benefits far outweigh the drawbacks. For starters, it offers the user a chance to make a decision….and when given a bit of basic security training, he would have had a good chance of making the correct decision. In addition, any future attempts for malware to run in elevated mode would also prompt the user to approve the elevation.

Companies skipped out on Vista due to all the negative press, deserved or not, that it received from the technical community. Plus, it came with a high price tag in terms of deployment costs, compatibility, user training, and hardware requirements. Microsoft has learned and I’m confident Windows 7 will offer no such excuses. UAC is certainly no silver bullet, but it does provide the infrastructure for mitigating and potentially thwarting malware attacks such as this. Like it or not, the reality is that desktop modernization is going to need to happen in order for organizations to have any chance of protecting their data.

An email server is a [BLEEP]ing valuable thing!

I could help but notice this event comes on the heels of the 10th anniversary of the Melissa virus, the granddaddy of all email-based attacks. Ahhh, email. Based on 1982 technology. Simple. Reliable. Taken for granted. Relegated to the status of a "utility services". Prone to outsourcing.

In the Microsoft world, it used to be that "email security" involved protecting your mail servers from becoming email relays and getting yourself blacklisted, turning off POP3, and trying to lock down Outlook. Then it evolved to fighting SPAM and implementing Sender Policy Framework (SPF). I really think its high time for folks to take a timeout to seriously evaluate availability and access control to mailboxes. Think about it: mail servers contain all the deepest, darkest secrets of your organization. It contains your organization’s style. Its substance. Access to email provides a malicious entity everything needed to socially engineer his way into your network. And then some. I was particularly struck by this quote from the report:

"An interesting and very effective twist was that the attackers did not just use the social information they gained from their initial attack to send plausible phish. They also stole mail in transit and replaced the attachments with toxic ones. Figure 1 shows an email whose body was stolen from the mailbox of a user and then used to construct the attack by attaching a malicious payload."

So a compromised mailbox can be a perfect source for corporate identity theft. Corporations need to start protecting their email as the strategic asset it is. A good place to start would be to evaluate how remote access is achieved. Restricting access to only trusted computers (in the strictest of terms) should be end-goal here. Obviously, all connections should be encrypted and strong password policies should be strictly observed. Secondly, access to email really does need to be logged and periodically audited. By the way, this goes double for mail-enabled smart phones.

We need a better means to establish trust and identity

In the corporate world nowadays, folks are expected to be able to collaborate anywhere at any time, often with entities outside of the immediate company. We’re supposed to blog, post on message boards, use Twitter, etc. We’re supposed to reach out. Make connections. However, this kind of "social networking" causes us to disclose things about ourselves and our work that we may not normally want or intend to disclose. After a while, one can become careless about this sort of thing. We start to believe anything we see on the screen and assume what we read in blogs and in our inboxes to be true. Its in our nature (and perhaps the "corporate DNA") to trust and be helpful.

Social networking and collaboration are great and positive things and these concepts are here to stay. But we need to build in a healthy degree of skepticism into our collaboration tools. For example, I would like to see Outlook / Exchange functionality that classifies email from authenticated users as an "authenticated message". Would this protect an organization from social engineered messages sent from a fully compromised computer with full access to a mailbox? No. But it would at least help protect against garden variety phishing and spoofing attacks that impersonate an employee. K
eeping with email as an example, organizations can further protect themselves by implementing digital signature technologies like S/MIME with private keys stored on a physical token like a smart card. Again, Windows Vista has broken down a lot of barriers in this department. S/MIME is a nice example because it provides a clear sign (through an easy to see icon with certificate validation) that a message was indeed sent from a legitimate user and not an anonymous connection from the Internet. I’m not saying S/MIME is the only road to solve "the email problem", but I do think email needs to evolve and implement some kind of trust model.

I could go on and on here, but that point I want to make is that we need to teach users to exercise a reasonable level of doubt about communications with external parties. And users need tools to help them better distinguish between information coming from a trusted connection verses other sources. And trusted connections better be trustworthy.

Anyhow, folks at Microsoft are working very hard to re-shape and reform the mechanisms of online identity. They’re integrating with technologies like OpenID to help make things like claims-based authentication a reality for both the Microsoft platform and others. Collaboration tools are going to have to evolve along these lines.

Leave a Reply