Why is it my credit card was disabled while I was on vacation, for me to come home to a generic letter from my bank stating that “some data loss has occurred” and that “for security reasons, a new credit card has been issued”?
The banking app I was using, in one way or another was probably owned, which resulted in financial loss for my bank, as well as a significantly less enjoyable vacation for yours truly. Other potential scenarios:
You log into your bank account, and all of your money is gone; the app used to access to your financial assets was owned.
You’ve noticed a sudden loss in clients, and a sharp gain in the success of one of your closest competitors; the app containing all your intellectual property and sales information was owned.
Your personal blog has become blacklisted by numerous antivirus software suites as an unsafe page; the app hosting your blog was owned.
But how, you ask? Many vendors of apps that you use every day pay top dollar for application security assessments from some of the brightest minds in the industry, so you’d expect that the security within these apps would be locked down tighter than the grease in your oven. So why is it that we continue to see (or feel) the pain of application compromises in the news and in our own lives?
In short, even some of the “best” in the security industry sometimes slip and fall when it comes to performing application security assessments. Assessing an application, in some ways, can be more of an art than a science. While many apps use common frameworks and technologies, all apps are, by nature, unique. Running automated scanning tools, while useful, is simply not enough; unless the distinguishing features of each app are taken into account during testing, the assessment will not be complete.
In order to perform a true security assessment of an application, one must fully understand how the application is- and more importantly isn’t- supposed to work. While many consultants may take a more blind approach in an attempt to simulate a “realistic” attack scenario, they are essentially cutting off their own hands; this would be analogous to a car mechanic trying to check your engine with the hood closed. To make the most efficient use of the consultant’s time that the app owner has paid for, it’s critical to take a white box, or open view, approach to the assessment, to ensure the consultant can understand the unique qualities of the application and focus their efforts in key areas. What key areas? Well, that’s the whole point; it depends on the application.
Each application assessment should begin by gathering information surrounding the application. NetSPI then goes a step further by walking through this information and reviewing, step by step, the functionality and intended purpose of the application with a “master” user, typically a developer or application lead. Through this master-apprentice model of learning, NetSPI is able to quickly gain knowledge of the intricacies of the application, as well as conduct an active conversation with the client to develop a test plan which focuses testing efforts on areas that would otherwise have been missed. Due to limited time and budgets, no test will run forever, so it’s critical to understand and focus testing on areas of the app that most significantly impact the underlying business processes.
So every day when you login to your bank account and the cash is still there, when another business day goes by without any blips, and when Uncle Frank and Aunt Marsha can still access your blog to see pictures of the kids without the old AV’s bells and whistles exploding, we can rest assured that somewhere, somehow, the app’s security has been verified through a true assessment… and if not? Well, we can at least know the bad guys haven’t cracked it yet. Or, uh, at least they haven’t targeted you yet.
As vulnerability assessments continue from quarter to quarter, some vulnerabilities seem to appear, disappear, and reappear again. Some appear that were never seen before, despite the fact the affected software has been in use for over a year. If you’re in charge of remediating these vulnerabilities, you may be left scratching your head in puzzlement. Was the vulnerability remediated? Was it reintroduced to the environment? Did the scanning tool fail to catch it in a particular quarter? The short answer is yes. The long answer?
Vulnerabilities can appear and disappear for a variety of reasons. Sometimes vulnerabilities will disappear due to being remediated, even if the remediation is unintentional. For example, a code-related vulnerability from last quarter doesn’t appear in this quarter’s scan. When you congratulate the development team on fixing the issue, they say “What? Sorry, we haven’t gotten around to fixing that one yet.” What happened? The server team applied a patch to the OS of the server the application was running on; the patch added new security functionality that unintentionally also fixed the code-related vulnerability, but no one realized it happened. Next quarter, the server team has rolled back the patch due to issues with a separate legacy application, and the vulnerability appears again. The next quarter, the server team turns off the affected server for maintenance during the time it was supposed to be scanned, so once again, the vulnerability disappears from the report, and all seems well. The next quarter, the server is turned back on, the development team adds new functionality to the application that requires additional services to be run on the server, the vendor’s scanning tool receives a huge plugin update with hundreds of new checks, and one of the new checks leads the security consultant to manually discover a high-severity issue which allows the complete compromise of the server. All of a sudden, a huge blob of risk has fallen in your lap, your boss’s left eye is twitching more than it usually does, and you have no idea how to rationalize what happened, much less explain it in an easy to consume manner. What do you do? Use the abbreviated cheatsheet below, which illustrates the most common sources of vulnerabilities’ disappearing and reappearing acts:
Source
Vulnerability
Trackable?
How?
Disappears
Appears
Intentional remediation of vulnerabilities
X
Yes
Ask owner
Unintentional remediation of vulnerabilities
X
No
-
The availability of services during scanning
X
Maybe
Review logs, ask owner
The addition of services since the last scan
X
Yes
Review systems, ask owner
Updates to plugins/tool set
X
Yes
Ask vendor
Manually discovered results
X
Yes
Ask vendor
Vulnerabilities can be hard to track, but with a bit of elbow grease and a convenient table provided by a reliable, intelligent resource (cough), you can hopefully be well on your way to eradicating the mystery of the vulnerability disappearing and reappearing act.
FireSheep, at this point, is somewhat old news; even when FireSheep was released, the issue it exploits “under the hood” has been old news for a number of years. If you haven’t heard of it yet, FireSheep is a FireFox extension that greatly simplifies the process of stealing another user’s HTTP session. By simply downloading and installing FireSheep, someone with less $k1llz than a scr1pt k1dd13 can easily double-click their way into accessing another user’s Facebook, Twitter, or a variety of other accounts. The extension works by sniffing unencrypted traffic, including cookies that let applications like Facebook know that you are in fact, well, you. There are some limitations on when and where the extension will work, but nonetheless FireSheep has quickly raised awareness within the general public on the pervasiveness of the issue.
While the average person may not understand exactly how FireSheep works, awareness of the end result is fairly obvious and hits home quickly. While the extension is rigged to be an easy “point and shoot” for well known sites such as Facebook and Twitter, the concept could be easily transferred to any application that fails to send session information over a secure channel, including yours. Even though HTTPS is used to protect the login process, the cookie containing the user’s session information is thereafter sent over HTTP. With a few tweaks to FireSheep’s source it would be just as easy to “point and shoot” the extension at your app, allowing session hijacking through a few clicks.
The moral of the story? As always, layer up. If possible, use the “Secure” attribute when setting session cookies to ensure that the cookie is only passed over HTTPS. Configure your application such that it runs entirely over HTTPS, or at least anywhere that session information will be passed between the client and server. If you’re using Apache, you can use the SSLRequireSSL directive to deny access when SSL isn’t used for an HTTP request. While there are a number of measures that can be taken client-side to try and combat the threat of FireSheep, ultimately the issue lies within the service provider. Depending on the application and its surrounding infrastructure, it may be a somewhat costly endeavor to make the switch to HTTPS; as with all changes, the cost must be justified. If the benefits of end to end encryption aren’t hitting home with the right people, consider setting up a quick FireSheep demo to illustrate just how easy it is to exploit the issue. If jaws drop as you update a (volunteer) coworker’s Facebook status on the projector within 10 seconds of them logging in, you’ll know you’re in good shape.
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.
