Category Archives: 6394

Apple to iPhone Users: Please Install This Untrusted Configuration Profile

It appears Apple is the only company around that doesn't use Microsoft Exchange. Apple's recently released iOS (not to be confused with Cisco's IOS) 4 apparently wasn't tested with Exchange at all. Many users are reporting slow e-mail sync, and apparently Exchange server admins are none too happy with the load these devices are putting on the Exchange server – much more than the old OS did.

Of course, you cannot downgrade a device that has been upgraded to iOS 4. iPhone Operating Systems are signed by Apple at run-time and Apple refuses to digitally sign anything below iOS 4 now, so if you upgrade your device, you are stuck, unless you are willing to jailbreak your device, and right now, you can't jailbreak an iOS 4 device that was not jailbroken prior to the upgrade.

That leaves you with Apple's solution: a configuration profile that modifies the settings on your device.

Unfortunately, the configuration profile is unsigned. Configuration profiles make critical changes to how your device operates. Therefore, Apple supports signing them so their source can be authenticated. Too bad Apple doesn't bother with this itself. Rather, Apple's recommendation appears to be that users download and install random unsigned configuration profiles found on the Internet.

Don’t fire people until after you wipe their phones

A very commonly required feature for mobile access to email is remote wipe – the ability to reach out and wipe all corporate data off a mobile device. Exchange ActiveSync supports this feature and has for several versions now. You, as the Exchange or Security administrator can issue a remote wipe command to a compliant device, or the user can do it themselves through Exchange, and the next time the user connects the device will be wiped.

There are two major flaws in that design. One is the well understood "the next time the user connects" part: you cannot reach out to the device and immediately wipe it. The devices do support receiving remote commands through SMS, but for some reason there is no function in Exchange to use that feature to somehow, securely, trigger a remote wipe.

It turns out, however, that there is another, possibly even larger, flaw in the implementation of remote wiping in Exchange ActiveSync. Here is the work flow:

  1. Device connects to Exchange Server
  2. Device transmits DeviceID
  3. Exchange server asks for authentication
  4. Device authenticates
  5. Exchange server checks if a remote wipe command has been issued for the device

Spot the flaw yet? Consider this scenario

  1. Bob failed to sufficiently internalize the sexual harassment training and racks up enough points to get fired
  2. Bob is walked to the door with his shiny personal Windows Phone 7 Smartphone or whatever in his pocket
  3. IT Department is notified that Bob has been terminated and disables/deletes his account
  4. IT Department, following the security policy, issues a remote wipe command to Bob's phone

Pop quiz: What happens to all the company confidential data on Bob's device?

Answer: Nothing! It will stay there for as long as Bob decides it should. Go back and look at the connection workflow again. The Exchange server will only send the remote wipe command to Bob's device after Bob has already authenticated. The IT Department did the absolutely logical thing and disabled Bob's account. Therefore, he will never successfully authenticate again. The way remote wipe is implemented in Exchange ActiveSync means we just lost the ability to wipe our data off Bob's mobile phone.

The alleged solution to this is that you should reverse steps 3 and 4 in your firing process: leave Bob's account active until his device gets wiped. If that makes you just a little queasy you are not alone. In my opinion, this is a major feature miss. Remote wipe in Exchange ActiveSync is only useful when a user loses his or her device, and even then, it is lacking since you cannot reach out to the device and wipe it. Remote wipe in Exchange ActiveSync is utterly useless when people are terminated from their emoloyer.

Passwords are here to stay

At least for the short to medium term. That is the, quite obvious, conclusion drawn in a Newsweek article entitled "Building a Better Password."  The article goes inside the CyLab at Carnegie-Mellon University to understand how passwords may one day be replaced. It is interesting reading all around.

The article is not without some "really?" moments though, such as this quote:

The idea of passphrases isn't new. But no one has ever told you about it, because over the years, complexity—mandating a mix of letters, numbers, and punctuation that AT&T researcher William Cheswick derides as "eye-of-newt, witches'-brew password fascism"—somehow became the sole determinant of password strength.

Actually, I do believe someone did tell you about it. Five years ago now, in fact.

And finally, standard user malware

Today I finally got wind of my first piece of true standard user malware. MS Antispyware 2008 has turned standard user. The version in question installs the binaries in c:\documents and settings\all users\application data\<something>, and makes itself resident by infecting HKCU\…\Run. Curiously, the legitimate anti-malware program (one of the top 3) failed to detect the infector.

Obviously, this version is much easier to remove than the ones that require admin privileges. However, MS Antispyware is not about being hard to remove. It just needs to run until the user pays for the privilege, and more than likely, even as a standard user, many people will fall for it.

On a somewhat unrelated note, just as I was wondering who would fall for these types of scams, I met a real person that did; a not-particularly-well-off disabled retiree who was scammed out of $5000 by an organized crime ring that claims to have won you a lottery, as long as you just pay them for the ticket first. That particular scam was run partially by phone and partially online. And, the scumbags apparently didn’t think they had scammed her out of enough money so they kept calling her even after she sent them the money. I advised her to call Rob McKenna’s office (Attorney General of Washington State). Mr. McKenna’s office stated that they felt horrible for her. Apparently that was about all the comfort they could give. I must say that level of action was not particularly impressive, and does not really live up to Mr. McKenna’s campaign promises of cracking down on scammers.

Please do not e-mail my social security number

Recently I had a very interesting incident. I wrote an article some time in 2008 and the publisher paid me a little bit of money for it. That means the publisher must send a report to the Internal Revenue Service (IRS – the U.S. tax department) reporting that they paid me, as well as send me a form called a 1099 form that I can use to report this money on my tax return.

A few days ago the comptroller for the publisher sent me an e-mail asking for my social security number (my national ID number for any non-Americans that are unfamiliar with the term). As is my custom, I responded that I really do not care to e-mail my social security number, but if he gives me a phone number I will gladly call him and let him know. This he did. I called, and within 15 minutes of the call I received a form California DE 542 in the mail. The DE 542 is required by the state of California when money is paid to a contractor, or a contract is entered into to pay money to a contractor. Its purpose is to permit the state to track payments to parents who do not pay their child support. Not only do I not need this form as I am not a resident of California; it also contains, you guessed it:

my social security number.

At this point I started wondering what part of "I do not wish to have my social security number transmitted by clear-text e-mail" was unclear. I sent a message to the sender that informed him that this could quite possibly be considered a data breach and require notification under Washington State SSB 6043, which requires formal breach notification. As of today, I am still awaiting a response. Any response.

Just because I felt like griping to someone, I forwarded the e-mail to my favorite accountant. Her response was "yeah, I know lots of CPA firms who e-mail around unencrypted 1040s." (A "1040" is the U.S. federal tax return form). I was absolutely floored. Last week credit card processor Heartland reported that they had experienced what may very well be the largest data breach in world history. Many banks are replacing every single one of their credit cards because of it. In fact, I took a call from a distressed bank manager just this morning asking whether it would be prudent to do so (the answer was "yes"). Yet, does that not pale in comparison to the number of unencrypted 1040s e-mailed around by tens of thousands of accountants every year, and the untold millions other tax-related forms that traverse unencrypted network channels?

If you steal my credit card number, I can call the bank and ask them to issue me a new number. A few days later, I have a new card. The bad guy can, at worst, incur a few hundred dollars in charges, maybe a few thousand if they are really lucky. Yet, credit card data is somehow seen as the primary piece of data that needs protection. How many news reports have you read that discuss a computer breach and include the words "no credit card numbers appear to have been compromised?" Have we completely lost sight of the fact that there may be other pieces of information that need protection?

Consider the corollary. If you steal my social security number, you can take over my house, get any number of credit cards in my name, give me a criminal record, get a driver's license in my name… And, how do I clean it up? If I call the Social Security Administration and ask for a new number because my existing number has been compromised they would simply laugh at me. Only in exceptionally rare circumstances do they issue new numbers. In some states I am permitted, if my social security number has been compromised, to put in a credit report freeze, but the burden is on me, as the victim, to prove that my information has been compromised before I can get a freeze. If I am deemed worthy of getting the barn door closed after the horses have fled, I get to pay $30-60, per freeze, per credit bureau, requested by certified mail. And each freeze may only be good for 90 days. That's only in some states. Other states prohibit credit freezes, and a few, more progressive ones, actually permit consumers to close the barn door before the horses run away. The freeze usually still costs money, and usually is still time-limited, and usually still requires that you use certified mail to each credit bureau to request it. Fortunately, you can "thaw" the freeze by making a single phone call and typing in a four-digit pin.

What is wrong with this picture? Why are accountants and comptrollers still e-mailing around the source data – social security numbers; while we as consumers only seem to care about the derived data – the credit card number? Why is there a Payment Card Industry (PCI) Data Security Standard that, while widely ignored, attempts to set data protection standards for cardholder data; but no Social Security Number security standard that establishes requirements for protection of social security numbers and liability for anyone who compromises someone else's Social Security Number?

Why do we not see any Attorney's General up in arms over that one? Who is going to help me protect the source data?

 

Is MS08-067 Wormable?

A couple of weeks ago Microsoft released an out-of-band security update in bulletin MS08-067. Looking at the type of vulnerability and the fact that the issue was already being exploited in the wild at the time, this was a good decision. If you have not already installed this security update, you should stop reading this right now and return after you have installed the update.

The problem fixed in MS08-067 is eerily reminiscent of the vulnerabilities that resulted in the Blaster and Sasser worms. Therefore, for obvious reasons, the question arises whether MS08-067 is wormable or not. Microsoft claimed in various outlets that it was wormable "on older systems." Michael Howard backs that up with some interesting analysis on the SDL blog. The Secure Windows Initiative (SWI) blog also discusses the issue and points to a number of mitigations designed to reduce the "wormability" on newer operating systems. By "older systems" Microsoft really means "not Vista and Server 2008." This leads to the question of why the vulnerability cannot be used to create a worm on Windows Vista and Server 2008, and whether the claim is correct or not.

The claim that MS08-067 cannot be used to create a worm on Vista and Server 2008 is based largely on two defenses used on those operating systems. The first is that the vulnerable end-point is not anonymously accessible on those operating systems. That's a pretty good defense out on the general Internet. However, on a corporate network it provides little defense. Anyone with user-level credentials on a host can exploit the vulnerability. Thus, if a single computer gets infected and then is brought inside the corporate network, it can infect any other computers on the corporate network by authenticating to them. It would take a little more coding to write an exploit that does that, but it is certainly not an impossibility.

The second defense is Address-Space Layout Randomization (ASLR). ASLR causes the addresses used for code in memory to change from execution to execution. Each time you execute a program it will be loaded into a portion of memory; but, under ASLR, that memory is offset at one of 256 possible memory locations. Many exploits rely on knowing where in memory certain structures are. Prior to ASLR those locations were deterministic within an Operating System, Serice Pack, and Patch Level combination. However, under ASLR, they are, as I mentioned, no longer deterministic. This makes exploitation much more difficult.

However, do these defenses, and specifically, ASLR, really make a vulnerability "not wormable?" I would argue that the answer is "we do not know" but that it is tending toward "no." The problem is that we really do not understand the spreading patterns of worms well enough to make a claim one way or the other. Let us take a neutral scientific approach to understanding this claim.

Worms rely on spreading from computer to computer. Each computer that is infected with the worm can infect countless additional computers. The only thing that moderates it is time. The spread, however, is exponential. The more infected computers there are, the more computers there are that can spread the infection. Eventually, some form of critical mass is reached at which point the spread turns uncontrollable. Unfortunately, we do not know where that inflection point is.

To see how this works, let us take a hypothetical worm, and let us assume that ASLR is not used. Let's say the infection takes 1/8th of a second per computer. In other words, if computer A is infected and targets the worm at computer B, 1/8th of a second later, computer B is ready to start infecting computer C. In one second, a single computer, computer A, can spread the infection, directly or indirectly, to 64 other computers. The total impact of the worm is t/r^2, where t is the time and r is the rate of spread measured in the time it takes to infect an additional computer. Using that formula, we can see that after 1 second 64 computers could be infected. After 2 seconds, 256 computers can be infected, and so on.

Now let's apply ASLR to this. Using ASLR, the memory address space is allocated over 256 possible addresses. In other words, under a very tight assumption the infection will fail in all but 1/256 cases. The assumption is that we cannot predict where the locations are, and that the randomization will actually cause the infection to succeed in only one case of 256. Let us just say this assumption holds because it lets us analyze a worst-case scenario for the worm. Under ASLR then, we can consider the rate of spread to be 1/256th that of the non-ASLR worm. In other words, rather than infecting the next computer in 1/8th of a second, computer A can only infect one new computer in 32 seconds. This, obviously, slows down the spread of the worm, but is it enough? The spread is still exponential. It just takes longer to spread. Consider this chart:

This chart maps the number of infected computers over a 24-minute period, assuming there is an infinite number of computers to infect, and ASLR is in use on all of them. It is clear from this graph that the spread is exponential. After 24 seconds, 2,025 computers are infected. By contrast, without ASLR, it would take less than 6 seconds to infect that many computers. The point, however, is that ASLR would not stop a worm, it would only slow it down. What we do not know is whether slowing down a worm is effectively enough to stop it. My inclination would be to say that it is probably not enough unless we can slow it down by many orders of magnitude.

In addition to ASLR, the affected service on Windows Vista and Server 2008 would only restart twice before staying down indefinitely. This is important because unsuccessful exploitation would almost certainly cause the service to crash. However, I do not consider that as a defense against worms, because more than likely, the user would at that point either restart the computer or just the service. Given that the restart behavior would only serve to further slow the spreading rate. It would not change the exponential nature of the spread. Again, we arrive at the same conclusion: none of the defenses make a vulnerability non-wormable. They merely slow the spread down.

This is important because there is a risk that people will avoid patching because a vulnerability is not wormable. Make no mistake, remotely exploitable vulnerabilities are still wormable, and within an hour, you could easily have your entire corporate network infected. As if that weren't bad enough, using a remotely exploitable vulnerability, someone with far worse intentions could take over your computers and use them as an entry point into your network. For that the criminal needs only one computer, not a whole network of them. Wormability, or lack thereof, is irrelevant against a targeted attack, which means that ASLR is essentially irrelevant against a targeted attack. in most cases the attacker needs a computer, not a particular computer. Being able to only gain a foot hold on one computer in 256 is likely to be enough because after the initial entry, the vulnerability plays no further part in the compromise of your network. In other words, do not consider ASLR to be a reason not to patch some particular vulnerability.

Now, do I think we will see a worm for MS08-067? No. Not in the traditional sense of Blaster. The time of worms, like Blaster, that are inherently non-destructive, has passed. At this point, criminals are not interested in simply writing worms that self-replicate. They are interested in one of the three big things: money, ideology, or national supremacy. While we may still see massive worms, they will be fundamentally different than the ones of old, and they will probably take a bit longer to write. The new breed will be more targeted, more silent, more deliberate, and more dangerous. Once the objectives change, so do the attack patterns.

In short, please do not use wormability, or lack thereof, as a decision factor in deciding whether to patch a vulnerability or not. Wormability is an irrelevant and potentially dangerously misleading metric.

Anatomy of a Hack 2008

A few years ago I delivered a very popular presentation I called "Anatomy of a Hack." Well, actually, I called it "How to Get Your Network Hacked in 10 Easy Steps" but the marketing department at my previous employer thought that title was a bit, edgy, so they renamed it. The Chinese called it "Anatomy of a Hacker" at TechEd China in 2005, but that's another story altogether. The presentation, which is actually documented in Protect Your Windows Network, had me wandering through an entire network once I got a foothold on one computer.

For the past couple of years I've been telling people that the future of attacks are against people, not networks. In June I got further confirmation of that. A notification came in from my blog that I had a new comment to approve. The comment was just a link, looking like this one:

 A Comment has been posted to Jesper's Blog: Hey, Mozilla: Quotes Are Not Legal in a URL by Google Images:
images.google-us.info/index.html Google Images

This looked suspicious enough so I started investigating a bit. What I found just hit the net on The Register. I thought it made an interesting tale of how the bad guys are trying to monetize their handiwork. Sandi has also written about this on her blog here, and here, and here

On a very much related note,  I will actually do a live walkthrough of this type of attack at TechEd EMEA ITPro in Barcelona this coming November. Yes, that's right, I'm going back to TechEd. Hope to see you there!

Buy the original Olympic Torch from Beijing

"Buy the original Olympic Torch from Beijing"

That was one of the fake headlines in the latest "CNN.com Daily Top 10" malware spam I've been getting lately. This particular spam is a fake newsfeed which redirects you to one of many sites. All the sites have the same thing in common: they are designed to trick you into installing fake anti-malware software.

I sent some screenshots I took to Sandi, and she wrote up a nice warning about it.

Phishing for a Tax Refund

What's wrong with this picture?

If you answered "why would the IRS use a web server in Korea to ask for information about my tax refund" you are a winner!

This is a phishing site preying on people who do not know that all you need to do to get your tax rebate is to file a tax return this year. Apparently, this is the hot new phishing scam, and the IRS has instructions for how to handle it.

The e-mail came in at 21:07 PDT today. By 21:30 PDT it was not recognized as a phishing site by either Internet Explorer or Firefox. By 21:35 Firefox had it marked. Impressive. By 21:40 IE did not have it marked, which I found interesting.

Mitigate the Image Uploader Vulnerabilities

The big security news this week is the six vulnerabilities found in various image uploader ActiveX controls. In case you haven't seen the news, there are exploits available publicly for remote vulnerabilities in five different ActiveX controls. US-CERT is offering the, relatively unhelpful, advice that users disable all ActiveX controls in their browser. Doing so would have the effect of disabling a lot of things, notably virtually every corporate expense reporting application. Your users will probably have a thing or two to say about that. You can mitigate that by adding all the sites users will ever need to the Trusted Sites zone, but if you haven't done that in the 10 years or so that you have had the option, you probably will not do it now.

That means you, like me, are probably looking for other options. Tom Liston, of SANS/IntelGuardians, created an application to set the kill bit on the affected controls. It is a nice little tool. However, his tool is local only, the source is not available, it is not digitally signed but instead uses an MD5 signature for source verification (standard on Linux, but not on Windows), and it uses a non-standard way of defining the control.

Another way to handle the problem, which is more scalable to an enterprise environment, is to dust off the old SlayOCX vbscript that I wrote for the VML vulnerability about 18 months ago. We can tie that into a logon script, and then link the logon script to a GPO. That will effectively disable the controls on all managed systems. First, we need a custom script with all the ActiveX controls enumerated:

<begin script>

REM Facebook
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 5C6698D9-7BE4-4122-8EC5-291D84DBD4A0 -l

REM Yahoo MediaGrid
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 22FD7C0A-850C-4A53-9821-0B0915C96139 -l

REM Yahoo DataGrid
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 5F810AFC-BB5F-4416-BE63-E01DD117BD6C -l

REM Aurigma controls from http://www.kb.cert.org/vuls/id/776931
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 104B0A37-AB99-4F06-8032-8BBDC3B77DDB -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 17D667BA-5675-4AAB-9221-08B9379384D4 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 48DD0448-9209-4F81-9F6D-D83562940134 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 55027008-315F-4F45-BBC3-8BE119764741 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k 6E5E167B-1566-4316-B27F-0DDAB3484CF7 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k A18962F6-E6ED-40B1-97C9-1FB36F38BFA8 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k AE2B937E-EA7D-4A8D-888C-B68D7F72A3C4 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k AE6C4705-0F11-4ACB-BDD4-37F138BEF289 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k B85537E9-2D9C-400A-BC92-B04F4D9FF17D -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k BA162249-F2C5-4851-8ADC-FC58CB424243 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k D1D98C0F-A339-42AB-BD5F-EA0FF5D0E65F -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k D1EA8D3D-F511-4388-B754-4A0CC14A4778 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k F1F51698-7B63-4394-8743-1F4CF1853DE1 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k F89EF74A-956B-4BD3-A066-4F23DF891982 -l
\\<your domain>\sysvol\<your domain>\SlayOCX.vbs -k FB90BA05-66E6-4c56-BCD3-D65B0F7EBA39 -l

</end script>

 Next, we can follow the directions in the original post to configure a logon script:

  1. Copy the script above (everything between the begin and end tags) and paste it into a new text document. Save the document as "NoPicturesPlease.cmd". Alternatively, just download and expand the SlayOCX_v1.zip file attached to this post.
  2. Open NoPicturesPlease.cmd in Notepad, hit CTRL+H and do a global find replace on "<your domain>" with the name of your domain.
  3. Copy the NoPicturesPlease.cmd file and SlayOCX.vbs to \\<your domain>\sysvol\<your domain>\scripts. where you replace "<your domain>" with the full DNS name of your domain.
  4. Open the GPMC (if you do not have the GrouIndifferentp Policy Management Console, you need to get it. Strictly speaking you can manage GPOs without it, but you really don't want to)
  5. Right-click the domain or OU where you want to link the GPO – you may as well do it at the domain level – and select "Create and Link a GPO Here…" Name your new GPO "NoPicturesPlease"
  6. Right-click the GPO NoPicturesPlease and select "Edit…"
  7. Expand "Computer Configuration:Windows Settings" and click on "Scripts (Startup/Shutdown).
  8. Double-click "Startup" in the right-hand pane
  9. Click "Add…"
  10. Browse to \\<your domain>\sysvol\<your domain>\scripts and select "NoPicturesPlease.cmd". Click "Open"
  11. Click "OK" again.
  12. Close the GPO editor and go back to the GPMC
  13. In the "Security Filtering" pane remove "Authenticated Users" and click Add…
  14. In the text box called "Enter the object name…" type "Domain Computers" or some other relevant group that you want to apply the policy to. Click OK.

When the computers next restart they will automatically apply the mitigation and kill bit all the relevant ActiveX controls. If any given ActiveX control does not exist on a particular computer nothing will be done to it. The script will also create a log file in the root of the boot volume, called "SlayOCX.log". By monitoring that log file you can tell how much the mitigation has modified the computers as well. If it finds any of the ActiveX controls you also have a good indication that people are surfing social networking sites at work, just in case you worry about such things.

If you want to ever undo the mitigation you can modify NoPicturesPlease.cmd to use the -r switch instead of the -k switch.