We blogged a little while back about the Snoopy demonstration given at 44Con London. A similar talk was given at ZaCon in South Africa. Whilst we've been promising a release for a while now, we wanted to make sure all the components were functioning as expected and easy to use. After an army of hundreds had tested it (ok, just a few), you may now obtain a copy of Snoopy from here. Below are some instructions on getting it running (check out the README file from the installer for additional info).
Remind me what Snoopy is?
Snoopy is a distributed tracking, data interception, and profiling framework.
-Ubuntu 12.04 LTS 32bit online server
-One or more Linux based client devices with internet connectivity and a WiFi device supporting injection drivers. We'd recommend the Nokia N900.
-A copy of Maltego Radium
After obtaining a copy from github run the install.sh script. You will be prompted to enter a username to use for Snoopy (default is 'woodstock') and to supply your public IP address. This is depicted below:
This installation will take around 3-5 minutes. At the end of the installation you will be presented with a randomly generated password for the web interface login. Remember it. You may now run the server component with the command snoopy, and you will be presented with the server main menu, as depicted below.
Selecting the 'Manage drone configuration packs' menu option will allow you to create custom installation packs for all of your drone devices. You will be presented with download links for these packs, such that you can download the software to your drones.
From your drone device download and extract the file from given link. Run setup_linux.sh or setup_n900.sh depending on your drone.
All collected probe data gets uploaded to the Snoopy server every 30 seconds. All associated clients have their internet routed through the server over OpenVPN. If you so desire, you can explore the MySQL database 'snoopy' to see this raw data. Graphical data exploration is more fun though.
In the Snoopy server menu select 'Configure server options' > 'List Maltego transform URLs'. This will give URLs to download Maltego Snoopy entities and machines, as well as a list of TDS transform URLs. You will need to download and add the entities and machines to your local Maltego installation, and add the transform URLs to your Maltego TDS account (https://cetas.paterva.com/tds). This is depicted below.
We can explore data my dragging the 'Snoopy' entity onto the canvas. This entity has two useful properties - 'start_time' and 'end_time'. If these are left blank Snoopy will run in 'real time' mode - that is to say displaying data from the last 5 minutes (variable can be set in server configuration menu). This time value will be 'inherited' by entities created from this point. The transforms should be obvious to explore, but below are some examples (further examples were in the original blog post).
I shall write a separate blog post detailing all the transforms. For now, enjoy playing around.
You can access the web interface via http://yoursnoopyserver:5000/. You can write your own data exploration plugins. Check the Appendix of the README file for more info on that.
At this year's 44Con conference (held in London) Daniel and I introduced a project we had been working on for the past few months. Snoopy, a distributed tracking and profiling framework, allowed us to perform some pretty interesting tracking and profiling of mobile users through the use of WiFi. The talk was well received (going on what people said afterwards) by those attending the conference and it was great to see so many others as excited about this as we have been.
In addition to the research, we both took a different approach to the presentation itself. A 'no bullet points' approach was decided upon, so the slides themselves won't be that revealing. Using Steve Jobs as our inspiration, we wanted to bring back the fun to technical conferences, and our presentation hopefully represented that. As I type this, I have been reliably informed that the DVD, and subsequent videos of the talk, is being mastered and will be ready shortly. Once we have it, we will update this blog post. In the meantime, below is a description of the project.
"Snoopy is a distributed tracking and profiling framework."
Below is a diagram of the Snoopy architecture, which I'll elaborate on:
Snoopy runs client side code on any Linux device that has support for wireless monitor mode / packet injection. We call these "drones" due to their optimal nature of being small, inconspicuous, and disposable. Examples of drones we used include the Nokia N900, Alfa R36 router, Sheeva plug, and the RaspberryPi. Numerous drones can be deployed over an area (say 50 all over London) and each device will upload its data to a central server.
A large number of people leave their WiFi on. Even security savvy folk; for example at BlackHat I observed >5,000 devices with their WiFi on. As per the RFC documentation (i.e. not down to individual vendors) client devices send out 'probe requests' looking for networks that the devices have previously connected to (and the user chose to save). The reason for this appears to be two fold; (i) to find hidden APs (not broadcasting beacons) and (ii) to aid quick transition when moving between APs with the same name (e.g. if you have 50 APs in your organisation with the same name). Fire up a terminal and bang out this command to see these probe requests:
tshark -n -i mon0 subtype probereq
(where mon0 is your wireless device, in monitor mode)
Each Snoopy drone collects every observed probe-request, and uploads it to a central server (timestamp, client MAC, SSID, GPS coordinates, and signal strength). On the server side client observations are grouped into 'proximity sessions' - i.e device 00:11:22:33:44:55 was sending probes from 11:15 until 11:45, and therefore we can infer was within proximity to that particular drone during that time.
We now know that this device (and therefore its human) were at a certain location at a certain time. Given enough monitoring stations running over enough time, we can track devices/humans based on this information.
3. Passive Profiling?
We can profile device owners via the network SSIDs in the captured probe requests. This can be done in two ways; simple analysis, and geo-locating.
Simple analysis could be along the lines of "Hmm, you've previously connected to hooters, mcdonalds_wifi, and elCheapoAirlines_wifi - you must be an average Joe" vs "Hmm, you've previously connected to "BA_firstclass, ExpensiveResataurant_wifi, etc - you must be a high roller".
Of more interest, we can potentially geo-locate network SSIDs to GPS coordinates via services like Wigle (whose database is populated via wardriving), and then from GPS coordinates to street address and street view photographs via Google. What's interesting here is that as security folk we've been telling users for years that picking unique SSIDs when using WPA is a "good thing" because the SSID is used as a salt. A side-effect of this is that geo-locating your unique networks becomes much easier. Also, we can typically instantly tell where you work and where you live based on the network name (e.g BTBusinessHub-AB12 vs BTHomeHub-FG12).
The result - you walk past a drone, and I get a street view photograph of where you live, work and play.
4. Rogue Access Points, Data Interception, MITM attacks?
Snoopy drones have the ability to bring up rogue access points. That is to say, if your device is probing for "Starbucks", we'll pretend to be Starbucks, and your device will connect. This is not new, and dates back to Karma in 2005. The attack may have been ahead of its time, due to the far fewer number of wireless devices. Given that every man and his dog now has a WiFi enabled smartphone the attack is much more relevant.
Snoopy differentiates itself with its rogue access points in the way data is routed. Your typical Pineapple, Silica, or various other products store all intercepted data locally, and mangles data locally too. Snoopy drones route all traffic via an OpenVPN connection to a central server. This has several implications:
(i) We can observe traffic from *all* drones in the field at one point on the server. (ii) Any traffic manipulation needs only be done on the server, and not once per drone. (iii) Since each Drone hands out its own DHCP range, when observing network traffic on the server we see the source IP address of the connected clients (resulting in a unique mapping of MAC <-> IP <-> network traffic). (iv) Due to the nature of the connection, the server can directly access the client devices. We could therefore run nmap, Metasploit, etc directly from the server, targeting the client devices. This is a much more desirable approach as compared to running such 'heavy' software on the Drone (like the Pineapple, pr Pwnphone/plug would). (v) Due to the Drone not storing data or malicious tools locally, there is little harm if the device is stolen, or captured by an adversary.
On the Snoopy server, the following is deployed with respect to web traffic:
(i) Transparent Squid server - logs IP, websites, domains, and cookies to a database (ii) sslstrip - transparently hijacks HTTP traffic and prevent HTTPS upgrade by watching for HTTPS links and redirecting. It then maps those links into either look-alike HTTP links or homograph-similar HTTPS links. All credentials are logged to the database (thanks Ian & Junaid). (iii) mitmproxy.py - allows for arbitary code injection, as well as the use of self-signed SSL certificates. By default we inject some JavaScipt which profiles the browser to discern the browser version, what plugins are installed, etc (thanks Willem).
Additionally, a traffic analysis component extracts and reassembles files. e.g. PDFs, VOiP calls, etc. (thanks Ian).
5. Higher Level Profiling? Given that we can intercept network traffic (and have clients' cookies/credentials/browsing habbits/etc) we can extract useful information via social media APIs. For example, we could retrieve all Facebook friends, or Twitter followers.
6. Data Visualization and Exploration? Snoopy has two interfaces on the server; a web interface (thanks Walter), and Maltego transforms.
-The Web Interface The web interface allows basic data exploration, as well as mapping. The mapping part is the most interesting - it displays the position of Snoopy Drones (and client devices within proximity) over time. This is depicted below:
-Maltego Maltego Radium has recently been released; and it is one awesome piece of kit for data exploration and visualisation.What's great about the Radium release is that you can combine multiple transforms together into 'machines'. A few example transformations were created, to demonstrate:
2. Devices at 44Con, pruned
Here we look at all devices and the SSIDs they probed for at 44Con. The pruning consisted of removing all SSIDs that only one client was looking for, or those for which more than 20 were probing for. This could reveal 'relationship' SSIDs. For example, if several people from the same company were attending- they could all be looking for their work SSID. In this case, we noticed the '44Con crew' network being quite popular. To further illustrate Snoopy we 'targeted' these poor chaps- figuring out where they live, as well as their Facebook friends (pulled from intercepted network traffic*).
The pi chart below depicts the proportion of observed devices per vendor, from the total sample of 77,498 devices. It is interesting to see Apple's dominance. pi_chart
The barchart below depicts my day sitting at King's Cross station. The horizontal axis depicts chunks of time per hour, and the vertical access number of unique device observations. We clearly see the rush hours.
Legal -Collecting anonymized statistics on thoroughfare. For example, Transport for London could deploy these devices at every London underground to get statistics on peak human traffic. This would allow them to deploy more staff, or open more pathways, etc. Such data over the period of months and years would likely be of use for future planning. -Penetration testers targeting clients to demonstrate the WiFi threat.
Borderline -This type of technology could likely appeal to advertisers. For example, a reseller of a certain brand of jeans may note that persons who prefer certain technologies (e.g. Apple) frequent certain locations. -Companies could deploy Drones in one of each of their establishments (supermarkets, nightclubs, etc) to monitor user preference. E.g. a observing a migration of customers from one establishment to another after the deployment of certain incentives (e.g. promotions, new layout). -Imagine the Government deploying hundreds of Drones all over a city, and then having field agents with mobile Drones in their pockets. This could be a novel way to track down or follow criminals. The other side of the coin of course being that they track all of us...
Illegal -Let's pretend we want to target David Beckham. We could attend several public events at which David is attending (Drone in pocket), ensuring we are within reasonable proximity to him. We would then look for overlap of commonly observed devices over time at all of these functions. Once we get down to one device observed via this intersection, we could assume the device belongs to David. Perhaps at this point we could bring up a rogue access point that only targets his device, and proceed maliciously from there. Or just satisfy ourselves by geolocating places he frequents. -Botnet infections, malware distribution. That doesn't sound very nice. Snoopy drones could be used to infect users' devices, either by injection malicious web traffic, or firing exploits from the Snoopy server at devices. -Unsolicited advertising. Imagine browsing the web, and an unscrupulous 3rd party injects viagra adverts at the top of every visited page?
Q. I use Apple/Android/Foobar - I'm safe! A. This attack is not dependent on device/manufacture. It's a function of the WiFi specification. The vast majority of observed devices were in fact Apple (>75%).
Q. How can I protect myself? A. Turn off your WiFi when you l leave home/work. Be cautions about using it in public places too - especially on open networks (like Starbucks). A. On Android and on your desktop/laptop you can selectively remove SSIDs from your saved list. As for iPhones there doesn't seem to be option - please correct me if I'm wrong? A. It'd be great to write an application for iPhone/Android that turns off probe-requests, and will only send them if a beacon from a known network name is received.
Q. Your research is dated and has been done before! A. Some of the individual components, perhaps. Having them strung together in our distributed configuration is new (AFAIK). Also, some original ideas where unfortunately published first; as often happens with these things.
Q. But I turn off WiFi, you'll never get me! A. It was interesting to note how many people actually leave WiFi on. e.g. 30,000 people at a single London station during one day. WiFi is only one avenue of attack, look out for the next release using Bluetooth, GSM, NFC, etc :P
Q. You're doing illegal things and you're going to jail! A. As mentioned earlier, the broadcast nature of probe-requests means no laws (in the UK) are being broken. Furthermore, I spoke to a BT Engineer at 44Con, and he told me that there's no copyright on SSID names - i.e. there's nothing illegal about pretending to be "BTOpenzone" or "SkyHome-AFA1". However, I suspect at the point where you start monitoring/modifying network traffic you may get in trouble. Interesting to note that in the USA a judge ruled that data interception on an open network is not illegal.
Q. But I run iOS 5/6 and they say this is fixed!! A. Mark Wuergler of Immunity, Inc did find a flaw whereby iOS devices leaked info about the last 3 networks they had connected to. The BSSID was included in ARP requests, which meant anyone sniffing the traffic originating from that device would be privy to the addresses. Snoopy only looks at broadcast SSIDs at this stage - and so this fix is unrelated. We haven't done any tests with the latest iOS, but will update the blog when we have done so.
Q. I want Snoopy! A. I'm working on it. Currently tidying up code, writing documentation, etc. Soon :-)
[2011/9/6 Edited to add Slideshare embed]
I am currently in London at the first ever 44con conference. It's been a fantastic experience so far - excellent talks & friendly people.
Yesterday, I presented a paper titled "Systems Applications Proxy Pwnage" . The talk precis sums it up nicely:
It has been common knowledge for a number of years that SAP GUI communicates using an unencrypted and compressed protocol by default, and numerous papers have been published by security professionals and researchers dealing with decompressing this traffic.
Until now, most of these methods have been time consuming, convoluted and have focussed more on obtaining sensitive information (such as credentials) than a thorough understanding of the protocol used by SAP GUI.
During this presentation, the speaker will focus on the protocol used by SAP GUI. The speaker will demo and release a new tool-set to assist security professionals in parsing, decompressing and understanding this protocol, as well as demonstrate how this formerly sacrosanct protocol makes SAP applications potentially vulnerable to a wide-range of attacks which have plagued web applications for years.
The talk went very well. All demos worked perfectly. My newly authored toolset not only seems to have performed admirably during the presentation, but also seems to be in some demand...
As such, I'm pleased to announce the public release of two tools - SApCap and SAPProx.
SApCap is a Java-based packet sniffer, decompressor and protocol analysis tool for SAP GUI. It makes use of a third-party JNI interface for pCap (get it here) and a custom-built JNI decompression interface for SAP. You can download it here.
SAPProx is what I believe to be the world's first ever SAP GUI proxy. Think of it as WebScarab for SAP. You can download it here.
The programs are GPL, and the sources are also available from the relevant pages.
The custom JNI library used for decompressing SAP traffic is also available from the previously mentioned download pages in both binary and source formats. I have, however, only had the opportunity to build binary libraries for Mac OS/X, Linux (32-bit) and Windows (32-bit). I will add more binary libraries as soon as I get back to ZA and have access to some different build environments again.
If you're interested, a copy of my 44con presentation is available from here or below.
Following on from Evert's posting about the new BroadView v4, I'd like to showcase a specific aspect of BV that we've found useful, namely Attributes. These are small pieces of data collected and maintained for each host scanned by BV including somewhat mundane bits of info like IP address and OS but, they also include some really tasty morsels about remote hosts that are scanned. Attributes are collected on a per-scan-per-host basis, and are populated by each test that runs during the scan. Since attribute population is dependent on the selected tests, the set of Attributes available to you would vary according to you configuration.
Consider the trivial attribute Network.TCP.HTTP.Banner; this doesn't require credentials to acquire and is stored by a test that detects webservers. On the other hand, the test that stores Users.Microsoft.Windows.Group.SystemOperators.Members would require domain credentials in order to pull the needed info. This is common inside of organisations, where BV is primarily intended.
To help me explain the power of Attributes a little easier, here are a few scenarios:
Your IT manager wants to know which Windows machines are missing the new MS10-018 patch. Instead of trawling through all the latest scans looking for hosts that are affected , you simply:
One of the IT techies gives you a call:
Bob: Hey Steve Steve: Ahoy Bob: Do you know which FTP servers on the network allow Anonymous access? Steve: Ofcourse I do Login to BroadView >> Attributes >> Network.TCP.FTP.IsAnonymousAccessAllowed >> True >> Download CSV Steve: You got mail Bob: Awesome, thanks
As you can see the power and extensibility of BroadView Attributes is (according to opinions from the office) Simply Astonishing(tm). We are currently working with our Assessment team to include Attributes that would allow them to very quickly pull a list of all "low hanging fruit" vulnerabilities when performing an internal Pen Test.
Currently we collect just over 50 attributes, but are adding new ones as we either think of or clients request more. The full list is:
Services.Microsoft.Windows.Running Users.Microsoft.Windows.Local.LastLoggedIn Users.Microsoft.Windows.Local.NeverLoggedIn Users.Microsoft.Windows.Local.PasswordNeverExpires Users.Microsoft.Windows.Group.AccountOperators.Members Users.Microsoft.Windows.Group.BackupOperators.Members Users.Microsoft.Windows.Group.PrintOperators.Members Users.Microsoft.Windows.Group.Replicators.Members Users.Microsoft.Windows.Group.SystemOperators.Members Users.Microsoft.Windows.Network.NeverChangedPasswords Users.Microsoft.Windows.Network.NeverLoggedOn Users.Microsoft.Windows.Network.PasswordNeverExpires Users.Microsoft.Windows.ActiveDirectory.Group.Members Users.Microsoft.Windows.ActiveDirectory.AccountsOld.Members Users.Microsoft.Windows.ActiveDirectory.AccountsStale.Members Users.Microsoft.Windows.ActiveDirectory.AccountsBadLogins.Members Users.Microsoft.Windows.ActiveDirectory.AccountsOldPassword.Members Users.Microsoft.Windows.ActiveDirectory.AccountsPasswordNeverSet.Members Users.Microsoft.Windows.ActiveDirectory.AccountsDisabled.Members Users.Microsoft.Windows.ActiveDirectory.AccountsLocked.Members Config.Microsoft.Windows.Domain.IsCorrect Config.Microsoft.Windows.Domain.Value Config.Microsoft.Windows.WSUS.Server Config.Microsoft.Windows.WSUS.Server.IsConfigured Config.Microsoft.Windows.WSUS.Server.Value Config.Microsoft.Windows.MachineName Debug.Network.IsHostAccessible
|Debug.Microsoft.Windows.Registry.Access.Full Debug.Microsoft.Windows.Registry.Access.Read Debug.Microsoft.Windows.Registry.Access.Fail Debug.Microsoft.Windows.Privileges.Admin.Full Debug.Microsoft.Windows.Privileges.Admin.Fail ServicePacks.Microsoft.Windows.Win2k3.Value ServicePacks.Microsoft.Windows.Win2k3.IsInstalled ServicePacks.Microsoft.Windows.NT4.Value ServicePacks.Microsoft.Windows.NT4.IsInstalled ServicePacks.Microsoft.Windows.Win2k.Value ServicePacks.Microsoft.Windows.Win2k.IsInstalled ServicePacks.Microsoft.Windows.XP.Value ServicePacks.Microsoft.Windows.XP.IsInstalled Software.Microsoft.Office.Value Software.Microsoft.Office.IsInstalled Software.Microsoft.SMSAgent.IsInstalled Software.Microsoft.SMSAgent.IsRunning Software.Microsoft.SMSAgent.IsInstalled Software.Microsoft.SMSAgent.McAfee.EPOAgent.IsInstalled Software.AntiVirus.Linux Processes.Microsoft.Windows Network.TCP Network.TCP.FTP.IsAnonymousAccessAllowed Network.TCP.SMTP.IsRelayAllowed Network.TCP.HTTP.Banner Network.TCP.HTTP.Directories Network.TCP.Banner Network.TCP.SMB.Direcotories Network.UDP.DNS.ReverseDNS Network.UDP.LDAP.BaseObject|
Theft of resources is the red-headed step-child of attack classes and doesn't get much attention, but on cloud platforms where resources are shared amongst many users these attacks can have a very real impact. With this in mind, we wanted to show how EC2 was vulnerable to a number of resource theft attacks and the videos below demonstrate three separate attacks against EC2 that permit an attacker to boot up massive numbers of machines, steal computing time/bandwidth from other users and steal paid-for AMIs.
For this video we wanted to consider a DoS on the EC2 from within, by running as many AMIs concurrently as possible.
Since sign-up for the sevice occurred in a browser, it was possible to script this process (using Twill for the most part). The first attack would be to boot hundreds or thousands of instances under one Amazon account, however an upper bound of 20 running machines per account is enforced by Amazon. Our approach was one step removed from this; we created multiple accounts and then ran the 20 machines. Each new account would also create multiple accounts and then run 20 machines. One iteration of the create-accounts-and-boot-AMIs cycle took three minutes; by the ninth iteration the projected number of running instances is ridiculous. It's apparent that this recursive registering of accounts and booting machines means that the number of running machines grows exponentially and this could continue until the system can't handle the machine load.
Our approach was effective because the registration process took no steps to prevent automated sign-up. In testing a single credit card was used to create our accounts which is an immediate anomaly however a malicious attacker would use stolen CC data to ensure that CC checks did not prevent new account registration.
As has been mentioned, users can choose AMIs from a list of machines that is mostly user-generated (out of 2700 odd machines, 47 were built by Amazon and the remainder by other users.) It is easy to add a machine to this list; simply create a new AMI and in its properties mark it as 'public'.
Our idea was to create a malicious AMI and add it to the public listing, with the goal being to show that users will run AMIs without any consideration for who built it or whether nasties were included. We quickly created an AMI, uploaded it and... nothing. No one ran the image and it seemed that people weren't so easily fooled.
Digging a little deeper, however, revealed that when our image was created, it was dumped on the second last page of the AMI listings and so users would have to surf through more than 50 pages of images before coming across our AMI. If Google has taught us anything, it's that ranking counts and so we needed to boost our machine up the AMI listing.
It turns out that the AMI listing is ordered by the AMI ID, which is a random id string that is generated when the AMI is created. Our process was then slightly modified as follows: we scripted the AMI registration process so that it was trivial to register an image. We then looped the registration script to create and register an AMI, and tested to see whether the randomly assigned AMI ID was low enough such that our AMI was listed on the first page.
Our first attempt took about 4000 iterations and landed us a top 5 spot in under 12 hours. A subsequent attempt took less than 4 hours to land a top 5 spot.
This was great, but our image was unattractively named 'qscanImage' runing on the 'Other Linux' platform, which didn't say much about it.
It turned out that we had a great degree of freedom in naming images. Images were stored in Amazon S3 buckets and the buckets had globally unique names. We tried buckets with names such as 'fedora', 'fedora_core' and 'redhat', but all these were taken, however with a small degree of evilness the bucket 'fedora_core_11' was available and so registered. The registration race was repeated with the better named machine, and after a little while we landed the AMI on the front page as shown in the screnshot below:
What's funny is that the machine was the highest listed 'Fedora' AMI, so a user who was specifically looking for a Fedora image would come across our evil image first.
In reality our image did not have anything malicious except a call-home line in '/etc/rc.local' that would 'wget' a file on our webserver, to show the image had been booted. The screenshot below shows the logline from our webserver which proved the image had been booted; this occurred in a little under four hours after the instance had been made public.
Our final Amazon video shows how it is possible to remove ancestry information from AMIs. When a paid-for machine is created, Amazon stores information about the owner of the machine in its manifest (which is an XML document) in order to pay the creator of the image. Our attack works as follows: