Back
How DirectDefense Gained Unauthorized Access To Your Networks and Applications This Year?
We are almost to the end of another year, and it has been a busy one for us here at DirectDefense. In addition to performing our normal engagements, such as performing network and application penetration tests, we have also enjoyed a lot of positive feedback from our presentation series – Catch me if you Can.
During the course of the presentation, we discuss a series of techniques that we’ve been using for the past 12+ years to gain unauthorized domain administrator access while performing internal assessments. Besides showing these simple techniques, we spend the majority of the time in the presentation discussing ways to identify some of these techniques as well as how to establish alerting triggers and solutions to help administrators identify an attack in process.
So in an effort to continue to provide our clients with some inside knowledge in how we (and the “bad guys” out there) are continually gaining unauthorized access, let’s discuss the top five methods we leveraged this year to penetrate your networks and applications.
#1 – SQL Injection – Be it an external penetration test or a comprehensive application assessment, we found way too many applications with SQL Injection vulnerabilities this year. This type of vulnerability is well over 10 years old, but seems to still be a significant issue for developers. While we can share that we do see the trend lowering due to the adoption of newer development frameworks such as .NET 4.5 and higher, there are lots of older applications still in use that have gone untested…until now.
One trend we saw this year was that organizations are going back and testing applications that have normally gone untested. To single out one point of commonality, we saw a lot of older (2+ years) Java and Oracle applications being submitted for testing this year. Though the stats may vary by organization, as much as 40% of the applications we encountered had easily identifiable SQL injection vulnerabilities. Another 20% of the applications had trickier blind or time-based SQL injection vulnerabilities, which while a bit more difficult to find, are still easily exploitable with modern tools.
Due to these vulnerabilities (and based on the rules of engagement), we compromised quite a few databases and applications and in a few instances were allowed to take the vulnerabilities all the way to a full corporate compromise.
#2 – Weak Passwords – Nothing new here, but for some reason we still are missing the mark with eliminating the use of default or weak passwords in our applications and networking environments.
- Externally –We attacked lots of websites and their Content Management Systems (CMS). Be it WordPress, Joomla, or Drupal, all CMS solutions create many attack opportunities. One of the easiest to exploit involves simply enumerating all of the users that have administrative access to the CMS application and then figuring out where the login page is. Once this is accomplished, we then perform a simple brute force on the user’s password to gain access. We’ve found that 1 in 5 admin accounts are using simple passwords that can be guessed in less than three hours. Once in, an attacker can do as they please, including putting their favorite key-logger java applet on your main login page.
- Externally and Internally –The existence of users with weak domain passwords continues to plague organizations. As highlighted in our post “Your Password Policy is Still Weak, But it is not Entirely Your Fault!”, the lacking features in the Active Directory complexity enforcement routine makes it difficult for administrators to prevent the use of weak passwords like “Password1”. While performing brute force attacks, we still routinely find several accounts that use this password which provides us, and the bad guys too, with immediate access into your corporate network (and/or VPN).
Simple fact – If you do not prioritize finding solutions that work for you to enforce good passwords, while updating your user awareness training to teach users how to select a stronger password, we (pentesters and bad guys) will continue to break into your networks.
#3 – Configuration Vulnerabilities – How well do you harden your server installations? Chances are you may be doing a good job, but that new network or “security” solution you bought and installed did not. This year we broke into a lot of network and security solutions/appliances due to default passwords and configuration vulnerabilities, especially medical solutions that leverage one or more of the 125 default accounts that come with Oracle databases.
Additionally, the most common configuration issue we found was that no one seems to be isolating the administrative interfaces on their solutions these days. You should be designing your networks to isolate administrative access (and interfaces) to a dedicated network segment, or at the very least, a dedicated IP range. This helps reduce the risk of a guest device or workstation from gaining access to the important functions on a device.
Pro Tip – Want to slow us down? Scan your appliances for configuration vulnerabilities before they become production and disable and/or remove all default content and settings that are in the installation and administrator manuals.
#4 – Patching Vulnerabilities – Yeah, Yeah, this is the easiest way to exploit and compromise an organization. Plain and simple, it’s a race. How fast from the time a vendor releases a patch can you get it installed in your environment before a worm or working exploit makes its way to the public?
Anyone reading this article did not know that they should be patching their systems at least once a month? Raise your hand if you did not
We all know we should be, but is it happening? More importantly are you forced to use a not so scalable free solution to try and get your patching done?
Let’s focus on what we are seeing. You guys are doing a good job at patching the Windows Operating System, there is no dispute there, and this has become the norm today. But with that said, most organizations are failing to patch primary and secondary applications (Exchange, SQL Server, and SharePoint to name a few). We also are seeing continual failure with the patching of primary, secondary, and so forth workstation applications – aka third party applications such as Browsers, Java, anything Adobe makes, etc. Finally, the largest failure for most organizations is everything that is not Windows. Linux, and more importantly Apache and JBOSS, appear to be everywhere these days. Either imbedded into the server that runs your VMware services, or on some random VOIP appliance or phone hardware that is running in your environment, patching of such devices is almost non-existent. If you do not find it and patch it, we, and the bad guys, certainly will and we will take advantage of the numerous patches you have yet to install.
#5 – Mobile Applications – Wow, did we have fun this year! Seems that all the lessons on application security that developers learned (or did not learn) in the past couple of years, got thrown out the window while they frantically created their “super mobile enhanced” version of their web applications.
We have to assume that most developers think people are using their mobile applications over the cellular network, and not the Wi-Fi wireless network, because the glaring vulnerabilities such as not requiring the use of SSL encryption for mobile applications is frankly inexcusable.
Note to developers – Most cellular users aged 25 and below use Wi-Fi whenever possible to keep from using up their minutes or their data plans. So please assume a user is using a less secure mode of communication and build solutions into your applications to protect them during these times.
Based on the applications we have reviewed, few mobile applications have SSL encryption enforced properly. Also, the time to live on sessions is extremely high, think weeks and years versus the normal minutes or hours when compared to traditional web applications. We also found that everyone seems to have their java application servers turned to super verbose error mode. Because of this, during testing of a mobile application for say SQL injection, the resulting JSON error messages responds with the full database SELECT query in the resulting error message (just want to thank you for that one).
The final, and most common mobile application vulnerability we have found is a lack of synchronization with authentication and/or state between the traditional and mobile version of the same application. Say you lock yourself out of traditional web application; there is a high likelihood that the mobile version will continue to function for days before the same lockout is enforced, giving the bad guys plenty of time to continue their attacks.
So now that we’ve shared our most common techniques for gaining unauthorized access into your organization’s networks and applications, we hope you have time to plan and implement changes into your environments in the New Year to keep us and the bad guys out, because we promise that we will be planning new techniques to get in.
If you would like to learn more about our security testing services and how DirectDefense can assist your company in developing security strategies and solutions that work, please contact us at sales@directdefense.com.
12.09.13