Introducing ZAP

Access ZAP - http://zap.zscaler.com

View a video walkthrough for ZAP

ZAP Home Page

After many months of hard work by the ThreatLabZ Team, I'm very pleased to unveil ZAP (Zscaler Application Profiler). ZAP makes it easy for anyone to determine the risk posed by a given mobile application. Users can do this by either looking up past results, or more importantly, proactively scan any iOS/Android app.

Why did we build ZAP? Being a inline security solution inspecting web traffic, it's imperative that we're able to not only analyze traditional web traffic, but also web traffic sent by mobile applications. While we think of mobile apps as native software, in many ways they behave like custom web browsers, leveraging HTTP(S) for communication. We therefore started building ZAP as an internal resource to analyze mobile app traffic, but quickly realized that people are all too trusting of mobile apps downloaded from an 'official' app store. Leveraging ZAP, our research has shown that apps commonly expose privacy and security risks from sending passwords in clear text to sharing personally identifiable information (PII) with third parties and that's why we're also releasing a public version of ZAP - to empower people to see this for themselves.

Search

The easiest way to leverage ZAP is to search through the historical results. Simply by typing the name of a mobile application in the search field, you can see if it has previously been analyzed. To further refine your search, you can additionally include the OS name (iOS or Android).

Sample ZAP Search Results

In the sample results above, you'll note that the application receives an overall score out of 100 with high numbers representing a greater security/privacy risk. Detail is also provided on the following four categories which influence the overall score:

• Authentication - Username/password information sent in clear text or using weak encoding methods
• Device Metadata Leakage - Transmission of device information such as the UDID (Unique Device Identifier), MAC address or details about the operating system
• PII Leakage - Sharing personally identifiable information such as phone numbers, email addresses, mailing addresses, etc.
• Exposed content - Communication with third parties such as advertisers and analytic firms

Scan

The true power of ZAP comes from it's ability to empower anyone to capture and analyze the web traffic from a mobile application. In order to accomplish this, we leveraged an excellent web proxy known as mitmproxy, built a front end to interface with it and created engines to automatically analyze the captured traffic to hilight security/privacy issues.

Scanning an application is as simple as pointing your phone to ZAP and using the application that you want to analyze - that's it. View the video below for a detailed walkthrough of the scanning functionality, but overall, it's a simple six step process as noted in the image below.

Video

The video below provides a detailed walkthrough of all ZAP functionality.

We look forward to hearing your feedback on how we can continue to improve ZAP, so please take it for a test drive and let us know what you think. There are many mobile apps that expose users to security/privacy risks and to date, the app store gatekeepers aren't doing an adequate job of protecting end users from these threats. Using ZAP you can help analyze the ever growing list of mobile apps and reveal those that are putting users at risk.

Enjoy!

- michael

Introducing Project Zulu

I want to personally and publicly thank Julien, Pradeep and Mike for all of their hard work over the past several months, to make today's launch of Project Zulu a reality. Zulu is a completely free service, open to anyone, which allows people to determine the risk posed by a particular web resource.

Zulu Launch Banner

Our goal in building Zulu, was to provide a simple and straightforward interface accessible to anyone regardless of security knowledge, while still delivering granular results that are of value to those that are more security savvy. I believe we've achieved this by providing a UI that requires no additional input beyond the UI to be analyzed, while allowing a few necessary advanced options, (User-Agent and Referer) when encountering malware triggered only when certain input variables are met. Results also display an overall ranking of Benign, Suspicious or Malicious, but also include details of elements that went into the overall score.

Zulu User Interface

We were also determined not to deliver a 'me too' project as there are already a number of great security projects available. Services like VirusTotal, Anubis and Wepawet for example, are invaluable tools when running specific tests (multi-AV, JavaScript/PDF analysis and sandboxing respectively). However, most projects such as these tend to focus on a specific threat or type of analysis. With Zulu, we sought to combine our own proprietary scanning techniques, with the great open source intel. that is available, to provide a broad view of the overall risk posed by virtually any web resource. We also look not just at a specific aspect of the resource, but instead, separately focus on determining risk for the content, URL and host separately, which is then combined into an overall risk score. For each component, we employ the following approaches:

Zulu results for Zeus Related Malware

• Content – Page content is scoured for the inclusion of potentially malicious code leveraging proprietary Zscaler algorithms, conducting heuristic tests and querying public sources.
• URL – The requested URL is tested against known suspicious/malicious patterns, public black/white lists, as well as historic risk assessments for subdomains, domain TLDs, file types, etc.
• Host – Historic reputations of the host IP address, Anonymous System Number (ASN) and geographic location are analyzed, along with suspicious behaviors displayed by the host in question.

A unique benefit of this approach is that we can deliver a risk score even when the page content is no longer available. While we can't access the page, we can still assess the URL and host and when they deliver a high risk score despite a lack of page content, one can often conclude the page was indeed malicious but has since been taken down. We also provide full access to historical scan results for the same resource. This can often uncover when a page first became infected and when it was subsequently cleaned up.

Why would Zscaler, a commercial entity, release a free tool? I'm sure that companies release free tools for a variety of reasons and ours are quite straightforward. Obviously Zulu provides a marketing benefit, but beyond this, it permits ThreatLabZ great freedom to experiment with new detection techniques. We plan to use Zulu as a proving ground for our great ideas (and yes, that makes you our guinea pigs). The benefit to you is that you're able to leverage some of our latest and greatest techniques. Moreover, you may well analyze a malicious web site that we haven't seen before. In the end, we hope that you find Zulu to be a valuable tool to combat web based threats and we certainly welcome your feedback at zulu[at]zscaler[dot]com.

One last thing. Why Zulu? Well, the Zulu warrior was a formidable foe, but more importantly, Zulu warriors represented a citizens army. Not a standing army, but one that came together and fought valiantly when faced with an impending threat to their society. We view our Zulu as a tool for for a citizen army combating malicious content. Everyone can use it and everyone benefits from historical results. Join the army!

- michael

IPAbuseCheck Stats

Last week, we announced our IPAbuseCheck lookup tool. We see lots of infected/abusive hosts on the Internet attempting to proxy abusive web transactions through our proxies. Rather than just ignoring these transactions, we’ve decided to provide this lookup utility for security professionals and organizations to query and identify abusive/infected hosts within their networks – based on some feedback, the service has been well received. This follow-up post provides a brief summary of the top offenders that we see in our database to date (July 1 – October 25, 2011).

Top Abuse Breakdown by Geography

The top 15 countries account for over 75% of the abusive clients that we have seen- with the US, China, Russia, Germany, Venezuela, and India accounting for half of the abusive clients that we have seen to date.

Top Abuse Breakdown by Organization (ASN)

ASN by Abusive Clients	ASN by Abusive Transactions
ASN % of Clients AS4812 China Telecom 6.32% AS4134 Chinanet 5.16% AS8048 Servicios, Venezuela 3.82% AS4837 CNCGROUP 2.54% AS15857 Telefonia Dialog S.A. 2.53%	ASN % of Transactions AS14618 Amazon.com, Inc. 25.16% AS8069 Microsoft Corp 10.23% AS8075 Microsoft Corp 9.92% AS4134 Chinanet 5.02% AS28753 Leaseweb Germany 4.28%

It was interesting to see some well known organizations like Amazon and Microsoft near the top for organizations that have sent us the most abusive transactions. Rather than these being infected corporate systems, it appears to be a handful of hosting service systems that are being abused either directly from the customer or from an infection. Here is a snapshot of a report from our database of a Microsoft IP that we reported to their Abuse Dept. once we started digging into this data:

70.37.48.163
OriginAS: AS8075
NetName: MICROSOFT-DYNAMIC-HOSTING

Screenshot of 70.37.48.163 Abuse Report

The transactions observed were hundreds of thousands of brute-force attempts against file sharing sites like Megaupload, Hotfile, Filesonic, and Rapidshare.

Top Abuse Breakdown by Client

Clients in our database that have the longest time range of abuse seen tend to be those clients that are scanning the Internet looking for open web proxies. These were the top 5 clients that we have seen with the longest date range from:

Top 5 Abusive Hosts by Date Range

Host	First Seen	Last Seen	Behavior
193.17.253.7	07/01/11 07:00	10/25/11 06:54	Proxy Scanning
207.226.163.146	07/01/11 07:00	10/25/11 06:51	Proxy Scanning
174.34.168.114	07/01/11 07:06	10/25/11 06:57	Proxy Scanning
221.187.4.28	07/01/11 07:07	10/25/11 06:56	Proxy Scanning
69.164.211.212	07/01/11 07:08	10/25/11 06:54	Proxy Scanning

The following table lists the top 5 abusive hosts by transaction count - these tend to be hosts that attempt to forward bulk transactions through proxies, like forum spam and brute-force attempts. Related to the previous section of organizations with the top abusive transactions - you can see that two Amazon EC2 systems (75.101.225.168, 248) are at the top of the list.

Top 5 Abusive Hosts by Transactions

Host	Transaction %	Behavior
75.101.225.168	19.94%	Forum Spam
111.221.81.70	6.31%	Forum Spam
75.101.225.248	5.17%	Forum Spam
117.41.235.133	3.06%	Brute-Forcing
84.16.224.62	2.13%	Brute-Forcing

Top Web Services Targeted in Abuse

The following lists the top 5 most targeted web sites/services abused by number of transactions and number of unique abusing clients.

Top 5 Abused Web Services by:

Abusive Transactions: forum.zing.vn dbol.vn/forum/ forum.sonlaol.vn api.rapidshare.com vdrz.vn/f/

Abusive Clients: chek.zennolab.com login.sina.com.cn clickingagent.com p24.easybitsgo.net checker.samair.ru

The bulk of the top sites by transaction are forum spam sites - in the top instances, the forums being abused are in Vietnam. One brute-forcing target is in the top 5, which is the Rapidshare file host. The bulk of the top services being used/abused by number of clients are proxy checkers - the Chinese service sina.com.cn was also listed in the top as a spam bot / brute-forcing target.

The above post provides some insight into the types of information that can be extracted from this service, and we'll continue to update the database regularly with the latest abusing clients.

IPAbuseCheck: Clients Abusing Web Proxies

IPAbuseCheck was designed to provide a simple, free web interface to query your IP addresses against a database that we have built containing unauthenticated IP addresses that have attempted to forward abusive or unwanted traffic through one or more of our proxies. The database contains abusive IPs identified from July to present, and contains well over 20K unique IP addresses. Here is a screenshot showing an example report of an IP listed in our DB:

In this case, a client IP at a very large software company is infected and attempted to issue tens of thousands of login POST requests through our proxies to Megaupload servers (and others such as Rapidshare, Hotfiles, and Yahoo webmail) using the "Googlebot" user-agent. Note: URL parameter values have been stripped from the URLs in our database. This particular client IP is not listed in any IP blacklists (checked using rbls.org). Very often IP blacklists list client IP addresses visible from the server perspective - in this case, it would have been our proxy IP if we let these transactions through. Our database provides a bit of a different perspective from many of these existing blacklists, in that we are listing abusive clients that are using proxies.

The goal of this free service is to provide those interested (ISPs, companies/organizations, security professionals, etc.) with this data to identify and clean-up clients that are participating in this form of abuse. Clients leverage proxies to distribute and/or mask their origin when conducting forms of abuse, such as:

• Brute-force web-based logins
• Search Engine Optimization (SEO)
• Forum spamming
• Pay-per action cheating
• Open proxy scanning
• Bulk account registration
• Site popularity / voting inflation
• other forms of abuse (DDoS and web-site scraping)

Client IPs listed include both those that are intentionally used for abuse and those that are from infected hosts that are unknowingly abusing proxies on the Internet. Zscaler's service provides policy and security enforcement through its proxies from its customers - valid customers must first authenticate to the Zscaler service before being able to use our proxies. Transactions listed in this database are from unauthenticated clients attempting to utilize our proxies in an open manner to distribute and mask traffic for their abuse.

The idea for this service stemmed from two Zscaler blog posts:

• Top Abuses of Open Web Proxies
• Brute-Forcing Client using "Googlebot" UA

We attempted to remove anything that we deemed to be a false-positive of abuse, but since this listing based on a few things like regular expressions and behavioral patterns it is still possible that the database contains false-positives. Use this information at your own discretion.

Using TheBrain to Visualize Web Transaction Logs

For those unfamiliar with TheBrain - it is a highly interactive mind-mapping software, which includes a free edition called the PersonalBrain. I have used this software on-and-off for a few years, and really like it for organizing and interacting with my thoughts when I start a new project. I recently took a look at using the software to organize and visualize web transaction logs for analysis (specifically to extract suspicious / malicious transactions). Below details my experiences - I'm curious to know what others have found to work.

After exchanging a few emails with TheBrain support (they are very responsive) - they shared a 5-page document on their supported XML formats. A DTD file is available, and is extremely easy to convert your data into "Thoughts" and "Links" (just make sure to properly handle any XML entities within your data). Thoughts are basically nodes within your mind-map and links can be parent/child or "jump" relationships (I think of these as bi-directional "lookup" relationships or cross-references). In my case I wrote a Perl script to extract and convert portions of my data into the supported XML format and then imported it into PersonalBrain.
The above is data from 5 transactions imported into the PersonalBrain with these relationships:

• ServerIP, Domain, URLPath, RequestType, Country, ASN, Score, AnalyticCheck, and Transactions are all children of Data, and each has related data under each Thought. For example, 1.2.3.4 falls under ServerIP and China falls under Country.
  
• ServerIP data has jump links to related ASN, Country, and Domain data and vice versa (the links are bi-directional)
  
• Domain data has jump links to related URLPaths and vice versa
• Transaction data has related jump links to ServerIP, Domain, URLPath, RequestType, Country, ASN, Score, and AnalyticCheck and vice versa

By having the data in this visual format, it is easy to quickly drill-down and view transactions with higher "suspicious" scores and then cross-reference their transaction information with other transactions. You have the ability to view both primary and secondary relationships, similar to what is displayed in the above graph, or a more concise view with just the primary relationships:


Zeus/SpyEye and other bots are often configured to use an IP lookup service (a possible example above) and provide their resolvable IP to the C&C. These types of inter-related transactions can become apparent when correlating botnet web transactions.

I found TheBrain to have a very easy format for converting and importing data to, and to have a very user-friendly, interactive, and fun! interface for working with your imported data. TheBrain includes the ability to "forget" and "remember" thoughts - i.e., the ability to remove and restore thoughts/links, so while you are conducting your analysis you can clear your brain of any data that is in the way.

What I did find TheBrain woefully inadequate for is large data-sets. When I exported all of the data that I wanted to review for a day, the XML file was 1.66GB for all of the Thoughts and Links. When I tried to import into PersonalBrain on my MacBook Pro (4GB, 2.53GHz Core 2 Duo) I ended up letting it attempt the import overnight ... after about 20 hours of waiting for it to import the data I "force quit" the application (though it never said "not responding").

If your data-set is of relatively small size, TheBrain may be a good free tool to add to your arsenal. Feel free to share other good, interactive, free visualization tools for analyzing web transaction logs, particularly if they scale to larger data-sets.

Detecting Firesheep

Firesheep, a Firefox plugin to do session hijacking ("sidejacking") by snooping on a LAN/WLAN and identifying session cookies passed in the clear over HTTP was released last week at Toorcon. To my surprise, this tool received a large amount of media attention. As the authors point out in their presentation, session hijacking is nothing new ... they actually describe it as the known "elephant in the room." In fact a few years ago (2008), sidejacking was presented at DefCon and a tool was written to take advantage of Gmail cookies being passed over HTTP to hijack Gmail sessions (see preso here). This presentation and tool also received a fair bit of media attention. Unfortunately not a whole lot was done about this problem. Google did eventually provided persistent SSL/TLS sessions for Gmail users, however as the Google Handler in Firesheep shows, user's Google session cookies can be captured when navigating from Gmail (HTTPS) to the Google search page (HTTP) or other HTTP Google pages that continue to track your Google profile (session). As the list of Firesheep handlers shows, the problem of passing session cookies in the clear is persistent across most all mainstream web services:


So how do you the user deal with this problem of websites passing session cookies in the clear for all to snoop off the Starbucks or Panera wifi you're using. The proper way of dealing with this problem is to browse to these sites through a trusted network connection. If not available, an encrypted tunnel (VPN, SSH, SSL, etc.) may be established through a trusted host to secure your web transactions. In addition to these known good security practices, I also took a look at detecting if someone is running Firesheep on the LAN/WLAN that you are connected to. The first thing that Firesheep does after it detects the session cookies for a site of interest is to automatically attempt to connect and scrape the user's account name and avatar to then display in the Firesheep/Firefox side panel. Because Firesheep is running on the same LAN/WLAN you are able to see Firesheep's network transactions the same way it saw yours :)

I just used Scapy (a python packet manipulation program) and generated one packet with the Facebook details that Firesheep is looking for. Here is the Facebook Firesheep handler:

Firesheep is looking for 3 cookies (xs, c_user, and sid) being passed to Facebook. So that's what I generate, with a few modifications - I make my packet IP address destination just for the gateway IP (versus sending garbage to Facebook) and send bogus "66666" values for the three cookies. In the Scapy interactive session this was done in these three lines (for readability):

>>> get = "GET /home.php HTTP/1.1\r\nHost: www.facebook.com\r\nUser-Agent:
Mozilla/5.0\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*
/*;q=0.8\r\nAccept-Language: en-us,en;q=0.5\r\nAccept-Encoding: gzip,deflate\r\nAccept-
Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\nKeep-Alive: 115\r\nConnection: keep-alive\r
\nCookie: c_user=66666; sid=66; xs=6666666\r\n\r\n"
>>> pkt = IP(dst="192.168.1.1")/TCP(flags="SPA",sport=12345,dport=80)/get
>>> send(pkt)

Here is the output of the packet that was generated:


Immediately after putting this packet onto the wire (well actually, it was wifi), I was able to see in Wireshark an attempted network session to Facebook with the fake session cookies that I populated.
The first packet highlighted in blue is the generated / fake Facebook session cookie packet to 192.168.1.1. Immediately following this packet being sent, we see packets being generated from my open Firefox running a Firesheep capture on the network. Firesheep immediately attempts to access www.facebook.com/home.php with the captured (fake) session cookies, only to be 302 redirected to the login.php page since the session is invalid. Any users running Firesheep on this LAN/WLAN would have also attempted this invalid session information and we would have seen it in our packet capture. From the Firesheep user's perspective, an error is displayed for the fake session information that I provided. Whereas, valid sessions display the account name and avatar that was scraped from accessing Facebook with the captured session cookies:

This technique could be put in a loop to generate and flood random fake session packets to provide an annoyance to the Firesheep user. Though they would just have to scroll through and ignore all of the error profiles. Also the flood of fake session packets and corresponding flood of traffic from Firesheep attempting to connect with the session cookies would likely result in a fairly unusable wifi network - and possible blacklisting from Facebook or other sites being repeatedly accessed by Firesheep with false session cookies.

The above described technique provides a 1 packet means of detecting Firesheep. Regardless of detection, users should (1) be wary of authenticating to sites on public/untrusted networks, (2) be disappointed with and encourage security changes among the web services they use, and (3) utilize encrypted tunnels (VPN, SSH, SSL proxy, etc.) to protect their session information when on public networks.

Who knows, maybe this round of attention on sidejacking will result in some real change..?