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.
Secure database configurations are important. However, many database administrators fail to lock down accounts that are used by trusted services. As a result, trusted services can often be used as entry points into database servers. Over time attackers have become very efficient at identifying those entry points, gaining access to confidential information, and pretty much being evil. This blog covers MS SQL Server entry points that can potentially be used to execute arbitrary queries via trusted database accounts.
Threats
Never discount the insider threat. Even if the administrator isn’t the culprit, their account can be impersonated and their password can be stolen. Also, insider attacks typically don’t trigger alerts in the same way that brute force attacks do because all of the actions appear to be legitimate from the system’s perspective. That makes enforcing the least privilege on accounts and objects even more important. Below I’ve listed a few accounts types that usually have more privileges than they really should. You may want to keep an eye on them.
Application Database Accounts
Database accounts used by applications typically have more privileges than they need to perform their function. In my experience I’ve found that most database accounts used by applications are assigned sysadmin privileges or actually use the SA account. As a result, every developer with access to the account can execute arbitrary queries and system commands on the database server. Application accounts should really only be assigned the access they require on the associated application database.
Database Administrator Accounts
Of course it makes sense to give database administrators access to manage their own databases. However, nine times out of ten they are able to elevate their privileges and access other databases and systems through inherited SQL Server service account permissions. So only give DBA access when it’s needed, set strong passwords, and audit administrative account activity.
Server Administrator Accounts
Similar to database administrators, local server administrators usually have more power than they realize due to inherited permissions. In SQL Server versions prior to 2008, the local Windows administrators group is assigned the sysadmin role by default. As a result, every local administrator is inherently also a database administrator. The lesson here is: Don’t assign the local administrators group sysadmin database privileges.
Database Service Accounts
In most environments SQL Server service accounts are part of the local administrators group. As a result, service accounts usually have sysadmin database privileges just like any other local administrator account. Shared SQL Server service accounts are another very common problem/practice in large environments because they make managing accounts easier. However, the reality is that the shared service accounts compound the issue by opening unwanted lines of trust between all of the database servers. When using shared service accounts, anyone who can administer one database server can also access data on every other server using the shared service account. Local commands and queries can be executed as the SQL Server service account by executing the OSQL command with the “-E” switch via the xp_cmdshell extended stored procedure. Contrary to what your parents may have taught you, when it comes to SQL Server service accounts, it’s not nice to share.
Entry Points
Below is a list of potential entry points into MS SQL Servers. Generally speaking, a database entry point is anywhere a user or application interfaces with a database. The idea is simple enough, and I think that most IT professionals understand it. What they don’t always understand is what those entry points are, or they forget that any interface used legitimately can also potentially be used by an attacker. The list below is intended to shed a little light into both areas. Most of the entry points can also be used to access other data management systems like Oracle and MySQL. However, I haven’t supplied any details for those platforms.
Database Listener
By default, SQL Servers listen on port 1433. In most cases they are configured to allow connections from anywhere on the network. As a result attackers can attempt to use exploits and weak passwords to gain unauthorized access. Based on my experience, there is at least one SQL Server account configured with a weak password. There are a number of tools to help identify such accounts. I like to use the SQLPing3 scanner. It does a good job of identifying SQL Servers and weak account passwords with the right word list. It also does a good job of finding SQL Servers on non-default ports along with all of the associated instance information. If you’re not a fan of SQLPing3, pretty much any vulnerability scanner will find the default database credentials for a SQL Server on the default port. The general idea for this bullet is to patch regularly and set strong passwords for all database accounts. If you’re using SQL Server 2005 or later I suggest inheriting the local or domain account policies to help enforce strong passwords.
ODBC
Open Database Connectivity (ODBC) is a middle layer of software that helps facilitate communication between applications and database servers. If an ODBC connection is already configured, it can be used to execute arbitrary queries against the database server through applications that use it. Examples include but are not limited to, Access, Excel, and Word. Additionally, some configurations allow attackers to extract usernames and passwords from ODBC configuration files. For example, Cain & Able has a nice ODBC password extractor for SQL Server 2005. If the password is recovered, attackers can connect directly to the SQL Server using SQL Server Management Studio.
Client-Server Applications
I think a lot of developers are under the impression that if a client application’s GUI doesn’t give users the option to execute arbitrary database queries then it’s not possible. Unfortunately that is far from the truth. Many applications can be decompiled with tools like .NET Reflector and the Boomerang Decompiler. Once decompiled the connection strings are often accessible in clear text. In some case the connections strings can even be accessed with a hex editor prior to being decompiled. Also, tools like Echo Mirage can be used to intercept and modify network traffic between the application and the server. Users and attackers can actually conduct thick application SQL injection by modifying the database queries in the TCP payload. If you’re interested, Mike Anderson wrote a brief blog on the subject which is available at http://www.netspi.com/blog/2010/05/04/echo-mirage-piercing-the-veil-of-thick-application-security/. The take away here should be to obfuscate or encrypt your code, and encrypt all application communication with the server.
Web Applications
Web applications present a number potential entry points. My goal today is not to provide a comprehensive list, but I will include some examples. If an attacker can access clear text connection strings in source code or configuration files such as the web.config, then the attacker can user them to connect to the backend database. Vulnerabilities that provide read access to such files vary from application to application, but the result is the same. If you are using clear text connection strings, consider encrypting them or using integrated authentication. SQL injection is another big one, which I’m sure doesn’t come as a shock to anyone. In many cases SQL injection can be used to bypass firewalls and execute arbitrary queries on the backend database. For SQL injection use common sense and best practice coding methods. I would spend more time on solutions for SQL injection, but there are volumes on the subject available online. Finally, some web applications actually support the functionality to build SQL queries on the fly. Technically it doesn’t qualify as SQL injection, but it definitely has the same result. The fix? Don’t do that.
Web Services
There are surprising amounts of web services running applications behind the scenes out there. I’ve seen quite of few used by both web applications and client-server applications. SOAP, REST, and RPC web services all still seem to be pretty popular right now. Overall, SOAP web services seem to be used more by web applications, and REST/RPC web services seem to be used more by client-server applications. Regardless of the web service type, I’ve seen many of the same issues that affect traditional web applications causing security holes that provide attackers with arbitrary query access.
While assessing the security of your database servers make sure to consider more than the local database configuration. While the local database configuration needs to be secure, connections from trusted services can also be used as entry points by attackers. Make sure to lock down accounts from those trusted services or you may be unwittingly providing full database access to internal and external attackers.
Long gone are the days when you could update your version of Nikto, set some mutation parameters, point it at a web site, and feel good about the results. This ancient technique isn’t even sufficient for today’s “simple” information retrieval apps, let alone complex apps that have crossed the Web 2.0 sphere and mimic the fat clients of yesteryear. Modern vulnerability scanners attempt to address the sophistication of today’s complex web apps by adding more intelligence to the scanning engine and capability into signature constructs. However, is it really possible to perform an adequate level of risk assessment using purely automated processes?
In this series of postings, we will examine some of the challenges of assessing the security of complex web applications, including those related to features of the yet to be finalized HTML version 5 (HTML5) standard. We will further discuss the role of automation; it may not be dead, but it certainly needs a lot of hand holding.
Where do the scanners break? Or more appropriately, where do they fail to adequately test web applications so as to provide accurate results? The same place that provides the greatest complexity and feature rich capabilities to modern web applications; Asynchronous Javascript and XML, or AJAX for short. What is AJAX? Basically it is a set of technologies that enable a client browser to perform a background exchange of information with a web server without having to reload web content. It involves several components which work together:
HTML and CSS (of course)
The Document Object Model (DOM) – client side objects which contain definitions and values that may or may not be rendered to the user but are made available to scripting languages, such as JavaScript, through the DOM API for manipulation
XML for the structured exchange of data (optional)
JavaScript (or other client side scripting language – e.g. VBScript)
XMLHttpRequest (XHR) – an API used by scripting languages to send/receive information asynchronously from the server
An example of all this in action is the Google maps application. All the interactivity involved in dragging the map canvas, displaying markers, populating markers with information, drawing direction vectors, and dynamically changing direction vectors are all provided by means of AJAX.
Is it secure? Even the most expensive point-and-click web scanners have a tough time answering that question. They are designed to crawl, identify parameters, inject, and monitor results for content that it is programmed to recognize as evil. Depending on the complexity of the client side scripting, fully automating these types of tests may be virtually impossible.
What’s the answer? That’s the subject of the next part in this series.
Subscribe to NetsPWN: Assessment Services Blog
