Penetration Testing  

The following post is a guest blog by Bo Weaver, Senior Penetration Tester at CompliancePoint. If you're attending UNITED, you can catch Bo's talk at 11:45 AM on Thursday, September 14 in the Phish, Pwn, and Pivot track. Hi! I’m Bo. I’ll be speaking at Rapid7’s UNITED Summit in Boston this week, and Rapid7's community manager asked me to write a little blog about my talk. I marvel how on the net we make up new words for a common digital thing—even spell check says "blog" isn’t a word! I know what a "bog" is and I know in our line of work a "blob" is a large chunk of data in a database table. Living in the mountains makes finding bogs kinda hard, but the chunk of word data below is swampy enough to qualify. I’ve worked in the security field for over twenty years. Long before the Internet I worked in private security, mostly undercover on corporate and industrial espionage. This was back in the day when you actually had to physically steal stuff. I also did a lot of work in Executive Protection. My Internet career started even before that when I was in the Navy: I studied as an Electronic Technician while in school; we all worked on a little R&D project called ARPANET. While working on this I never thought that it would turn into what it’s become! In the 90s I did a lot of work with BBSes and then dialup ISP in the Southeast—mostly securing these networks. Since then I’ve had about every network security job there is. I've learned a lot over the years, and I'll be sharing some of that knowledge at UNITED. My passion has always been hacking. For roughly the last 5 years I have been working for Compliancepoint, an Atlanta-based security consulting company as a senior penetration tester and security researcher. The thing I love most about my job here is that we test everything from Mom and Pop companies running an online business to major corporate and government networks. We get to see it all. My talk at UNITED is about reducing complexity and how even big problems can have relatively simple solutions. Sometimes organizations think they need to throw millions at a problem when some time, some knowledge, and little expense can fix even major issues. I learned about KISS in engineering school and have never forgotten: “Keep It Simple, Stupid”. Doesn’t matter if you’re building a toaster or a world network. Kiss it! See the full UNITED agenda here.

By Deral Heiland IoT - IoT Research Lead Rapid7 Nathan Sevier - Senior Consultant Rapid7 Chris Littlebury  - Threat Assessment Manage Rapid7 End-to-end ecosystem methodology When examining IoT technology, the actionable testing focus and methodology is often applied solely to the embedded device. This is short sighted and incomplete. An effective assessment methodology should consider the entire IoT solution or as we refer to it, the IoT Product Ecosystem. Every interactive component that makes the product function is included in this IoT Product Ecosystem. Embedded device and associated sensors receivers and actuators Mobile application and or command and control software Cloud API and or associated web services Network communication protocols: Ethernet 802.11 Wifi Intra-component communication such as Zigbee, Z-Wave, Bluetooth, etc. Rapid7's motivations behind examining the entire ecosystem is to ensure all components of the technology are secure. Failure of any component of the product ecosystem can and will affect the overall security posture. As an example, a failure in the cloud API security can easily lead to unauthorized access control of the embedded hardware, allowing a malicious actor to carry out attacks that could potentially impact the safety and security of the product user. In the following sections we discuss the various areas and processes that should be a focus to ensure a thorough assessment of an IoT product ecosystems is conducted. Functional evaluation When conducting a test on an IoT product's ecosystem, first and foremost an IoT product should be set up and configured within normal specifications. We generally prefer to set up two separate environments, which will better facilitate vulnerability testing, such a cross account and cross system attack and can also be used to make comparisons between normal and altered configurations. Leveraging a fully functional environment, we can then more effectively map out all functions, features, components and communication paths within the products ecosystem. Using this data we can next build out a test plan, which covers the products ecosystem from end-to-end. Device reconnaissance We start each IoT security assessment by conducting reconnaissance and open source intelligence gathering (OSINT) to enumerate information about the components and supporting infrastructure. This enumeration can include, researching the make and model of the components and software used by the device, and identification of any external presence that makes up the cloud component of the product. Cloud focused testing IoT technology uses various web services for remote control, data collection, and product management. Often web services and cloud API can be the weakest link within an IoT product ecosystem. To validate the security, we conduct a very comprehensive assessment of the associated cloud services using functions and communication between the cloud services and all components in the product ecosystem. This allows us to validate the overall security posture of the product and determine impact and risk caused by security issues between components of the ecosystem. This also includes focused testing of the OWASP Top 10. Mobile application/control system-focused testing Generally IoT technologies commonly leverage various forms of remote control services such as mobile application (android, iOS) to remotely manage and control IoT technology. During this phase of testing we conduct in-depth testing and analysis of the mobile and remote application used to manage the IoT product. Again similar to the cloud testing, Rapid7 tests all functions and communications between the mobile applications and all components in the product ecosystem to validate the overall security posture of the product. This testing also focuses around the OWASP mobile top 10 to assure the application meets all security best practices. Network-focused testing IoT technologies commonly expose services via standard network communication paths such as ethernet and wifi, which can create an elevated level risk. During this phase of testing, we will identify all exposed TCP and UDP ports within the IoT ecosystems infrastructure. With this list of ports we can then conduct a thorough penetration test to identify all vulnerable or misconfigured services, which can be leveraged to compromise the system and or gain access to critical information. Physical inspection We also perform a physical inspection to assess the physical attack surface of an IoT device. This inspection includes examining the device for JTAG and Serial pin-outs, as well as identifying the pins used for power, data, and control of individual components. Each device will have different components or elements but some common attack vectors include: Exterior USB Access Exterior port access Location and medium of storage Availability of debug console access Availability of serial console access Efforts required for disassembly of the device Risk to compromise based on brief physical access to the device Risk to compromise based on extended physical access to the device Risk to compromise based on allowed connectivity medium (Wireless, Wired, Bluetooth, etc.) Physical device attacks Physical inspection of the device is key to identifying the most logical physical attacks. After inspection, we conduct physical tests against the IoT device. Though these attack vectors may differ, they often follow common themes. Often, this testing will resemble the following actions: Compromise through available ports. Circumvention of device protections such as boot loader restrictions or restricted bios. Access to modify the configuration of the device. Access to storage to pull configuration keys used by the cloud component. Access to firmware that would otherwise be restricted. Access to the console or logs to isolate traffic destinations during communication with the cloud component. Radio-focused testing Most IoT devices also use radio based communication (RF) methods. We focus our communication testing methods to identify security issues to help determine risk and impact. To accomplish this we conduct specialized testing and analyses of the radio-based communication to identify if the communication: Conforms to expected encryption techniques. The component pairing processes cannot be subverted. Allows unauthorized access or control. Can be easily used to map out the underlying command and control traffic Is vulnerable to replay attacks. Need help securing your IoT devices? Check out our IoT Security Testing Services to learn more.

By Emilie St-Pierre, TJ Byrom, and Eric Sun Ask any pen tester what their top five penetration testing tools are for internal engagements, and you will likely get a reply containing nmap, Metasploit, CrackMapExec, SMBRelay and Responder. An essential tool for any whitehat, Responder is a Python script that listens for Link-Local Multicast Name Resolution (LLMNR), Netbios Name Service (NBT-NS) and Multicast Domain Name System (mDNS) broadcast messages (Try saying that out loud 5 times in a row!). It is authored and maintained by Laurent Gaffie and is available via its GitHub repository, located at https://github.com/lgandx/Responder. Once you find yourself on an internal network, Responder will quickly and stealthily get user hashes when systems respond to the broadcast services mentioned above. Those hashes can then be cracked with your tool of choice. As Responder's name implies, the script responds to the broadcast messages sent when a Windows client queries a hostname that isn't located within the local network's DNS tables. This is a common occurrence within Windows networks, and a penetration tester doesn't need to wait too long before capturing such broadcast traffic. Behold our beautiful diagram to help visualize this concept: Due to the client viewing any reply as legitimate, Responder is able to send its own IP as the query answer, no questions asked. Once received, the client then sends its authentication details to the malicious IP, resulting in captured hashes. And believe us, it works - we've seen penetration testers get hashes in a matter of seconds using this tool, which is why it is used early within an internal engagement's timeline. If no hashes are captured via the first method, Responder can be also be used to man-in-the-middle Internet Explorer Web-Proxy Autodiscovery Protocol (WPAD) traffic. In a similar manner to the previous attack, Responder replies with its own IP address for clients querying the network for the “wpad.dat” Proxy Auto-Config (PAC) file. If successful, Responder once again grabs the hashes which can then be cracked, or if time is of the essence, used to pass-the-hash with PsExec (PsExec examples) as we will demonstrate below. Once hashes have been captured, it's time to get cracking! Responder saves all hashes as John Jumbo compliant outputs and a SQLite database. A reliable cracking tool such as John the Ripper can be used to complete this step. Even if cracking is unsuccessful, hashes can be used to validate access to other areas of the target network. This is the beauty of using Responder in conjunction with PsExec. PsExec is a Windows-based administrative tool which can be leveraged to move laterally around the target network. It is useful to launch executables, command prompts and processes on systems. There are numerous tools available for penetration testers who wish to take advantage of PsExec's availability within a network. For example, Metasploit has over 7 PsExec-related modules, its most popular ones being psexec and psexec_psh. There's also the previously-mentioned Windows executable and Core Security's impacket psexec python script. All are potential options depending on the penetration tester's preferences and tool availability. Many networks today struggle to reliably detect remote code execution, which is why it's very common for penetration testers to use Responder and PsExec in the early stages of an engagement. This is due to default Windows environment configurations, as well as protocol-specific behavior which by default trusts all responses.  Fortunately, such attacks can be prevented and detected. To mitigate the first attack we mentioned using Responder's broadcast attacks, these can be prevented by disabling LLMNR and NBT-NS. Since networks already use DNS, these protocols aren't required unless you're running certain instances of Windows 2000 or earlier (in which case, we recommend a New Year's resolution of upgrading your systems!). To prevent the second showcased Responder attack caused by WPAD traffic, it is simply a matter of adding a DNS entry for ‘WPAD' pointing to the corporate proxy server. You can also disable the Autodetect Proxy Settings on your IE clients to prevent this attack from happening. If your company uses Rapid7's InsightIDR, you can detect use of either Responder or PSExec. Our development team works closely with our pen-test and incident response teams to continuously add detections across the Attack Chain. For that reason, the Insight Endpoint Agent in real-time collects the data required to detect remote code execution and other stealthy attack vectors. For a 3-minute overview on InsightIDR, our incident detection and response solution that combines User Behavior Analytics, SIEM, and EDR, check out the below video. Rapid7 InsightIDR 3-Min Overview - YouTube References: https://github.com/lgandx/Responder /2013/03/09/psexec-demysti fied https://github.com/CoreSecurity/impacket/blob/master/examples/psexec.py http://www.openwall.com/john/ https://www.microsoft.com/en-us/download/details.aspx?id=36036 https://www.sans.org/reading-room/whitepapers/testing/pass-the-hash-attacks-tools-mitigation-33283

GDPR is coming….. If your organisation does business with Europe, or more specifically does anything with the Personal Data of EU Citizens who aren't dead (i.e. Natural Persons), then, just like us, you're going to be in the process of living the dream that is Preparing for the General Data Protection Regulation. For many organisations, this is going to be a gigantic exercise, as even if you have implemented processes and technologies to meet with current regulations there is still additional work to be done. Penalties for infringements of GDPR can be incredibly hefty. They are designed to be dissuasive. Depending on the type of infringement, the fine can be €20 million, or 4% of your worldwide annual turnover, depending on which is the higher amount. Compliance is not optional, unless you fancy being fined eye-watering amounts of money, or you really don't have any personal data of EU citizens within your control. The Regulation applies from May 25th 2018. That's the day from which organisations will be held accountable, and depending on which news website you choose to read, many organisations are far from ready at the time of writing this blog. Preparing for GDPR is likely to be a cross-functional exercise, as Legal, Risk & Compliance, IT, and Security all have a part to play. It's not a small amount of regulation (are they ever?) to read and understand either – there are 99 Articles and 173 Recitals. I expect if you're reading this, it's because you're hunting for solutions, services, and guidance to help you prepare. Whilst no single software or services vendor can act as a magic bullet for GDPR, Rapid7 can certainly help you cover some of the major security aspects of protecting Personal Data, in addition to having solutions to help you detect attackers earlier in the attack chain, and service offerings that can help you proactively test your security measures, we can also jump into the fray if you do find yourselves under attack. Processes and procedures, training, in addition to technology and services all have a part to play in GDPR. Having a good channel partner to work with during this time is vital as many will be able to provide you with the majority of aspects needed. For some organisations, changes to roles and responsibilities are required too – such as appointing a Data Protection Officer, and nominating representatives within the EU to be points of contact. So what do I need to do?If you're just beginning in your GDPR compliance quest, I'd recommend you take a look at this guide which will get you started in your considerations. Additionally, having folks attend training so that they can understand and learn how to implement GDPR is highly recommended – spending a few pounds/euros/dollars, etc on training now can save you from the costly infringement fines later on down the line. There are many courses available – in the UK I recently took this foundation course, but do hunt around to find the best classroom or virtual courses that make sense for your location and teams.Understanding where Personal Data physically resides, the categories of Personal Data you control and/or process, how and by whom it is accessed, and how it is secured are all areas that you have to deal with when complying with GDPR. Completing Privacy Impact Assessments are a good step here. Processes for access control, incident detection and response, breach notification and more will also need review or implementation. Being hit with a €20million fine is not something any organisation will want to be subject to. Depending on the size of your organisation, a fine of this magnitude could easily be a terminal moment. There is some good news, demonstrating compliance, mitigating risk, and ensuring a high level of security are factors that are considered if you are unfortunate to experience a data breach. But ideally, not being breached in the first place is best, as I'm sure you‘d agree, so this is where your security posture comes in. Article 5, which lists the six principles of processing personal data, states that personal data must be processed in an appropriate manner as to maintain security. This principal is covered in more detail by Article 32 which you can read more about here.Ten Recommendations for Securing Your EnvironmentEncrypt data – both at rest and in transit. If you are breached, but the Personal Data is in a render unintelligible to the attacker then you do not have to notify the Data Subjects (See Article 34 for more on this). There are lots of solutions on the market today – have a chat to your channel partner to see what options are best for you. Have a solid vulnerability management process in place, across the entire ecosystem. If you're looking for best practices recommendations, do take a look at this post. Ensuring ongoing confidentiality, integrity and availability of systems is part of Article 32 – if you read Microsoft's definition of a software vulnerability it talks to these three aspects. Backups. Backups. Backups. Please make backups. Not just in case of a dreaded ransomware attack; they are a good housekeeping facet anyway in case of things like storage failure, asset loss, natural disaster, even a full cup of coffee over the laptop. If you don't currently have a backup vendor in place, Code42 have some great offerings for endpoints, and there are a plethora of server and database options available on the market today. Disaster recovery should always be high on your list regardless of which regulations you are required to meet.Secure your web applications. Privacy-by-design needs to be built in to processes and systems – if you're collecting Personal Data via a web app and still using http/clear text then you're already going to have a problem. Pen tests are your friend. Attacking your systems and environment to understand your weak spots will tell you where you need to focus, and it's better to go through this exercise as a real-world scenario now than wait for a ‘real' attacker to get in to your systems. You could do this internally using tools like Metasploit Pro, and you could employ a professional team to perform regular external tests too. Article 32 says that you need to have a process for regularly testing, assessing, & evaluating the effectiveness of security measures. Read more about Penetration testing in this toolkit.Detect attackers quickly and early. Finding out that you've been breached ~5 months after it first happened is an all too common scenario (current stats from Mandiant say that the average is 146 days after the event). Almost 2/3s of organisations told us that they have no way of detecting compromised credentials, which has topped the list of leading attack vectors in the Verizon DBIR for the last few years. User Behaviour Analytics provide you with the capabilities to detect anomalous user account activity within your environment, so you can investigate and remediate fast.Lay traps. Deploying deception technologies, like honey pots and honey credentials, are a proven way to spot attackers as they start to poke around in your environment and look for methods to access valuable Personal Data.  Don't forget about cloud-based applications. You might have some approved cloud services deployed already, and unless you've switched off the internet it's highly likely that there is a degree of shadow IT (a.k.a. unsanctioned services) happening too. Making sure you have visibility across sanctioned and unsanctioned services is a vital step to securing them, and the data contained within them. Know how to prioritise and respond to the myriad of alerts your security products generate on a daily basis. If you have a SIEM in place that's great, providing you're not getting swamped by alerts from the SIEM, and that you have the capability to respond 24x7 (attackers work evenings and weekends too). If you don't have a current SIEM (or the time or budget to take on a traditional SIEM deployment project), or you are finding it hard to keep up with the number of alerts you're currently getting, take a look at InsightIDR – it covers a multitude of bases (SIEM, UBA and EDR), is up and running quickly, and generates alert volumes that are reasonable for even the smallest teams to handle. Alternatively, if you want 24x7 coverage, we also have a Managed Detection and Response offering which takes the burden away, and is your eyes and ears regardless of the time of day or night.Engage with an incident response team immediately if you think you are in the midst of an attack. Accelerating containment and limiting damage requires fast action. Rapid7 can have an incident response engagement manager on the phone with you within an hour. Security is just one aspect of the GDPR, for sure, but it's very much key to compliance. Rapid7 can help you ready your organisation, please don't hesitate to contact us or one of our partners if you are interested in learning more about our solutions and services. GDPR doesn't have to be GDP-argh!

Today, we're excited to release Rapid7's latest research paper, Under the Hoodie: Actionable Research from Penetration Testing Engagements, by Bob Rudis, Andrew Whitaker, Tod Beardsley, with loads of input and help from the entire Rapid7 pentesting team.This paper covers the often occult art of penetration testing, and seeks to demystify the process, techniques, and tools that pentesters use to break into enterprise networks. By drawing on the experiences of dozens of pentesters in the field, based on real, qualified data drawn from the real-life experiences of those pentesters, we're able to suss out the most common vulnerabilities that are exploited, the most common network misconfigurations that are leveraged, and the most effective methods we've found to compromise high-value credentials.Finding: Detection is EverythingProbably the most actionable finding we discovered is that most organizations that conduct penetration testing exercises have a severe lack of usable, reliable intrusion detection capabilities. Over two-thirds of our pentesters completely avoided detection during the engagement. This is especially concerning given that most assessments don't put a premium on stealth; due to constraints in time and scope, pentesters generate an enormous amount of malicious traffic. In an ideal network, these would be setting off alarm bells everywhere. Most engagements end with recommendations to implement some kind of incident detection and response, regardless of the specific techniques for compromise were used.Finding: Enterprise Size and Industry Doesn't MatterWhen we started this study, we expected to find quantitative differences between small networks and large networks, and between different industries. After all, you might expect a large, financial industry enterprise of over 1,000 employees would be better equipped to detect and defend against unwelcome attackers due to the security resources available and required by various compliance regimes and regulatory requirements. Or, you might believe that a small, online-only retail startup would be more nimble and more familiar with the threats facing their business.Alas, this isn't the case. As it turns out, the detection and prevention rates are nearly identical between large and small enterprises, and no industry seemed to fare any better or worse when it came to successful compromises.This is almost certainly due to the fact that IT infrastructure pretty much everywhere is built using the same software and hardware components. Thus, all networks tend to be vulnerable to the same common misconfigurations that have the same vulnerability profiles when patch management isn't firing at 100%. There are certainly differences in the details -- especially when it comes to custom-designed web applications -- but even those tend to have the same sorts of frameworks and components that power them.The Human TouchFinally, if you're not really into reading a bunch of stats and graphs, we have a number of "Under the Hoodie" sidebar stories, pulled from real-life engagements. For example, while discussing common web application vulnerabilities, we're able to share a story of how a number of otherwise lowish-severity, external web application issues lead to the eventual compromise of the entire internal back-end network. Not only are these stories fun to read, they do a pretty great job of illustrating how unrelated issues can conspire on an attacker's behalf to lead to surprising levels of unauthorized access.I hope you take a moment to download the paper and take a look at our findings; I don't know of any other research out there that explores the nuts and bolts of penetration testing in quite the depth or breadth that this report provides. In addition, we'll be covering the material at our booth at the RSA security conference next week in San Francisco, as well as hosting a number of "Ask a Pentester" sessions. Andrew and I will both be there, and we love nothing more than connecting with people who are interested in Rapid7's research efforts, so definitely stop by.

UPDATE: Leaderboard can be found on this new post! Plus, some notes that may be helpful. Exciting news! Rapid7 is hosting a month-long, world-wide capture the flag(s) competition! Rapid7 recently released Metasploitable3, the latest version of our attackable, vulnerable environment designed to help security professionals, students, and researchers alike hone their skills and practice their craft. If you are unfamiliar with Metasploitable3, you can get up to speed with this blog post announcing its release. For an additional challenge in Metasploitable3, we've hidden several flags in the virtual machine that penetration testers can find to demonstrate their prowess. To honor the release of this new tool – and to have a little fun – we're hosting a month-long competition to see who can find the most Metasploitable flags! The competition will be very simple, and easy for anyone to participate in. For our leaderboard winners, we'll be giving out some great prizes as well as some Metasploit T-Shirts for others who submit a captured flag. Here's how it works. Download and install Metasploitable3. Dig in! Find those flags! Complete a simple write-up (see format below or template here), providing proof you've found one and you'll be added to the leaderboard. (Note: We may ask your permission to publish the write-up after the competition closes.) We'll keep a running tally of the leaderboard at the bottom of this blog post. On December 31st we'll announce the winners! Details There are currently 15 flags hidden in Metasploitable3, with more being added. When you find a flag, take a screenshot of it.  Put it in a doc with the following information: How did you get access to the machine? How did you spot the file? How did you extract the file? Note: In some cases, the files are easy to find so please describe the extraction process. A template can be found here. Please note: in the spirit of friendly competition, please only submit flags that have been found from a running metasploitable3 instance, not the vagrant folders used to build the instance.  Then email capturetheflag [at] rapid7.com and we'll review and add you to the leader board.  At the end of the month the top 3 people with the most submitted flags accepted will receive prizes. In the case of a tie, a set of subjective measures will be used to select the winners. The measure will be: creativity of methods used to obtain the flags and strength of the write-up. We reserve the right to award bonus prizes. And one note for our beloved Rapid7 employees: You are welcome to play along, but standings will be tracked separately and awarded accordingly. Prizes! 1st Place: Hak5 Pineapple 2nd Place: LAN Turtle or Lock Pick Set 3rd Place: LAN Turtle or Lock Pick Set The first 25 to submit a flag will get a Metasploit T-Shirt! We reserve the right to award bonus prizes. Any questions? Feel free to comment below or email community [at] rapid7.com and we'll get back to you. Happy Hunting! Leaderboard Get all the updates here: Metasploitable3 CTF Competition: Update and Leaderboard! Official Rules: Terms & Conditions The Metasploitable3 Capture the Flags competition is open to anyone. No purchase is necessary to participate. Eligibility is dependent on following the entry rules outlined in this guide. To Enter: Locate and screenshot flags found in Metasploitable3 and send a written submission detailing 1) how you got access to the machine; 2) how you spotted the file; 3) how you extracted the file, to capturetheflag [at] rapid7.com. A template can be found here or by searching for “Metasploitable3 CTF” on community.rapid7.com. Partial or incomplete submissions WILL NOT BE ACCEPTED as an entry and shall not be eligible for any prize. All submissions will be reviewed by Rapid7 for adherence to these Official Rules. Rapid7 may ask for permission to publish written submissions after the contest close. The leaderboard competition will open on Wednesday, December 7, 2016 at 12:00:01 ET and close on Saturday, December 31, 2016 at 11:59:59 ET. Entries submitted after this time may be eligible for additional prizes determined by Rapid7. In the event of a tie, Rapid7 will evaluate submissions to select the first place winner. A set of subjective measures will include 1) creativity of methods used to obtain the flags and 2) strength of the written submission. Rapid7 reserves the right to award bonus prizes. The leaderboard will be updated regularly with the final submissions being added by Tuesday, January 3, 2017 at 11:59:59 ET. Prizes/Odds of Winning: Only the prizes listed below will be awarded in the competition. Odds of winning depend on the number of eligible entries submitted by the close date. Prize is not transferable or redeemable for cash. Rapid7 reserves the right to make equivalent substitutions as necessary, due to circumstances not under its control. Please allow 3-4 weeks for delivery of any prize. Leaderboard Prizes Three (3) Prizes Leaderboard Position Prize Approx. Value 1st place Hak5 Pineapple (Nano Basic) $149.99 2nd place LAN Turtle OR Lock Pick Set $49.99 3rd place LAN Turtle OR Lock Pick Set $49.99 Additional Prizes Twenty-five (25) Prizes** The first 25 people to submit a flag will get a Metasploit T-Shirt (approx. value: $10) available from the online Rapid7 Retail Store. Rapid7 reserves the right to award additional T-shirt prizes. Competition host is Rapid7 LLC, 100 Summer St, Boston, MA 02110. By entering the competition, you agree to these terms and conditions. Employees and the immediate families of Rapid7 may not participate. If you have any concerns or questions related to these terms and conditions, please email capturetheflag [at] rapid7.com.

This is the 5th in a series of blog topics by penetration testers, for penetration testers, highlighting some of the advanced pentesting techniques they'll be teaching in our new Network Assault and Application Assault certifications, opening for registration this week. For more information, check out the training page at www.rapid7.com/services/training-certification/penetration-testing-training.jsp First things first, I think it's important to define this topic. Per OWASP, "Local File Inclusion (LFI) is the process of including files, that are already locally present on the server, through the exploiting of vulnerable inclusion procedures implemented in the application." Taking a look at that definition, what does it really mean? Essentially, it states that through some means someone may be able to access files on your local system through your application. Very often when talking about LFI you are talking about utilizing Directory Traversal (‘../') to move up from the WebRoot directory to access local files. In many different examples throughout the web you will see articles discussing LFI in regards to accessing files within Linux, such as accessing ‘/etc/passwd,' or log files within ‘/var/log,' or a user's Bash history ‘/home/[USERNAME]/.bash_history.' An example of accessing /etc/passwd within a web application is shown in Figure 1.   Figure 1: https://www.offensive-security.com/metasploit-unleashed/file-inclusion-vulnerabi lities/ However, it isn't very often that you see any articles or blog posts that discuss files to access within Windows in the case that a LFI vulnerability is discovered within an application on a Windows Server.  This blog post will discuss potential files to access on a Windows Server. On Windows a very common file that a penetration tester might attempt to access to verify LFI is the hosts file, WINDOWS\System32\drivers\etc\hosts. This will generally be the first file someone tries to access to initially ensure they have read access to the filesystem. From this initial read access there are a number of places that someone might go within the filesystem to retrieve files; in fact there are a number of great blog posts and articles available that discuss potential files to then access. However, another great area to look for interesting files is within a user's directory. A great way to enumerate users with LFI is to look for the desktop.ini file. With LFI, when discovering the desktop.ini file for a user's account, which will be located at (in newer versions of Windows) C:\Users[USERNAME]\Desktop\desktop.ini, you can begin attempting to discover potential files that could be contained within their Desktop or Documents folder as users often store sensitive information within these folders. Based on all of this, what are some simple ways to attempt to discover LFI within a web application? A quick Python script can allow for the testing of LFI. First, a quick example script to test for the ability to read some common Windows files within an example web application, in this case ‘www.testpage.com' which has a parameter named ‘page' that allows for LFI. In this case, you could have the following script with the use of the ‘Requests' and ‘Webbrowser' Python libraries: import requests import webbrowser url = 'http://www.testpage.com?page=' LFI = '../../../../../../../../../' pages = ['WINDOWS/system32/drivers/etc/hosts', 'WINDOWS/system32/win.ini', 'WINDOWS/system32/debug/NetSetup.log', 'WINDOWS/system32/config/AppEvent.Evt', 'WINDOWS/system32/config/SecEvent.Evt', 'WINDOWS/Panther/unattend.txt', 'WINDOWS/Panther/unattend.xml', 'WINDOWS/Panther/unattended.xml', 'WINDOWS/Panther/sysprep.inf'] for x in pages: check = requests.get(url + LFI + x) if check.status_code == 200: webbrowser.open(url + LFI + x) In the above example, we are attempting to make the request to verify the HTTP response code of 200 to see if when we access the file within the web application that it is returned (i.e. that it exists). Then, with the use of the ‘Webbrowser' library we can open the page to download the file within our web browser to open it with your favorite text editor easily.  Note, there may be situations that this simple of a script may not be the best option, specifically those areas where all requests return a 200 for the page and you are testing a large list of potential files. In those cases each request will open in the browser and if a file is reachable it will either display within the browser or be available to review within your text editor. Granted, there are many ways to accomplish this task with Python, but this is one of my favorites. The following shows another Python script to attempt to enumerate usernames by locating paths that return a ‘desktop.ini' file as discussed earlier, then when a username is verified on the server you can attempt to find potential files that may contain sensitive information stored on the user's Desktop on the server. import requests import webbrowser url = 'http://www.testpage.com?page=' LFI = '../../../../../../../../../' usernames = ['bob.jones', 'tom.johnson', 'mary.thomas', 'bill.smith'] desktopini = '/Desktop/desktop.ini' usersfiles = ['accounts.txt', 'passwords.doc', 'configs.txt', 'sensitiveinfo.doc'] for x in usernames: check = requests.get(url + LFI + x + desktopini) if check.status_code == 200: print(‘User ’ + x + ‘was found’) desktopsearch = requests.get(url + LFI + '/Desktop/' + usersfiles) if desktopsearch.status_code == 200: webbrowser.open(url + LFI + '/Desktop/' + usersfiles) These example scripts are essentially trivial examples, but they provide enough to get you started to begin searching for LFI with Windows and gets you started in beginning to find information that could be very useful for Penetration Tests. Want to learn more techniques for application and network penetration testing? Go back and read the other blogs in our “Pentesting in the Real World” series and sign up for our new Network Assault and Application Assault courses!

This is the 4th in a series of blog topics by penetration testers, for penetration testers, highlighting some of the advanced pentesting techniques they'll be teaching in our new Network Assault and Application Assault certifications, opening for registration this week. For more information, check out the training page at www.rapid7.com/services/training-certification/penetration-testing-training.jsp Preface As penetration testers, we are always looking for commonly used services that offer us (and attackers) easy ways into networks. Some of these easy wins include Tomcat, Java RMI instances with class loaders enabled, vulnerable IPMI instances, and or databases poorly configured or misconfigured. These entry points are not theoretical or what could potentially happen. These issues are what does happen over and over and over on penetration test. Today we are going to talk about an open-source NoSQL database known as MongoDB. By default, this database does not require a password to authenticate to it. Even though this database only listens on localhost by default, I've found this service listening on a externally accessible port more than a few times. So much in fact I'm now blogging about it. What is it? What is NoSQL? No, it's not a protest against SQL; it's a different type of database solution. One of the problems with NoSQL is there is no authentication associated with most types of NoSQL solutions. Besides MongoDB, other NoSQL solutions include Redis, and Apache Cassandra. MongoDB is one of the more popular NoSQL solutions. As a result, it is something we have been finding frequently on our penetration tests. And as it is a type of database, simply gaining access to it can often be considered a compromise. There have been a number of data breaches due to improper use of MongoDB. There were 93 Million Mexican voters who had their data breached due to a MongoDB being misconfigured. A dating site had its users compromised because of a misconfigured MongoDB instance, and 13 million MacKeeper users were also compromised, yep you guessed it, by MongoDB misconfiguration. How do so many people misconfigure their databases you ask? Well its simple: the default install requires no password. This is done with the intention that the database does not listen externally on the system. However, most users want it to listen externally so what do they do? They make it listen externally and go about their business, happy that their software works, and live happily ever after. That's when the big bad wolf hacker comes sniffing around trying to huff and puff and access your database that does not have a password. As you might imagine it does not require a lot of skill to access a database with no password. In fact, you probably logged into your phone or computer in order to read this blog, and that required more effort than it does to access these databases. Let's take a look at some of the ways hackers do it. How to find it? MongoDB runs on a default port of 27017. If you don't know what a port is, imagine a computer system as an office building. The ports are doors and windows into the building. MongoDB is window 27017. In order to find out if this window, I mean port, is open on a system, you can scan a network using tools such as masscan, shodan, nmap, metasploit, and nosqlmap.py. For example, to find it using nmap you can run the following commands: nmap -Pn -p 27017 --script mongodb-databases x.x.x.x If you wanted to use Nosqlmap.py in order to find MongoDB instances you could use the following command: nosqlmap.py Then go through the menu options as demonstrated in Figure 2: Lastly is a way to find MongoDB using Rapid7's very own Metasploit. The Metasploit module that will help in this instance is the following: auxiliary/scanner/mongodb/mongodb_login The Metasploit commands shown in Figure 3 are as follows: use auxiliary/scanner/mongodb/mongodb_login show options set rhosts x.x.x.x exploit Now that we have found MongoDB wide open on a network what do we do now, Brain? Well Pinky, now we take over the WORLD … err access the database. How to access it? At this point accessing a database can be done any number of ways. We could simply use the MongoDB client as demonstrated in Figure 4: We could use a third party GUI client if you like to click your way around databases. Once such client is Robomongo as can be seen in Figure 5. Additionally, we could use NoSQLMap to access data from the database as well. NoSQLMap provides the following options to access the database also seen in Figure 6. Get Server Version and Platform Enumerate Databases/Collections/Users Check for GridFS Clone a Database Launch Metasploit Exploit for Mongo < 2.2.4 How to exploit it? If you have been following along closely you might have noticed versions 2.2.3 and below are vulnerable to more than just accessing them. Specifically, versions 2.2.3 and below makes use of the “nativeHelper” feature in the spidermonkey MongoDB implementation. As it stands this only affects 32 bit Linux installs of MongoDB 2.2.3 and below. The Metasploit module for exploiting this is as follows: exploit/linux/misc/mongod_native_helper Additionally, versions 2.2.3 and below are also vulnerable to NoSQL injection. There is a mMetasploit module that can be used against the web interface. The Metasploit module used for exploiting this is as follows: auxiliary/gather/mongodb_js_inject_collection_enum Note: Additional security risks Even when it's secured, if an attacker or pen tester gets on the box they will will be able to extract the password in clear text. This is because the password is stored in the mongodb.conf file in clear text. There is currently nothing that can be done about this. This is one of the ways companies are getting compromised these days. If you want to learn more techniques like this, look out for the rest of our “Pentesting in the Real World” series, and sign up for our assault class where we will teach you how to identify issues and how to exploit those issues to gain access and / or information.

This is the third in a series of blog topics by penetration testers, for penetration testers, highlighting some of the advanced pentesting techniques they'll be teaching in our new Network Assault and Application Assault certifications, opening for registration this week. For more information, check out the training page at www.rapid7.com/services/training-certification/penetration-testing-training.jsp Background Group Policy Preferences (GPP) are a powerful tool that once allowed administrators to create domain policies with embedded credentials. These policies allowed administrators to set local accounts, embed credentials for the purposes of mapping drives, or perform other tasks that may otherwise require an embedded password in a script. While a useful tool, the storage mechanism for the credentials was flawed and allowed attackers to trivially decrypt the plaintext credentials. While addressed in MS14-025, this patch only prevents new policies from being created, and any legacy GPPs containing credentials must be found and removed. Learning how to find and exploit these GPPs that contain credentials is an important tool to have in the pentester's arsenal because the policies may contain highly privileged accounts. GPP uses Embedding credentials in group policy preferences solved a lot of problems for administrators. A GPP could be used to easily apply a common local administrator password to all workstations, apply an entirely new administrator account (as shown below), schedule tasks as other users, map drives, apply printers, or several other uses. Often, these kinds of policies can involve service accounts that frequently have elevated privileges. In the example below, a GPP is set to add the account ‘new_local_admin' to all domain systems. We'll use this account as a demonstration later on. On pentests I've performed, I've encountered GPPs being used to set local administrator accounts, schedule tasks or even applying a service account to a system which often has elevated privileges. Regardless of why they originally were created, their mere existence is a great resource for a pentester. Can you keep a secret? Given the wide variety of uses for GPPs that contain credentials, it is fairly common to find them on penetration tests, and often with credentials ranging from local admin to domain admin.  While the functionality of GPPs is very powerful, the mechanism of storing those credentials was compromised in a way that made them trivial to decrypt. Even Microsoft no longer advocates storing credentials in GPPs, and addressed the issue in MS14-025 (https://support.microsoft.com/en-us/kb/2962486)). Put in basic terms, applying any account, administrative or not, via GPP stores the account's password in an insecure manner. Specifically, the password that is stored in the policy is encrypted with a known key, helpfully documented by Microsoft here: https://msdn.microsoft.com/en-us/library/cc422924.aspx, meaning anyone who can access the GPP can decrypt the store and obtain the plain text password, no matter the complexity. Since GPPs are stored on the domain controller in the SYSVOL share, this means that at a minimum all domain users can access the encrypted credentials. To put it another way: While MS14-025 does address the issue to some degree, it only does so by blocking or warning against the creation of new policies that can apply account credentials (https://blogs.technet.microsoft.com/srd/2014/05/13/ms14-025-an-update-for-group- policy-preferences/)), which is perfectly reasonable as clearly no one wants a patch that deletes existing credentials. However, this means that if any current GPPs are already applying credentials they must be found and manually removed, along with considerations for any functionality such as mapping of drives or printers that may break as a result. As these policies rarely get attention from IT other than during the initial creation, and are more ‘set and forget,' many times a penetration tester will find an account that was provisioned years before and simply forgotten about. Attacking GPPs Obtaining credentials is a primary goal during a pentest, and group policy preferences is a go-to attack for many testers as it is stealthy and high reward. Since group policies are stored in SYSVOL on the domain controller, any domain user can read the policy and therefore decrypt the stored passwords. Below is an example of how the password for ‘new_local_admin' is stored in a groups.xml file. This also means any phishing attack or other foothold on any domain system will result in a leak of all credentials stored in group policy preferences. Demonstrating this is very easy so try this yourself with the Metasploit smb_enum_gpp module. If you run smb_enum_gpp against a domain controller and get credentials in your result, then you'll know you have this vulnerability. Below is the password for ‘new_local_admin' we set in the GPP. Even without Metasploit, one can extract the cpassword value from the files on SYSVOL and pass them to the gpp-decrypt tool in Kali Linux which will decrypt it: While GPPs are mainly useful for privilege escalation, persistence, or lateral movement, which are all essentially post-exploitation activities, I've run into some even weirder scenarios during penetration tests. In the worst example, anyone on a local network was able read the SYSVOL share and extract credentials via anonymous access to a domain controller. This sort of misconfiguration can make a bad situation a worst case scenario as it allowed an unauthenticated attacker who had only network access to gain credentials easily. After dumping the active directory group memberships, also via anonymous access, wouldn't you know that this account (that was effectively world readable) was a domain admin! That's about the nastiest of worst-case scenarios. After finding and exploiting this issue numerous times, I've found some common themes: Many organizations simply aren't aware that GPP behaves in this manner. They may think that the MS14-025 patch completely remediated the issue. Organizations don't even know they have GPPs with credentials. Number three is by far the most common. Often, the age of the accounts indicates they were set years ago and have been functioning as intended.  Usually these are service accounts, commonly with no password expiration. IT administrator turnover or bad documentation simply results in these policies being overlooked. Solutions? The first step is to perform an accounting of group policies that apply credentials. Speaking as a pentester, I feel the easiest way is to use attack methods and tools to find the usage of GPPs that contain credentials. As mentioned before, the Metasploit smb_enum_gpp module (https://www.rapid7.com/db/modules/auxiliary/scanner/smb/smb_enum_gpp) can be used to enumerate GPPs that contain credentials, but realistically a search of the SYSVOL share for the files that contain the credentials can also be performed with a script. Microsoft even supplies such a script in kb article 2962486 (https://support.microsoft.com/en-us/kb/2962486). If GPPs are used to apply local administrator accounts, Microsoft also has the Local Administrator Password Solution (LAPS) tool (https://www.microsoft.com/en-us/download/details.aspx?id=46899)) to help provision these accounts without group policy preferences. So to recap, legacy GPPs that contain credentials are a great way for penetration testers to gain credentials easily from an insecure credential store on domain controllers. They are easy to find, are often privileged accounts, and accessing them doesn't usually ring alarm bells. Interested in learning how to use GPP and similar techniques on your penetration test? Register for our next Network Assault class, and keep an eye out for the other blog posts in this series, which we'll be releasing throughout the week.

This is the second in a series of blog topics by penetration testers, for penetration testers, highlighting some of the advanced pentesting techniques they'll be teaching in our new Network Assault and Application Assault certifications, opening for registration this week. For more information, check out the training page at www.rapid7.com/services/training-certification/penetration-testing-training.jsp As a pentester one of the first things I am looking to do on an internal network is gain access to systems. One of the ways I do that is to respond to NetBIOS-NS or it's predecessor LLMNR broadcast messages, to tell the requesting host that our attacking machine is the host they are wanting to connect to. So what is NetBIOS-NS and LLMNR: Both NetBIOS and LLMNR are services used to identify hosts on a network when DNS fails. When a host on the network is not able to resolve a hostname to an IP address via DNS, LLMNR and then NetBIOS will send broadcast messages to the network asking all hosts on the network if they have the hostname originally requested. As an attacker all we have to do is listen for those requests, respond to them to tell the requesting host (victim) they are looking for our attacking machine, and capture their connection request. Attack Methodology: There are two Metasploit modules I like to use for capturing the credentials sent by the victim machine when requesting to connect. auxiliary/server/capture/http_ntlm auxiliary/server/capture/smb Both of these modules setup listening services on our attacking machine to respond to both SMB and HTTP, for NTLM/LM hashes. What we need to do is solicit these connections from a victim machine, and direct them to our attacking machine so we can capture the requests that will include NTLM/LM hashes. This can be achieved through the Metasploit modules. auxiliary/spoof/llmnr/llmnr_response auxiliary/spoof/nbns/nbns_response I recommend that you dig into the options for each of these modules for a more in-depth understanding of their potential and use not covered in this article. In the Figure 1 below, you will notice I have two Virtual Machines. The VM on the left is my attacker machine, running Metasploit Framework. And the VM on the right is a Windows7 victim machine. Both of these VMs are running on a local host network, so they are logically next to each other within the VM network. On the attacker machine I have already done the following within the Metasploit Framework: use auxiliary/server/capture/http_ntlm set JOHNPWFILE httpntlm.txt run use auxiliary/server/capture/smb set JOHNPWFILE smbhashes.txt run use auxiliary/spoof/llmnr/llmnr_response set spoofip 0.0.0.0 set interface eth0 run use auxiliary/spoof/nbns/nbns_response set interface eth0 run With all four of the modules setup and configured to listen for and/or respond to incoming broadcast messages I am able to mimic a host trying to access network resources with my Windows7 victim VM. Remediation: NetBIOS-NS and LLMNR: It should be noted that, given sufficient password strength, this form of attack would not necessarily yield access. Rapid7 therefore recommends that the first steps are to ensure all accounts are configured with strong passwords, then consider disabling the NetBIOS and LLMNR protocols on all Windows hosts. Disabling these protocols would limit the ability of a malicious actor to perform a poisoning attack and capture Windows authentication traffic. For hosts XP or older, NetBIOS can be disabled within the network adapter properties within each Windows host. For Windows 7 and above, the LLMNR protocol can be disabled through Group Policies. Finally, ensure that security configuration standards are properly applied to all desktop systems prior to deployment into a production environment. Create security configuration standards for desktop systems if they do not already exist. Metasploit is not the only tool that has this functionality. SpiderLabs, opensource tool responder.py is another that can leverage this weakness in NetBIOS-NS, and LLMNR. Wesley McGrew's tool nbnspoof.py is an old school tool for spoofing/poisoning NetBIOS-NS. Capturing NTLM/LM hashes is a great first step when attempting to gain access to the network. Both of Metasploit's auxiliary servers' modules I listed in this article have a setting for writing the captured hashes in both/either a format for Cain & Able, or John the Ripper to make cracking the captured hashes one step easier.

This is the first in a series of blog topics by penetration testers, for penetration testers, highlighting some of the advanced pentesting techniques they'll be teaching in our new Network Assault and Application Assault certifications, opening for registration this week. For more information, check out the training page at www.rapid7.com/services/training-certification/penetration-testing-training.jsp So you're starting a pentest. Or you finally get to try out the hands-on part of the Network Assault class. You're probably eager to fire up Metasploit and start pwning, but before you can, you have to understand WHAT you want to/can attack. That's where the critical first step of a penetration test comes in: reconnaissance. Reconnaissance and intelligence gathering is a crucial part of any pentester's gameplan; you can only test what's available so we have to know what's out there. A machine with no ports open and no responses isn't very useful, to a user or a pentester. You can also look for evidence that the system is already compromised by finding open back doors or other software that shouldn't be there, typically with a vulnerability scanner. However, a vulnerability scanner can also disclose false positives (when the vulnerability scanner reports a vulnerability, but the vulnerability doesn't really exist). One example could be that the scanner reports blind sql injection because it didn't get the same response it expected; when the tester tries to validate, he finds that the response was an unrelated error message. Any vulnerability scan should be manually validated to ensure what is reported is a true positive. A good scanner makes this easy by reporting the actual test that it used, so the person doing the validating can run the proof themselves; for example, if a vulnerability scanner reports that XSS is present, it should show the parameter that was tested and the actual code it used. In the figure below, we see one example of the type of information that is gained from the Nexpose scanner. Nexpose is reporting that rsh is enabled on the server and the root account doesn't have a password at all! We can also see that the Nexpose vulnerability scanner is offering a solution. It gives an explanation of how to mitigate this confirmed vulnerability using the “passwd” command. Nexpose will give this kind of information, including its severity level, for each vulnerability it finds. Once the vulnerability scan is complete, you'll have an idea of the version of the operating system, version of the web server (if there is one) and other services' versions. Additionally, you'll have a list of the potential vulnerabilities of the system. These will be a great starting point when you get to the exploitation stage, as one or more of them could get you a foothold toward gaining full control of your targeted environment. Next, a good pen tester will try some more specific scans, that can be done concurrently. One very common example is a port scan. The most commonly used tool for a port scan is nmap, which lets you easily find open ports on both TCP and UDP. A default nmap scan will test the 1000 most commonly used TCP ports, with a simple SYN check. The targeted machine will respond with the ports that are available. We may also want to check all 65,535 available ports on a machine, to see if it is using any uncommon or non-standard ports. This can by done by adding the “-p” flag. You can either indicate all ports with “-p 0-65535” or more simply just “-p-“. Conveniently, we can have nmap output its results to files, which may be more easily read by other tools, in case we don't want to read each machine's results ourselves, or if there are too many to go through. Use the –oA flag to tell nmap to output the results to all possible file types, using the string after (in this case, “scan”) as the file name. The file types that will be created are a greppable nmap file, an exact replica of the output we see above, and an xml file. Nmap has a bunch of other functionality for more specific tasks including running additional test scripts, or even doing brute forcing, that may be used later in the assessment. Once Nexpose and nmap have completed, it's time to get even more focused. Nexpose and nmap should have given you and idea of the underlying operating system, open ports, and services that are running. Based on that information, try using some more specific scanning tools. If there are secure HTTP ports open (443 is the standard), you could run SSLScan to get an idea of the strength of the ciphers being used and information about the SSL certificates in use. If there is a content management system (CMS) running, you might want to get a better idea of what its running with a tool like CMSmap, or WPScan (if running WordPress) or Droopescan (if running Drupal). With a little searching, you can probably find a tool for whatever CMS the site may be running. In the figure below, we are running CMSmap against a Wordpress site, to get a better idea of which themes and plugins are installed. Lastly, while exploitation is out of the scope of this blog post, the Metasploit tool does have auxiliary scanning modules that can also find out even more about the target. In this example, we used the auxiliary/scanner/http/wordpress_login_enum module to brute force the username and password to the Wordpress site. Before starting the exploitation stage, you'll always want to get as much information about what's running and which versions. Knowing these bits will make the exploitation stage faster, easier and safer, and make the Network Assault class even more enjoyable. Good luck!

In a fight between pirates and ninjas, who would win? I know what you are thinking. “What in the world does this have to do with security?” Read on to find out but first, make a choice: Pirates or Ninjas? Before making that choice, we must know what the strengths and weaknesses are for each: Pirates Strengths Weaknesses Strong Loud Brute-Force Attack Drunk (Some say this could be a strength too) Great at Plundering Can be Careless Long-Range Combat Ninjas Strengths Weaknesses Fast No Armor Stealthy Small Dedicated to Training Hand-to-Hand/Sword Combat It comes down to which is more useful in different situations. If you are looking for treasure that is buried on an island and may run into the Queen's Navy, you probably do not want ninjas. If you are trying to assassinate someone, then pirates are probably not the right choice. The same is true when it comes to Penetration Testing and Red Team Assessments. Both have strengths and weaknesses and are more suited to specific circumstances. To get the most value, first determine what your goals are, then decide which best corresponds with those goals. Penetration Testing Penetration testing is usually rolled into one big umbrella with all security assessments. A lot of people do not understand the differences between a Penetration Test, a Vulnerability Assessment, and a Red Team Assessment, so they call them all Penetration Testing. However, this is a misconception. While they may have similar components, each one is different and should be used in different contexts. At its core, real Penetration Testing is testing to find as many vulnerabilities and configuration issues as possible in the time allotted, and exploiting those vulnerabilities to determine the risk of the vulnerability. This does not necessarily mean uncovering new vulnerabilities (zero days), it's more often looking for known, unpatched vulnerabilities. Just like Vulnerability Assessments, Penetration Testing is designed to find vulnerabilities and assess to ensure they are not false positives. However, Penetration Testing goes further, as the tester attempts to exploit a vulnerability. This can be done numerous ways and, once a vulnerability is exploited, a good tester will not stop. They will continue to find and exploit other vulnerabilities, chaining attacks together, to reach their goal. Each organization is different, so this goal may change, but usually includes access to Personally Identifiable Information (PII), Protected Health Information (PHI), and trade secrets. Sometimes this requires Domain Administrator access; often it does not or Domain Administrator is not enough. Who needs a penetration test? Some governing authorities require it, such as SOX and HIPAA, but organizations already performing regular security audits internally, and implementing security training and monitoring, are likely ready for a penetration test. Red Team Assessment A Red Team Assessment is similar to a penetration test in many ways but is more targeted. The goal of the Red Team Assessment is NOT to find as many vulnerabilities as possible. The goal is to test the organization's detection and response capabilities. The red team will try to get in and access sensitive information in any way possible, as quietly as possible. The Red Team Assessment emulates a malicious actor targeting attacks and looking to avoid detection, similar to an Advanced Persistent Threat (APT). (Ugh! I said it…) Red Team Assessments are also normally longer in duration than Penetration Tests. A Penetration Test often takes place over 1-2 weeks, whereas a Red Team Assessment could be over 3-4 weeks or longer, and often consists of multiple people. A Red Team Assessment does not look for multiple vulnerabilities but for those vulnerabilities that will achieve their goals. The goals are often the same as the Penetration Test. Methods used during a Red Team Assessment include Social Engineering (Physical and Electronic), Wireless, External, and more. A Red Team Assessment is NOT for everyone though and should be performed by organizations with mature security programs. These are organizations that often have penetration tests done, have patched most vulnerabilities, and have generally positive penetration test results. The Red Team Assessment might consist of the following: A member of the Red Team poses as a Fed-Ex delivery driver and accesses the building. Once inside, the Team member plants a device on the network for easy remote access. This device tunnels out using a common port allowed outbound, such as port 80, 443, or 53 (HTTP, HTTPS, or DNS), and establishes a command and control (C2) channel to the Red Team's servers. Another Team member picks up the C2 channel and pivots around the network, possibly using insecure printers or other devices that will take the sights off the device placed. The Team members then pivot around the network until they reach their goal, taking their time to avoid detection. This is just one of innumerable methods a Red Team may operate but is a good example of some tests we have performed. So... Pirates or Ninjas? Back to pirates vs. ninjas. If you guessed that Penetration Testers are pirates and Red Teams are ninjas, you are correct. Is one better than the other? Often Penetration Testers and Red Teams are the same people, using different methods and techniques for different assessments. The true answer in Penetration Test vs. Red Team is just like pirates vs. ninjas; one is not necessarily better than the other. Each is useful in certain situations. You would not want to use pirates to perform stealth operations and you would not want to use ninjas to sail the seas looking for treasure. Similarly, you would not want to use a Penetration Test to judge how well your incident response is and you would not want to perform a Red Team assessment to discover vulnerabilities.

A few months back I posted a blog entry, SNMP Best Practices, to give guidance on best methods to reduce security risks as they relate to SNMP. Now that everyone has had time to fix all those issues, I figured it's time to give some guidance to penetration testers and consultants on how to exploit exposed SNMP services by harvesting data and using it to expand their attack footprint. The first question when approaching SNMP is identifying exposed services. To discover exposed services we often use the port scanner tool, NMAP, to scan for UDP port 161. Since most of the time we additionally want to enumerate the data, it is just as easy to automate the discovery and data extraction with simple scripts written in Python or Perl. I personally tend to use Perl and I have created such a script, which can be downloaded, from my GitHub page. If you choose to use my script, the syntax is very simple and is shown below in Figure 1: When I use this script, I set the target to the subnet range of the network I am testing. For example, if testing an internal network of 10.10.0.0/16, I would use the command, “./snmpbw.pl 10.10.0.0/16 public 2 32.” This command will spin up 32 threads and attempt to conduct a snmpbulkwalk command on every host exposing SNMP on UDP port 161 within the entire /16 subnet range. When a device is found with SNMP enabled and a community string of “public,” the script will walk all MIB tables starting at ".1" then return the data and save it in a file for further offline analysis. I have found this method to be very fruitful in harvesting valuable data, which can then be used to conduct further attacks against the environment. I typically kick off this SNMP data harvesting attack script once I have determined the IP address ranges in scope. Then, I just let it run in the background while I continue my network reconnaissance work. Once the snmpbw script has completed running, I then examine the recovered data. One of the first things I do is extract the sysDesc .1.3.6.1.2.1.1.1.0 MIB data from each file to determine what devices I have harvested information from. This can easily be done using the following grep command: grep ".1.3.6.1.2.1.1.1.0" *.snmp An example of the results from this grep command is shown below in Figure 2: So now that you have harvested data from exposed SNMP services, what kind of information could you expect to find? Actually, it is quite amazing what can be discovered within the SNMP MIB data. With a little exploration, I often find some of the following usable pieces of data: Email addresses SNMP community strings Password hashes Clear text passwords Of course, the effort it takes to discover usable information can often be very time consuming. MIB dumps can often be massive, running into multiple megabytes. So I have spent some time examining this issue trying to determine methods to reduce the time involved in examining the data and figured I would share a couple of these with the Community. One of my favorite things I love to do with SNMP MIB data is trying to identify other valid SNMP community strings. Often this data can be used to gain further access to other system. As an example, if I can identify the private community string used by an organization on their Cisco IOS routers, then I could possibly use that community string to extract the running configurations from those routers. The best method for finding such data has often been related to SNMP Trap data. So again, using the following grep we can parse through a lot of MIB data quickly searching for the key word of “trap”: grep -i "trap" *.snmp The following example (Figure 3) shows information I was able to successfully enumerate from the SNMP data using the key word of “trap.” In this example, I was successful in identifying several SNMP community strings, which I then successfully used to gain, read, and write access to the SNMP of multiple network devices. I was also successful in using this data to extract the running configuration from nearly all of the Cisco routers on the network. Another area of interest is logs, I have discovered that there are some devices that hold logs within the MIB tables. These logs can also contain failed logon attempts. Think about the last time you logged into a device via Telnet or SSH and inadvertently entered your password as the username. Sadly, I must admit, I do this quite often. That brings me back to the concept of devices storing logs in the SNMP MIB data. By examining the SNMP data, you could possibly find password information stored in MIB data from users who accidentally enter passwords in the wrong fields during authentication. To retrieve this log information, I typically search for key words such as fail, failed or login and examine that data to see if there is anything of value. grep -i "fail" *.snmp The following example (Figure 4) shows a snippet of logs from a SNMP MIB extraction showing a failed login attempt where the password was used for the username. The cool part is that the next log entry will most likely show a successful authentication for the true user name. It is also important to note that these logs are usually short and they end up rolling over quickly, so make sure you get a copy before launching any brute force attacks against the device. If not, you may end up with SNMP MIB extraction data that looks like the logs in Figure 5: In conclusion, I hope these few examples will give you some good ideas on how to extract and use SNMP data. Also, I think it is important to point out that by taking the time to better examine the data exposed by SNMP, we can better define the risk associated with poorly secured SNMP solution to our customers.

In my work performing vulnerability assessments and penetration tests, I'm often confronted with the dilemma of dealing with a pesky intrusion prevention system (IPS) or web application firewall (WAF). Sometimes we know they're there. Other times, they rear their ugly heads and force a days-long change management process for a whitelist request. Or, when testing web sites/applications, it's not uncommon to find out that I can just connect via SSL/TLS and carry out my tests that would've otherwise been blocked over HTTP.When performing your scans and tests, I think it pays to consider the following – well in advance – to save yourself or others some hassle and (especially) false sense of security:Which technical control(s) might end up creating challenges? Perhaps it's an IPS or a WAF. Maybe it's a firewall or even an endpoint security technology running on the system(s) being tested. Maybe it's a third-party monitoring system that places suspect behavior on a blacklist. Strangely enough, many people aren't familiar with which controls they have in place, often because a third party is “handling everything”. These are considerations that need to be mastered rather than assumed.What happens when scans are blocked? Do you stop there? Some people do, assuming that all's well with security...penetration thwarted! That's what the bad guys would encounter, no? Not really. The thing is, not every exploit originates from an automated scan. The savvy hacker (and security professional) knows that a lot can be done on the down-low. Such manual analysis/exploitation often flies under the radar of security controls. How are you going to address that? If you're doing this work in terms of PCI DSS compliance, the Security Standards Council addresses the very issue of blocked scans/test and the importance of whitelisting when it's needed. It's good to see that this approach is becoming an industry-wide recommended practice.How do you document your findings? If you uncover weaknesses only by manipulating the traditional, scoped assessment approach, is it still reality? Is a blacklisted, whitelisted, or “skirt the situation altogether” approach a true reflection of the security posture of the systems being tested? My take is that if it's out there for others to play with, it should be fair game for all types of testing. If not, perhaps your online footprint needs to be reduced. Still, I see people requiring that the testing only be done in certain ways to, perhaps, have a more favorable outcome for the auditors and management to see. That's a slippery slope, but it happens all the time.In the end, only you will know what's required, what's best for your organization, and what your lawyers are willing to defend. This issue underscores the importance of properly scoping your security assessments. Leaving your security defenses up all the time doesn't mean that something cannot fail and get you into a bind. Don't let finely-tuned testing parameters end up creating a false sense of security that facilitates a breach or is otherwise held against you in the future.

Penetration Tests are a key part of assuring strong security, so naturally, security professionals are very curious about how this best practice goes down from the pen tester perspective. Jack Daniel, Director of Services at Rapid7 with 13 years of penetration testing under his belt, recently shared which flaws pen testers are regularly using to access sensitive data on the job in the webcast, “Campfire Horror Stories: 5 Most Common Findings in Pen Tests”. Read on for the top takeaways from this webcast:Patching & Passwords – Patching trends have shown great progress over the last few years but are still a large area of concern. Organizations have adopted patching standards, and are certainly more mature compared to 5-8 years. The bulk of systems, especially critical patches, are being patched regularly. However, pen testers still find organizations are missing critical patches from years and years ago, even if they are up-to-date with recent patches. As for passwords, when pen testers are able to gain access and do a massive password dump or brute forcing, over 30% of passwords include variations of an employee's company name or their company's product names. Pen testers are able to quickly work around or crack weak passwords and password hashes. To avoid these pitfalls, make sure passwords are audited regularly, don't use weak roots, and do not store password hashes locally.Beware the Default – Misconfigurations and default configurations are consistently the number 1 most common finding for penetration testers as an issue at almost every organization. If configurations are not regularly reviewed, it can lead to accidental information leaks. A default account left enabled on a device that gets rolled out without a security review is a quick foothold into any network. A system that is different from most others on a network, and outliers within the network in general, are also weak points for attackers to focus on since they know securing an outlier device will require additional expertise from the security team. To prepare for misconfiguration and default configuration issues, know your network and what it will look like to an attacker, and segment wherever possible so that a blind spot cannot spiral into a devastating breach.Encryption Good, XSS Bad – Storing or transmitting sensitive data in clear text and cross site scripting are two other common missteps that pen testers come across. Data left unencrypted is completely reliant on network controls for protection and vulnerable to attackers. Put an emphasis on securing an app or device itself, and encrypt your data while storing or transmitting it, keeping in mind that databases tend to be less secure. Web flaws and cross site scripting are becoming more pervasive. To combat this, ensure your users and their browsers have client side scripts disabled wherever possible.  To learn more about the most common findings in pen tests: view the on-demand webinar now.