POSTS BY MICHAEL ANDERSON

In Which a Smartphone is Pwnt, Thoroughly and Without Reason

Michael Anderson | Thursday, December 30th, 2010

Does your phone have a firewall? Does it have antivirus? Should it? I’ll wager your laptop does. That’s because your laptop faces the looming threat of attackers from the internet every time to connect to a network. Additionally, any time you use a network, you expose yourself to the potential for a network level attack. Everyone knows that an unprotected computer is pwnage waiting to happen. So what about your phone?

Your phone is connected to the internet 24/7. What’s more, it lacks a lot of the controls that would normally be applied to a network computing device. It has no firewall, no antivirus, and most users can’t even kill processes or modify the file system without voiding their warranty. The user has to rely on the closed nature of the device, and hope there are no exploits roaming the wild. This is paper-thin security at best, especially when you consider the trends in modern phone usage are pushing for more devices containing more sensitive data.

So how does an attacker target a mobile device? They don’t have to: given some recent developments in the Metasploit framework, they can initiate wide ranging automated attacks against anyone they can connect to. Consider the open Wi-Fi network, such as at a coffee shop. As customers sit down, and link up laptops and phones, an attacker keeps track of hosts joining the network. Then, leveraging the power of the autopwn feature of Metasploit, an attacker can attempt any number of exploits against any number of hosts, smartphone or not. Your laptop might withstand automated attacks because it has a firewall and antivirus. Your phone doesn’t. There is no “Do you want to allow this app to run?” There is no “Would you like Windows Firewall to allow access to this program?” That’s it. An attacker now has access to your phone’s audio, camera, data access, and any stored credentials or other sensitive data.

Metasploit has payloads in development for both the iPhone and Android platforms that will give root access to the phone, pending a successful exploit. Finding more exploits is only a matter of time. So this brings me to my point: Should your phone have a firewall?

Permalink | Email the Author | No Comments

Tags: Metasploit, Mobile Devices, Smartphone

Echo Mirage: Piercing the Veil of Thick Application Security

Michael Anderson | Tuesday, May 4th, 2010

In recent years web application security has gotten a lot of attention. The advent of easy to use web proxies has brought a lot of attention to SQL injection and cross-site scripting vulnerabilities, and developers have taken note. Thick application security/development, however, is lagging in that respect. You can pierce the veil yourself and witness the unprotected underbelly of thick application security, because I’m about to teach you how to use a useful tool called Echo Mirage. Echo Mirage is a versatile local proxy tool that can be used to intercept and modify TCP payloads for local Windows applications. It allows users to launch a program behind its proxy or hook into an existing process. It also supports OpenSSL and Windows SSL. Using this tool sheds light on a whole slew of bugs and holes concealed by the thick application security illusion.

Keep in mind that this technique could be interpreted as reverse engineering. Depending on the license of the software you are testing, this could stray towards the grey side of legality. For the purposes of this tutorial, I have created my own C# SQL command handler.

Step 1: Acquire Echo Mirage from here: http://www.bindshell.net/tools/echomirage. The official release version is only 1.2, and the demonstrated version is 2.0, which you can preview here: http://www.bindshell.net/entry/31.html

Step 2: Open up Echo Mirage, and click File-> Execute. Choose the .exe for your file, and click OK. Click on the green Go arrow, and your application should start. Phonebooks, invoicing, and ERP systems are common examples of applications which hook into a database and could be vulnerable to this sort of attack.

Figure 1: Having selected my target executable, the path is listed in black.

ma_042310_fig11

Figure 2: After launching the application, the red text demonstrates that Echo Mirage is intercepting traffic from the target process.

ma_042310_fig2

Step 3: Initiate a connection to a remote database; while my slapdash SQL interface has a button labeled “connect,” many applications will be less clear about when a connection to a database is created. When I start the connection, Echo Mirage intercepts all the packets that I’m sending to the database. Note that even though the connection string is available, many recent implementations of SQL will encrypt the password before it goes over the wire.

Figure 3: Connection strings! My favorite!

ma_042310_fig3

Step 4: Create a query. It will be automatically intercepted by Echo Mirage, and you can relay whatever malicious queries you want. In another application this step could be running a search, updating a record, or generating a report. When sending your request, one limitation of Echo Mirage becomes apparent: it is unable to change the size of the data sent. What this means for a potential attacker is that sending a larger query allows for more space when injecting. There is little worry of sending a query that is too large; if you have extra space at the end of your injection simply comment the rest out.

Figure 4: This is the query as sent from my interface

ma_042310_fig4

Figure 5: Echo Mirage captures the request

ma_042310_fig5

Step 5: Now that you have the query captured in Echo Mirage, overwrite some characters to inject. Try not to disrupt the formatting and only overwrite characters that were actually part of the query you sent.

Figure 6: The edited query, prior to sending

ma_042310_fig6

Figure 7: The results of the edited query

ma_042310_fig7

I hope this demonstration hits home and proves the necessity of input validation and parameterized SQL queries, even in thick client environments. As tools like Echo Mirage mature, this type of attack will only become more common and more dangerous.

Permalink | Email the Author | No Comments

Tags: Echo Mirage, NetsPWN: Assessment Services

Botnet Detection and Dynamic DNS

Michael Anderson | Tuesday, October 20th, 2009

The Internet is a vast and unforgiving wilderness; every day, some new monstrous beast rears its ugly head and threatens the hapless denizens of networks everywhere. The only thing standing between those Internet citizens and complete ownage is the security industry. This means that we have to adapt to the newest and biggest threats on the Internet. Recently, the industry has shown its vulnerability to a particularly nasty threat: botnets. This malware is dangerous because it is difficult to detect before some workstations start broadcasting administrator passwords, online credentials, or even credit card and social security numbers. What’s more, botnets can adapt to hide from common detection techniques and antivirus configurations. Prevention is, of course, the best answer, but it can’t be the only line of defense. Pfizer lost some serious credibility when its networks started uncontrollably spamming people with offers for Viagra (a product they make), and as recently as September it was revealed that over half of Fortune 100 companies had networks infected with a botnet called Mariposa. The problem isn’t a simple one.

More recent approaches to botnet detection have come in the form of network-based detection. Many botnets rely on dynamic DNS solutions to obfuscate data collection centers, and David Dagon wrote an interesting presentation on DNS-based detection of forming botnets. These dynamic DNS solutions tend to be abused by botnet owners, allowing them to hijack hundreds of third-level domains from dynamic DNS servers for use in controlling botnets or aggregating data. Fortunately, this means that the botnet will require a lot of DNS traffic during formation, and this footprint allows for easily isolation of the infected hosts, before they transform into a rampaging swarm of zerglings and spew your data all across the Internet. It won’t save anyone from an already formed botnet, and it won’t prevent a distributed denial of service attack that originates externally, but it’s another layer of protection for internal data.

Permalink | Email the Author | No Comments

Tags: botnet detection, dynamic DNS