I recently read an editorial on SQL Server Central by Steve Jones titled “Review Your Code” in which he asserts: “if you write code after today that’s susceptible to SQL Injection, you ought to be fired”.
I am certainly not going to disagree. However, I don’t believe we should narrow the scope of the witch hunt to just the “coders”. If you want to go on a termination rampage after a breach, you should probably look beyond just the code monkeys.
What about anyone who calls themselves an “architect”. If you design a Swiss cheese system to begin with, what do you expect from the engineers?
What about the DBAs? Why aren’t they standing up and demanding the use of parameterized queries to interact with their databases? Or better yet, demand applications interact with the database using only stored procedures so that the application user(s) only need(s) CONNECT and EXECUTE permissions?
What about QA? How does an application get deployed these days without at least some cursory security testing?
If the application is business critical, what about the decision makers? Are they willing to write the checks to perform a REAL penetration test on the application? (Not just a scan)
This list is by no means exhaustive. Depending upon your organization, there are probably plenty of other roles on the development team that should be security conscious too. So when it comes time to hand out punishment after a breach, just firing the code monkey will probably not fix your problem.
I’m often asked about the top vulnerabilities identified in a penetration test, or similarly, the top defensive measures an organization can implement to defend against attacks. Those are great questions, and undoubtedly useful in securing an environment against attacks, but let’s get straight to the point. Those questions, and any defensive countermeasure that go with them, are only HALF the equation. Can you imagine being expected to fly a plane by merely reading the flight manual? There is reading, studying, assignments, tests, and practical exams that go into becoming a pilot.
Likewise, who has ever become great at anything by simply learning about it? This principle can be applied to organizational security, but specifically I’m talking about TESTING. Not the PCI, HIPAA, SOX, or any other fill-in-the-blank compliance testing, but the testing that actually improves security. For you sports fans, Vince Lombardi said “Practice does not make perfect. Only perfect practice makes perfect.” What is perfect practice in the context of information security? The answer is simple. Perfect practice is the type of practice that most accurately reflects and works toward the desired outcome. Applied to the previous analogy, defensive protections without testing is the equivalent of learning to fly a plane by simply reading the manual.
In security, organizations are generally defending against external attacks. According to the 2013 Verizon Data Breach Investigation Report, internal attacks, or the insider threat, accounted for only 14% of all compromises in 2013. Because external attacks are the most common, I’m going to focus on them. However, this strategy applies to all areas of security testing. By now, it is fairly well documented and accepted that most external attacks come through phishing, spam, or some other attack targeting end-users. Approximately 60-70% of all attacks could be summarize like this:
Attacker sends spear-phishing email with malicious link (or some other social engineering technique) to end-users.
End-user clicks the link and workstation becomes infected with malware.
Attacker uses infected workstation to pivot to other high value workstations and servers within the network.
Attacker collects necessary credentials to gather sensitive documents, perform financial transactions, etc.
As necessary, attacker exfiltrates data via HTTP/S channels.
Not all attacks follow this pattern, but the majority do. Why do I bring this up? Because this is the problem I see with compliance and the information security industry. When discussing the scope and methodology of an upcoming engagement with a client, the testing they typically expect involves an external “penetration test” (which is really more like a vulnerability scan), or an internal penetration test, which does not reflect the approach taken by actual attackers. Why let penetration testers inside your network when the attackers are working from the outside? Ultimately, how can organizations improve when we, as an information security industry, are not providing the types of assessments that will help them defend against the current threat landscape they face?
The blame doesn’t stop there. Congress is at least partially to blame for requiring organizations to waste resources and money on compliance that, for the most part, does very little to improve security and defenses against real attacks. Meanwhile, organizations blow their budget on compliance assessments and APT Blocker 2000 products, and, ultimately are left with a false sense of security. It’s a sick cycle and similar to the definition of insanity, we’re all doing the same thing over and over and expecting different results.
So what does this mean and what’s the solution? Most importantly, testing must reflect the goal or desired outcome. Why is this so important? Because as with anything in life, improvement only comes through work and practice. If the goal is to improve defenses against the “typical” attack previously outlined, which is a good place to start, then a Blackbox Penetration Test is the best approach. Few security companies are able to provide what I consider a true blackbox penetration test. Here are the requirements.
The assessment is performed with zero prior insider knowledge of or access to the target organization.
The assessment utilizes custom backdoors, malware, and Trojans to access and exfiltrate the target network.
Within the target organization, only those with a need-to-know, know about the blackbox assessment.
The assessment will be conducted stealthily with the intent to circumvent all defensive measures.
The assessment scope will be as broad as possible, leaving external websites and infrastructure, end-user workstations, and physical access as potential attack vectors.
The success criteria of the assessment includes, at a minimum, domain administrator access, exfiltration of sensitive files, and access to virtualization infrastructure.
Metasploit has become too big, bloated, and invasive to be used for this type of an assessment. While Metasploit has its strengths, the goal should be to simulate and model the assessment after common attack methods. How many blackhat attackers use Meterpreter? Very few…at the most. As an industry we need to step up our game. There are some products that understand this need. For example, Cobalt Strike (and especially the Beacon payload), is a great backdoor to customize what would otherwise be another generic Metasploit attack performed by a penetration tester.
Silent Break Security utilizes custom tools, backdoors, and malware…and by custom I don’t mean a 5 MB python-compiled exe backdoor. A technical background working for the NSA provided an understanding of attack tactics, techniques, and procedures (TTPs) used by actual attackers every day, and that we’ve incorporated into our toolset. To make engagements even more realistic, 0-day exploits are often leveraged in attack scenarios. Organizations need to know the effectiveness of their defenses against a real attack. The only way to provide that insight is to model the testing methodology accordingly.
Below are a couple screenshots of our custom persistent and shell access payloads. The first, named Throwback, provides stealthy, beaconing, persistent access after an end-user workstation gets compromised. The second custom payload, SlingShot, uses reflective DLL injection (provided by Throwback) as a means to provide temporary shell access. Other tools are used and developed as necessary, but the underlying principle is always the same. The point of illustrating these custom tools is not a sales pitch, but rather to show the importance of providing organizations with what they need the most, but just don’t know it yet. Real testing.
Frequently during external and web application penetration tests, we run into SVN entries files on web servers. These files are sometimes created as part of the SVN commit process and can lead to the disclosure of files (and source-code) that has been added to the web directory. This can be especially impactful for assessments, where there may be vulnerable pages (and/or configuration files) that are not clearly advertised from the main web site (i.e.: admin_backdoor.jsp or web.config).
The files are typically laid out in lists of files and directories followed by their type (dir, file) on the next line.
registry
dir
admin_login.jsp
file
Additionally, there may be source files accessible through the svn-base files (i.e.: /.svn/text-base/ExamplePage.jsp.svn-base). You can consider these files like backups of the originals that (hopefully) won’t execute on the server. Sometimes, the server sees these files with their original extension (.jsp) and you may have trouble getting at the source.
The entries files can typically be found in each directory that is used by SVN, as well as any subdirectories. So if a directory shows up in your entries list, it’s worth looking in that directory for another entries file. I got tired of manually going through each of these entries files, so I wrote a script to automate listing the files, source files, and directories into an HTML file. The script also goes into each identified directory to find more entries files to spider.
The script will output a directory named after the directory that you’re starting in (i.e.: DIR), and in that directory will be an HTML file (DIR.html) that you can use to start navigating files. Links to the svn-base files are included on the page and show up with the .svn-base file extension. If you are familiar with the default Apache directory listing page, this should be pretty easy for you to navigate. I’ve also added sorting for the table, just click on Name or Type at the top.
Additionally, I’ve added an option for a second parameter that you can use for outputting the .svn-base files to a directory. Be careful with this one, as you can potentially end up downloading the entire web root.
Mobile devices are becoming more common in corporate environments. As a result, mobile device management solutions (MDM) have cropped up so that employers can remotely manage and wipe devices if necessary along with setting certain requirements that employees must comply with, such as setting a passcode, encrypting the device, and not jailbreaking or rooting the device. It’s certainly not a bad idea to enforce restrictions on devices that may contain sensitive information. However, bypassing some of the restrictions that an employer may put in place it not difficult. This is especially true if someone wants to keep their device rooted. There are many contenders in the sphere of MDM software. For this blog I will be looking at AirWatch for Android. The device I will be using is a rooted Nexus 4 running Android 4.2.2.
AirWatch is an MDM solution that provides employers with the ability to manage mobile devices and enforce policies. An agent is installed on the device and monitors whether the device is compliant or not for specific policies. If a device is found to be non-compliant, the agent phones home to a server, notifying the employer of a non-compliant device.
Here is the default web interface for an AirWatch enrolled device. As you can see, my Nexus 4 is enrolled, is encrypted, and requires a passcode. However, it is still not compliant because my device has been “compromised,” i.e. rooted by myself. A poor word choice in my opinion. The same can be seen on the AirWatch agent.
If we navigate to the compliance section, we can see why we are not compliant.
Again, the agent shows that we are encrypted, but our device is “compromised.”
Digging Deeper
At this point I want to know how AirWatch is detecting that my phone is rooted. I tried removing the su binary and any superuser applications, but that didn’t seem to work. As a rooted phone, we can certainly grab the apk of the agent and tear it apart. That only revealed obfuscated java classes that would take a while to decipher. Next, I tried running strace against the agent process to get an idea of the calls that it is making, hoping that there would be something there that reveals what it is doing to detect root. Again, there weren’t any answers that I could find.
I decided to shelve looking for how AirWatch was detecting root for another day and instead I started focusing on the HTTP request and responses that the agent was sending and receiving. I started burp and setup a proxy on my Nexus 4. There is a fair amount of traffic that goes between the AirWatch agent and the server it’s talking to. One request in particular caught my eye.
This AirWatchBeacon checkin request. I omitted some of the more sensitive information in the request. As you can see there is an “IsCompromised” field in the request that is set as true. So I change that to false and sent the request off. After refreshing the web interface, my device is no longer compromised.
The agent also shows that my device is no longer compromised.
So now we know how the agent is checking into the server and whether or not your device is compromised. By changing a simple flag, we now control that. Furthermore, there doesn’t seem to be any type of session information related with the request. We can replay the same request hours, even days later, and the server will accept it. The only downside now is that the agent will periodically do a check-in request with the server and report that the device is compromised. It’s a hassle to send a non-compromised request every time we want to be compliant. The first step I took in resolving this issue was to look at the AirWatch configuration options in its SQLite database.
Using the SQLite Editor app from the Android market, I open up the AirWatch database with root access.
Selecting the AirWatch database reveals a number of interesting tables.
The profileGroupSetting table is where most of the AirWatch configurations are stored.
There are a few rows that look interesting. The ones that contain interval in the name seem to set how often the AirWatch requests are sent. I tried changing the BeaconInterval to large values to see if it would take longer for the check in requests to be sent. That didn’t seem to work. Neither did setting the value to zero or a negative value. For the most part, setting the interval values do not seem to do anything in my testing.
There is, however, another way to stop AirWatch from sending out request. Modifying the Android hosts file to block the host that the requests are being sent to. The Android hosts file is located in /system/etc/. Again, you have to be root to be able to modify the hosts file. I modified the hosts file to redirect the requested host to my localhost. The requested host is going to be different for every company, so I won’t be showing that. It’s been well over a week and my device has still not checked in and still shows that I’m compliant.
The only downside to not checking in often is that your device will show as not being seen for sometime. You employer may have a policy in place to remove devices that AirWatch shows as being inactive. One way to mitigate this is to periodically send out the checkin request yourself. Simply setting up a cronjob with curl to send out the checkin request work very well.
Finally add the bash script to your crontab by running “crontab –e” to edit the crontab and add the following at the end of the file:
0 */2 * * * /root/command.sh
This will cause the script to run every two hours.
Conclusion
MDM solutions are great for employers to manage mobile devices. However, they are not without their problems. Not only was I able to bypass compliance for having a rooted device, but I was also able to bypass the need to encrypt my device from the profileGroupSetting table. Bypassing compliance restrictions for AirWatch is relatively trivial after a few hours and I’m sure it is probably similar with many others MDM solutions.
Update – 09.13.13
Eric Gruber: AirWatch states that it has addressed this issue by recommending that clients enabled a security configuration setting called “secure channel” which according to AirWatch protects against Man-In-The-Middle attacks by using mutual X.509 message-level certificate signing and encryption between the client and the server. For AirWatch hosted customers, this options is now enabled by default and cannot be disabled.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
Name
Domain
Purpose
Expiry
Type
YSC
youtube.com
YouTube session cookie.
52 years
HTTP
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Name
Domain
Purpose
Expiry
Type
VISITOR_INFO1_LIVE
youtube.com
YouTube cookie.
6 months
HTTP
Test
test.com
Testing
7 days
HTTP
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
We do not use cookies of this type.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
We do not use cookies of this type.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
We do not use cookies of this type.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Cookie Settings
Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.
Back
