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 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.
Figure 2: After launching the application, the red text demonstrates that Echo Mirage is intercepting traffic from the target process.
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!
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
Figure 5: Echo Mirage captures the request
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
Figure 7: The results of the edited query
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.
In simple terms, IP traceback allows for the reliable identification of the source of IP traffic, despite techniques such as IP spoofing. While there are numerous methods for achieving this goal, they all have one thing in common: not one of these methods has actually been implemented in commercial networking equipment. Maybe its time has finally come.
The advantage of such a capability lies in determining the sources of one-way attacks, or attacks that can be conducted using spoofed source IP addresses. Unlike Reverse Path Forwarding, which can prevent address spoofing in limited environments, IP traceback essentially allows packets to be postmarked with the true source IP address. Denial-of-service (DoS) attacks are the most common type of malicious traffic that falls into this category. Although they don’t usually get the sort of visibility that they used to, DoS attacks still occur with astonishing frequency. While there are other methods for determining the source of spoofed traffic, they are typically time-consuming and require the involvement of numerous upstream parties. IP traceback could allow a network administrator to determine the source of such malicious traffic.
In a grad school paper I wrote a few years ago, I argued that “without the support of major networking equipment vendors or ISPs, and barring a major attack with far-reaching consequences, there is little hope for IP traceback in the near future.” Today, the question is when do we reach the point that the ability to reliably track the source of malicious IP traffic is deemed important enough to demand a feature such as IP traceback? Such an ability is more important than ever.
At the same time, there is a question of how effective such a solution would be if it were only partially implemented. Getting ISPs in North America and Europe to implement such a feature is a big enough step, but what practical value would IP traceback have if it were not implemented at the sources of much of the world’s malicious traffic: places like eastern Europe, Russia, China, and North Korea?
Despite such a potential limitation, I believe that there is a still a place for IP traceback in our networks. A software-based solution, which would require only firmware or driver updates, would be relatively inexpensive and simple to deploy. At the same time, it would assist network administrators and law enforcement in investigating attacks that use IP spoofing techniques, thereby creating an effective deterrent against such attacks.
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.
Devices such as printers, photo frames, phones, and webcams are often considered an afterthought during a typical security assessment. A study released by the Stanford University Security Laboratory, however, has demonstrated that the web-based management interfaces embedded in these devices may introduce greater risk into your network than you would think.
Unless it’s possible to access the underlying code of these interfaces, organizations are faced with three options: remove the device from the network, ask the vendor for a patch, or accept and minimize the risk via access controls. For most organizations, the first option isn’t reasonable. As for the second option, organizations are left at the vendor’s mercy in terms of when, and if, a patch will be released. The third option may be sufficient, but places no pressure on vendors to fix these issues. Additionally, as mandatory security standards such as the PCI DSS continue to become prevalent, it’s a matter of time before these devices could be forced into the limelight.
Many organizations that release web-based applications are expected to bake security into their software development life cycle, as well as to audit these applications and release patches on a regular basis. It seems the root of the problem stems from the lack of pressure on these vendors from the users of these devices. Often times, devices such as IP-based cameras and photo frames are placed on networks without admins being aware of it. Even devices that admins are aware of, such as printers, are often overlooked during security assessments. Budgets are limited, and security assessments are often focused on more pertinent areas within the network, such as mission-critical server infrastructure. An auditor can’t tell you to repair vulnerabilities on devices that are out of scope or that they are unaware of; as far as the client is concerned, these vulnerabilities may as well not exist. In turn, vendors will be under little to no pressure from their clients to patch these often-overlooked vulnerabilities.
In regards to the vulnerabilities themselves, many of the findings in the paper did not seem to be all that “new” so much as simply unnoticed. Many of them were simple issues surrounding a lack of input and output validation via standard web forms. However, the paper did mention a new form of attack known as XCS, or cross-channel scripting. In the past, these types of attacks were often launched via HTTP. XCS, on the other hand, exploits cross-site scripting vulnerabilities via non-traditional communication channels such as FTP, SMB, and SIP. For example, a tag such as <script>alert(123)</script> may be embedded in a spoofed caller ID created via SIP. This script tag will be stored in a log; once the admin views the log via the web-based management interface for the phone, an alert box with the numbers “123” will appear on the admin’s screen. Obviously this won’t accomplish much beyond annoying an admin, but if the script were to be used to steal the admin’s session, the attacker could then take unauthorized actions in the interface with the admin’s privileges. Depending on the nature of the interface, the attacker could do pesky things like changing the ringtone of every phone on the network to a Rick Astley tune (click at your own risk). Alternatively, an attacker could potentially take down an entire company’s IP-based phone system, thus causing hefty amounts of financial damage in lost productivity and consumer confidence due to downtime.
We all have limited resources and have to choose our battles when it comes to security assessments. Still, I would highly recommend giving the white paper a skim, if not to get an idea of the potential risks associated with these often-overlooked devices. I’m waiting for a news story about someone taking over an entire network via an IP-enabled photo frame (if you see one, let me know). Maybe it won’t happen any time soon, perhaps never; but if it does, organizations may have to think twice about that seemingly innocuous printer gathering dust in the back of the office.
Mozilla is known to most people for its open-source and free software, most notably Firefox. However, starting around August 4th, it also became known as yet another company whose merchandise store was breached. Following the announcement on the company’s blog and closure of Mozilla’s store, the following headlines filled trade pubs and the blogosphere: “Mozilla Store Breached” - PC Magazine, “Mozilla shuts Firefox e-store after security breach” – Computerworld, and “Mozilla Store Security Breached” - InformationWeek.
A careful reading of these articles, however, revealed that the breach did not happen by any fault of Mozilla; rather, it was caused by a company called Gateway/CDI, a third-party e-commerce processor. Even though most news stories about the breach mentioned this critical fact, my conversations with non-techie friends proved that such details went largely unnoticed and that Mozilla was viewed as the guilty party. This only goes to prove that unless the reader has a reason to take an interest in the story, the headline will be the only thing read. Unfortunately, headlines such as “Mozilla shuts down online store after third-party security breach” (SearchSecurity.com) are rare and tend to appear only in technical and security-oriented news sources.
What all this adds up to is that when considering the outsourcing of storing, processing, or transmitting critical data to a third party, organizations must recognize that in the event that such a third party is breached, it will be their name in the headlines, not the vendor’s.
The solution is for companies to carefully evaluate whether outsourcing is really the best option for them and for their clients. Personally, I think that companies are outsourcing too much, completely ignoring the risks associated with letting your data outside of the trusted network perimeter. However, if outsourcing still makes business sense, careful attention must be paid to ensuring that the vendor takes all appropriate precautions to make sure your data remains safe. Ideally, this should be done during the initial negotiation, as that will be the time when a client has the most influence and power over the vendor. Typical validation steps may include a combination of any of the following tactics:
Ask if the vendor has a SAS-70 on file. (Make sure it explicitly covers the service you are purchasing, and request an independent review of the report to make sure it was provided by a reputable audit firm.)
Involve Internal Audit to request that the vendor fill out a questionnaire, indicating its information security practices. Make sure to ask for proof for some of the most critical controls.
Hire a security consulting firm to perform an independent audit of the security controls the vendor has in place.
Request your internal information security team to perform a thorough review of the vendor’s security controls.
The most important thing to remember is that even though your organization may be outsourcing to a third party, the overall responsibility for the protection of the data in the eyes of your current and future customers will always remain with your company.
Subscribe to Technology Blog
