Is Your Web App Vulnerable to Memory Scraping?

If you or your customers became infected with malware, could your web application data be stolen through a memory scraping attack?

The following video was released by Jamieson O'Reilly showing proof of concept malware that successfully scrapes memory to capture the username and password of a number of Australian financial institutions.

http://www.youtube.com/watch?v=8W9O0ISbj7o

Many people may be wondering, is my bank vulnerable? That isn't the question you should be asking.

If you look at the bigger picture, this isn't limited to financial institutions. It demonstrates an attack that can be used on nearly all web applications on the Internet.

So the two bigger questions would be;

- "Are the web applications in my company vulnerable to memory scraping?", and
- "What data is able to be scraped?"

The executive summary would be that the short answer is almost certainly "Yes, your web applications are vulnerable". The types of data that can be stolen may include usernames, passwords, credit card details, bank account details, tax information, customer data, client data ... come to think of it, pretty much any type of data that your web application handles.

For the more technical audience, how about I show you how to identify if your web application is leaking sensitive data in memory.

To start with, you need a web browser (I am going to use Firefox), and a tool that can search memory (I am going to use OllyDbg). I am going to test this out on our "Threat Analytics" login page.

Step 1: Launch Firefox and go to the login page (http://www.threat-analytics.com). Don't login yet.



Step 2: Download and extract OllyDbg from http://www.ollydbg.de/odbg201h.zip

Step 3: Run OllyDbg by double-clicking on ollydbg.exe

Step 4: Attach OllyDbg to the Firefox process via the main menu, select "File -> Attach". This will open up a window listing the processes on the machine. Locate the "firefox.exe" process, and double click.



This may take a few minutes as OllyDbg analyses the process and the DLLs that it uses.

Step 5: Once it finishes, Firefox will be frozen since OllyDbg has "paused" Firefox. We need to hit the run button so Firefox comes to life again. You may need to hit run a few times to get past any break points that are triggered.



Step 6: Now, enter in your username and password into the login form, and hit enter. They don't have to be valid authentication credentials. This puts the username and password into memory (assuming your application is vulnerable).



Step 7: Lets search memory for our password. In OllyDbg click the "M" button that launches the "Memory Map".



Step 8: Right-click on the Memory Map window and select "Search". In the ASCII field, type in the password you want to search for.



If you hit a memory location that you don't have permissions to read, then tap down and hit "Ctrl-L" to search for the next instance.

Step 9: Once the password has been found, OllyDbg will launch a new window containing your password in memory. This is demonstrated below where the password is displayed in clear-text.



If you were unable to locate your password in memory, and you are sure that you did it correctly, then you may be safe. Well, for the login page that is. If you then enter into your application and type further details in, such as your credit card, bank details, email address, etc, then i'm certain that you will be able to locate these details in memory.

As I mentioned earlier, I would say about 99.999% of web applications on the Internet suffer from this flaw on their login pages, and the rest suffer from the flaw once you are past the authentication controls.

Memory scraping isn't a new technique, and there is active malware such as Dexter that is scraping credit card details from memory. The proof of concept malware in the video does bring up a valid case where sensitive data should have additional security controls put in place to minimize the risk of malware stealing your data.

One technique to prevent this flaw is to use JavaScript encryption on your data as it is entered. This ensures that your data is encrypted in memory as well as across the wire.

Again, this isn't foolproof but it does add another round of hurdles that may just make attackers move onto the next site and leave you alone.