Rapid7 Blog

Authentication  

R7-2017-07: Multiple Fuze TPN Handset Portal vulnerabilities (FIXED)

This post describes three security vulnerabilities related to access controls and authentication in the TPN Handset Portal, part of the Fuze platform. Fuze fixed all three issues by May 6, 2017, and user action is not required to remediate. Rapid7 thanks Fuze for their quick…

This post describes three security vulnerabilities related to access controls and authentication in the TPN Handset Portal, part of the Fuze platform. Fuze fixed all three issues by May 6, 2017, and user action is not required to remediate. Rapid7 thanks Fuze for their quick and thoughtful response to these vulnerabilities: R7-2017-07.1, CWE-284 (Improper Access Control): An unauthenticated remote attacker can enumerate through MAC addresses associated with registered handsets of Fuze users. This allows them to craft a URL that reveals details about the user, including their Fuze phone number, email address, parent account name/location, and a link to an administration interface. This information is returned over HTTP and does not require authentication. R7-2017-07.2, CWE-319 (Cleartext Transmission of Sensitive Information): The administration interface URL revealed from the URLs enumerated in R7-2017-07.1 will prompt for a password over an unencrypted HTTP connection. An attacker with a privileged position on the network can capture this traffic. R7-2017-07.3, CWE-307 (Improper Restriction of Excessive Authentication Attempts): Authentication requests to the administration portal do not appear to be rate-limited, thus allowing attackers to potentially find successful credentials through brute-force attempts. Product Description Fuze is an enterprise, multi-platform voice, messaging, and collaboration service created by Fuze, Inc. It is described fully at the vendor's website. While much of the Fuze suite of applications are delivered as web-based SaaS components, there are endpoint client applications for a variety of desktop and mobile platforms. Credit These issues were discovered by a Rapid7 user, and they are being disclosed in accordance with Rapid7's vulnerability disclosure policy. Exploitation R7-2017-07.1 Any unauthenticated user can browse to http://mb.thinkingphones.com/tpn-portlet/mb/MACADDRESS and, if a valid MAC address is provided in place of MACADDRESS, receive a response that includes the following data about a Fuze handset user: Owner email address Account (including location information) Primary phone number Administration portal link Here is a (redacted) example of retrieving the above information using Fuze's TPN Portlet: While the total possible MAC address space is large (48 bits), the practical space in this case is significantly less. An attacker would only need to enumerate options starting with related published OUIs to target the subset of MAC addresses for Polycom and Yealink phones, which are the officially supported phone brands that Fuze offers as outlined here. For example, Polycom's OUIs are 00:04:F2 and 64:16:7F. An attacker can use this information to enumerate all Fuze customers/users with hard phones and collect their their email addresses, their phone numbers, and also access the Fuze device admin login page (shown below) and potentially make configuration changes. While it is common for handsets to request configuration from a remote server during boot, and indeed for those requests to not be authenticated, the fact that the configuration server is located in the cloud versus on-prem, and the fact that the specific URLs are crafted using a known pattern of MAC addresses, adds an unexpected surface for undesired information disclosure. R7-2017-07.2 Network traffic between a handset and the TPN Portal (http://mb.thinkingphones.com/tpn-portlet/mb/MACADDRESS/admin.jsp) are made over HTTP. Thus if an attacker is able to capture/intercept network traffic while the handset boots up, they would be able to view the content of requests made to the Portal, including the admin code, as shown below: R7-2017-07.3 If an attacker was not listening to network traffic during handset boot, they could still determine the administration portal URL by MAC enumeration as mentioned in R7-2017-07.1. Given that URL, the attacker could try various admin codes until they are successfully logged in, as it does not appear that authentication attempts are limited. Remediation Fuze addressed R7-2017-07.1 on April 29, 2017 by requiring password authentication to access the TPN portal (http://mb.thinkingphones.com/tpn-portlet/mb/MACADDRESS), and R7-2017-07.2 on May 6, 2017 by encrypting traffic to the TPN portal. No user action is required to remediate these two issues. Hashed passwords were pushed out by Fuze to customer handsets during a daily required update check. Handsets were also configured to use TLS for future communication with the portal at that time. After this update was pushed, Fuze's servers were configured to deny unauthenticated requests, as well as requests made over HTTP. If any handsets did not receive these updates, users would not be able to perform some actions from the handset directly, such as re-assigning to a new user. This may impact a small number of users, who should work with Fuze support to resolve. Phone re-assignment and other configuration changes can still be made and pushed from the Fuze server side. More importantly, if a handset did happen to be offline during the initial update push, once back online it would still be able to download firmware updates and essential configuration updates, including those related to SIP and TLS requirements. Fuze addressed R7-2017-07.3 on May 6, 2017 by rate limiting authentication attempts to the administration portal. In addition, MAC enumeration to find URLs providing the administration portal URLs is no longer possible given the authentication requirement. No user action is required to remediate this issue, as the change was made to Fuze's servers. Vendor Statement Rapid7 is a Fuze customer and a highly valued voice in ensuring that Fuze is continuously improving the security of its voice, video, and messaging service. As users of the entire Fuze platform, Rapid7’s team identified security weaknesses and responsibly disclosed them to the Fuze security team. In this case, while the exposure was a limited set of customer data, Fuze took immediate action upon receiving notification by Rapid7, and remediated the vulnerabilities with its handset provisioning service, in full, within two weeks. Fuze has no evidence of any bad actors exploiting this vulnerability to compromise customer data. Fuze is grateful to Rapid7 for its continued partnership in responsibly sharing security information, and believes in its larger mission to normalize the vulnerability disclosure process across the entire software industry. -- Chris Conry, CIO of Fuze* Disclosure Timeline Wed, Apr 12, 2017: Issues discovered by Rapid7 Tue, Apr 25, 2017: Details disclosed to Fuze Sat, Apr 29, 2017: R7-2017-07.1 fixed by Fuze Sat, May 6, 2017: R7-2017-07.2 and R7-2017-07.2 fixed by Fuze Tue, May 23, 2017: Disclosed to CERT/CC Fri, May 26, 2017: CERT/CC and Rapid7 decided no CVEs are warranted since these issues exist on the vendor's side, and customers do not need to take action. Tue, Aug 22, 2017: Public disclosure

Better Credential Management for Better Vulnerability Results

Often the first time the security team knows that credentials have expired is when their scans start to return dramatically fewer vulnerabilities. We all know getting credentialed access yields the best results for visibility. Yet, maintaining access can be difficult. Asset owners change credentials. Different…

Often the first time the security team knows that credentials have expired is when their scans start to return dramatically fewer vulnerabilities. We all know getting credentialed access yields the best results for visibility. Yet, maintaining access can be difficult. Asset owners change credentials. Different assets have different frequencies for credential updates. Security teams are often left out of the loop. Between the original scan run time, the time it takes the security team to pinpoint that credential status is the cause of the problem, correcting the credential data, and re-running the scan—too much time has elapsed that could have been utilized by security groups. What security teams need is a way to bypass these hassles by leveraging credential management solutions that are currently in play. This way, credentials are not stored in the vulnerability management system and are handled ephemerally, as they should be. This results in not only increased efficiency and less frustration for security teams, but also better security by having credentials be stored and managed centrally via CyberArk. We are pleased to announce that as part of the May 24th, 2017 release, Nexpose and InsightVM (Security Console 6.4.39) have been integrated with CyberArk Enterprise Password Vault to enable credentialed scans while minimizing administrative effort. The CyberArk integration, which is in-product, will work with either specific credentials or shared credentials for a given asset and will allow your team, no matter the size, to spend less time looking after your tools and more time on your security program. You can: Query for credentials dynamically based on: Address: The IP address or fully qualified domain name (FQDN) for the asset. Object Name: The name of the object that stores the credentials. Username: The username for the account that will be retrieved Policy ID: The policy ID that is assigned to the credentials that will be retrieved. Custom Attributes: Custom Key/Value pairs in CyberArk Manage credential management preferences at the Site level or globally. Getting Started Help documentation, CyberArk Support, or contact your CSM or Rapid7 Support.

Metasploit Framework Valentines Update

Valentines day is just around the corner! What could be a nicer gift for your sweetie than a bundle of new Metasploit Framework updates? The community has been as busy as ever delivering a sweet crop of sexy exploits, bug fixes, and interesting new features.…

Valentines day is just around the corner! What could be a nicer gift for your sweetie than a bundle of new Metasploit Framework updates? The community has been as busy as ever delivering a sweet crop of sexy exploits, bug fixes, and interesting new features. Everyone Deserves a Second Chance Meterpreter Scripts have been deprecated for years in favor of Post Exploitation modules, which are much more flexible and easy to debug. Unfortunately, the Internet still abounds with blogs and other advice still recommending their use, and it is clear the word still hasn't gotten out. In a previous Metasploit release, we attempted an experiment removing all of the scripts that already had Post Exploitation modules. Unfortunately, this caused even more confusion since it looked like Metasploit was broken. Now, Metasploit will kindly suggest that users explore the vast world of Post modules instead. For now, all of the built-in Meterpreter scripts you know and love are back for one last dance, but you should really look at dumping those guys. Remember, there are many more Post modules in the sea! Traverse your Way into my Life With this release, we have a number of directory traversal updates, both offensive and defensive. First off, we have added a module for exfiltrating arbitrary data from a Cisco Firepower management console. The default credentials are also documented, so if you run into one of these in the wild, there is a good chance you can make a special connection. And in the "it's not you, it's me" department, Justin Steven has been busy finding and fixing a number of directory traversal bugs in Metasploit's session handler, that can be exploited if you interact with a rogue Meterpreter session. Of course you should practice "safe sess(ions)", but if you can't, update your Metasploit Framework and get protected. You Stole my Creds, my Phone, my Car, and my Heart If you're looking for credentials to add to your little black book, Metasploit release also adds credential extraction modules for Advantech WebAccess, Metrocontrol Weblog, and Cisco Firepower Management Console. And once you have filled your cred list, you can now manipulate them in a more powerful way thanks to improvements in credential management. Android Meterpreter adds a number of new features sure to make keeping up with your bae even easier (that doesn't sound creepy at all does it!) Android Meterpreter now supports stageless HTTPS, which makes it easier to keep your payloads secure, fast, and reliable. If you have trouble with your Android sessions falling asleep after you connect, keep them going all night (and day) long with the new wakelock command. Metasploit makes its first foray into car hacking with a new hardware bridge session type, along with a number of new modules for administering and exploiting OBD-II / CANbus networks in modern vehicles. But, it's not limited to just these, you can add your own hardware devices by implementing the HWBridge specification. Don't let your car spoil your next date, hack back! There are many more improvements and modules to enjoy as well, and they are all available now. So why not update your console with someone special, and make everyday a very special Metasploit Valentines day. For full details, see the latest detailed Metasploit release notes: https://community.rapid7.com/docs/DOC-3575

Under the Hoodie: Actionable Research from Penetration Testing Engagements

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…

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.

The Twelve Pains of Infosec

One of my favorite Christmas carols is the 12 Days of Christmas. Back in the 90's, a satire of the song came out in the form of the 12 Pains of Christmas, which had me rolling on the floor in laughter, and still does. Now…

One of my favorite Christmas carols is the 12 Days of Christmas. Back in the 90's, a satire of the song came out in the form of the 12 Pains of Christmas, which had me rolling on the floor in laughter, and still does. Now that I am in information security, I decided it is time for a new satire, maybe this will start a new tradition, and so I am presenting, the 12 Pains of Infosec. The first thing in infosec that's such a pain to me is your password policy The second thing in infosec that's such a pain to me is default credentials, and your password policy The third thing in infosec that's such a pain to me is falling for phishing, default credentials, and your password policy The fourth thing in infosec that's such a pain to me is patch management, falling for phishing, default credentials, and your password policy The fifth thing in infosec that's such a pain to me is Windows XP, patch management, falling for phishing, default credentials, and your password policy The sixth thing in infosec that's such a pain to me is Lack of input filtering, Windows XP, patch management, falling for phishing, default credentials, and your password policy The seventh thing in infosec that's such a pain to me is no monitoring, lack of input filtering, Windows XP, patch management, falling for phishing, default credentials, and your password policy The eighth thing in infosec that's such a pain to me is users as local admins, no monitoring, Lack of input filtering, Windows XP, patch management, falling for phishing, default credentials, and your password policy The ninth thing in infosec that's such a pain to me is lack of management support, users as local admins, no monitoring, lack of input filtering, Windows XP, patch management, falling for phishing, default credentials, and your password policy The tenth thing in infosec that's such a pain to me is testing for compliance, lack of management support, users as local admins, no monitoring, lack of input filtering, Windows XP, patch management, falling for phishing, default credentials, and your password policy The eleventh thing in infosec that's such a pain to me is no asset management, testing for compliance, lack of management support, users as local admins, no monitoring, lack of input filtering, Windows XP, patch management, falling for phishing, default credentials, and your password policy The twelfth thing in infosec that's such a pain to me is trust in antivirus, no asset management, testing for compliance, lack of management support, users as local admins, no monitoring, Lack of input filtering, Windows XP, patch management, falling for phishing, default credentials, and your password policy The first thing in infosec that's such a pain to me is your password policy When I go into organizations for penetration tests, one of the easiest ways to get in is through password guessing. Most organizations use a password policy of 8 characters, complexity turned on, and change every 90 days. So, what do the users do? They come up with a simple to remember password that will never repeat. Yes, I am talking about the infamous Winter16 or variations of season and year. If they aren't using that password, then chances are it is something just as simple. Instead, set a longer password requirement (12 characters or more) and blacklist common words, such as password, seasons, months, and company name. The second thing in infosec that's such a pain to me is default credentials The next most common finding I see is the failure to change default credentials. It is such a simple mistake, but one that can cost your organization a ton! This doesn't just go for web apps like JBOSS and Tomcat, but also for embedded devices. Printers and other embedded devices are a great target since the default credentials aren't usually changed. They often hold credentials to other systems to help gain access or simply can be used as a pivot point to attack other systems. The third thing in infosec that's such a pain to me is falling for phishing Malicious actors go for the weakest link. Often this is the users. Sending a carefully crafted phishing email is almost 100% successful. In fact, even many security professionals fall victim to phishing emails. So, what can we do about it? Well, we must train our employees regularly to spot phishing attempts as well as encourage and reward them for alerting security on phishing attempts. Once reported, add the malicious URL to your blacklist, and redirect to a phishing education page. And for goodness sake, Security Department, please disable the links and remove any tags in the email before forwarding off as "education". The fourth thing in infosec that's such a pain to me is patch management There are so many systems out there. It can be hard to patch them all, but having a good patch management process is essential. Ensuring our systems are up to date with the latest patches will help protect those systems from known attacks. It is not just operating system patches that need to be applied, also for any software you have installed. The fifth thing in infosec that's such a pain to me is Windows XP Oh Windows XP, how I love and hate thee. Even though Windows XP support went the way of the dodo back in 2014, over 2.5 years later I still see it being used in corporate environments. While I called out Windows XP, it is not uncommon to see Windows 2000, Windows Server 2003, and other unsupported operating system software. While some of the issues with these operating systems have been mitigated, such as MS08_067, many places have not applied the patches or taken the mitigation tactics. That is not to mention what unknown security vulnerabilities that exist and will never be patched. Your best bet is to upgrade to a supported operating system. If you cannot for some reason (required software will not run on newer operating systems), segregate the network to prevent access to the unsupported systems. The sixth thing in infosec that's such a pain to me is lack of input filtering We all know and love the OWASP Top 10. Three of the top 10 is included in this pain. Cross-Site Scripting (XSS), SQL Injection (SQLi), HTML Injection, Command Injection, and HTML Redirects are all vulnerabilities that can be solved fully, or at least partially in the case with XSS, with input filtering. Web applications that perform input filtering will remove bad characters, allow only good characters, and perform the input filtering not at the client-side, but at the server-side. Then using output encoding/filtering, XSS is remediated as well. The seventh thing in infosec that's such a pain to me is no monitoring In 1974, Muhammad Ali said “His hands can't hit what his eyes can't see” referring to his upcoming fight with George Foreman. This quote bodes true in Infosec as well. You cannot defend what you cannot see. If you are not performing monitoring in your network, and centralized monitoring so you can collaborate the logs, you will miss attacks. As Dr. Eric Cole says “Prevention is ideal, but detection is critical.” This is also critical to REVIEW the logs, meaning you will need good people that know what they are looking for, not just good monitoring software. The eighth thing in infosec that's such a pain to me is users as local admins Though for years we have been suggesting to segregate user privileges, yet almost every penetration test I perform I find this to be an issue. Limiting use of accounts to only what is needed to do their job is very hard, but essential to secure your environment. This means not giving local administrator privileges to all users but also using separate accounts for managing the domain, limiting the number of privileged accounts, and monitoring the use of these accounts and group memberships. The ninth thing in infosec that's such a pain to me is lack of management support How often do I run into people who want to make a change or changes in their network, yet they do not get the support needed from upper management? A LOT! Sometimes an eye-opening penetration test works wonders. The tenth thing in infosec that's such a pain to me is testing for compliance I get it, certain industries require specific guidelines to show adequate security is in place, but when you test only for compliance sake, you are doing a disservice to your organization. When you attempt to limit the scope of the testing or firewall off the systems during the test, you are pulling a blinder over your eyes, and cannot hope to secure your data. Instead, use the need for testing to meet compliance a way to get more management support and enact real change in the organization. The eleventh thing in infosec that's such a pain to me is no asset management You can't protect what you don't know about. In this regard, employ an asset management system. Know what devices you have and where they are located. Know what software you have, and what patch levels they are at. I can't tell you how many times I have exploited a system and my customer says “What is that? I don't think that is ours”, only to find out that it was their system, they just didn't have good asset management in place. The twelfth thing in infosec that's such a pain to me is trust in antivirus A few years ago, I read that antivirus software was only about 30% effective, leading to headlines about the death of antivirus, yet it still is around. Does that mean it is effective in stopping infections on your computer? No. I am often asked “What is the best antivirus I should get for my computer?” My answer is usually to grab a free antivirus like Microsoft Security Essentials, but be careful where you surf on the internet and what you click on. Antivirus will catch the known threats, so I believe it still has some merit, especially on home computers for relatives who do not know better, but the best protection is being careful. Turn on “click to play” for Flash and Java (if you can't remove Java). Be careful what you click on. Turn on an ad blocker. There is no single “silver bullet” in security that is going to save you. It is a layering of technologies and awareness that will. I hope you enjoyed the song, and who knows, maybe someone will record a video singing it! (not me!) Whatever holiday you celebrate this season, have a great one. Here's to a more secure 2017 so I don't have to write a new song next year. Maybe “I'm dreaming of a secure IoT” would be appropriate.

Avoiding Default Fail

As the Internet of Things (IoT) quickly flood into the market place, into our homes and into our places of employment, my years of pen testing experience and every research project I spin up reminds me IoT has weak defaults -- especially default passwords, which…

As the Internet of Things (IoT) quickly flood into the market place, into our homes and into our places of employment, my years of pen testing experience and every research project I spin up reminds me IoT has weak defaults -- especially default passwords, which will be the undoing of all of us. You would think after pointing out the issues with default password for years most of us would learn to start changing those passwords before deployment. Unfortunately that's not the case. I think we are aware of the massive Distributed Denial of Service (DDoS) attacks that have taken place and impacting availability of resources and services on the Internet over the last couple weeks. Malware infected IoT devices are being used to cause these DDoS.  The malware, also know as Mirai, leveraged default passwords in IoT devices to infect these devices and mark them as part of a large Bot-Net which was then used to conduct DDoS attacks. As we begin to use IoT-based technology more, we need to be diligent about how default settings, such as passwords, are maintained. As shown by these DDoS attacks, if we do not properly reconfigure the passwords on our devices when they are deployed, then they could potentially be used to cause mayhem on the internet, impacting us all. To go beyond the simple network service password issues we have other default settings that are typically overlooked. The two that come to mind are Wi-Fi SSID and WPA/WPA2 Pre shared keys. Since a large number of the IoT based technologies also utilize Wi-Fi services, we need to take a closer look at these solutions during deployment. First, lets talk about the Service Set Identifier SSID. SSID is the human readable name that gets assigned to the wireless network. You may be thinking, "what's wrong with the SSID name? It can't be used to attack me." Maybe not directly, but it does often reveal the product details that have been deployed and that information can then be used by a malicious actor to plan out how he or she can attack you. I always encourage users to rename the SSID to something completely different and unrelated to yourself or your location. This may not stop a knowledgeable attacker but at least it doesn't make their job easier. Next are Wi-Fi passwords, typically referenced as Pre-Shared Keys (PSK). Though the default setting of the PSK may appear to be complex (Figure 1), it is not and in many cases is easily cracked in a short period of time. For example, if a malicious actor is successful in identifying the product that is in use, they can then identify the standard default PSK length and pattern being used. This information can then be leveraged further to decrease the length of time needed to crack the PSK. So the solution is to never trust the defaults, but rather change the defaults when you deploy the technology. So when it comes to proper use of passwords, whether network or Wi-Fi, I would recommend a long password that is at least 32 characters, contains alpha numeric, upper and lower case, and a special character. I know such passwords can be difficult or impossible to remember, I feel your pain. So another option is passphrases. Passphrases can be difficult to guess and crack, but often are easy for the owner to remember because it has meaning to them. For example the phrase “My favorite vacation was in Peru” is 32 characters including spaces, making it hard to guess. It has meaning to me, the owner, so I can more easily remember it. If you want to make this password even better, you could easily change some characters to numbers or special characters and modify the case on other characters. *For example “my faVorit3 vaCation wa$ in Peru.” It's the same phrase just made more secure with a few simple alterations. With these minor alterations, it makes the passphrase more complex and it is unlikely anyone will ever guess or easily crack your password. *Editor's Note: This is not Deral's password, and it shouldn't be yours either. It's already been used on the internet!

NCSAM: You Should Use a Password Manager

October is National Cyber Security Awareness month and Rapid7 is taking this time to celebrate security research. This year, NCSAM coincides with new legal protections for security research under the DMCA and the 30th anniversary of the CFAA - a problematic law that hinders beneficial…

October is National Cyber Security Awareness month and Rapid7 is taking this time to celebrate security research. This year, NCSAM coincides with new legal protections for security research under the DMCA and the 30th anniversary of the CFAA - a problematic law that hinders beneficial security research. Throughout the month, we will be sharing content that enhances understanding of what independent security research is, how it benefits the digital ecosystem, and the challenges that researchers face. This year, NCSAM is also focused on taking steps towards online safety, including how to have more secure accounts. In 2016, just like in most of the last 15 years, we learned new information about recent and not so recent data breaches at large organizations, during which sensitive account information was made public. Essentially, these breaches have unearthed data on what puts accounts at higher risk for a breach. Putting aside the concerns about non-password account information being made public, one of the factors that determines how bad a data breach is for users is the format of leaked passwords. Are they plaintext? Plaintext passwords are just the actual password that a user would type. For example, the password "taco" is stored as "taco" and when made public, can be used by an attacker right away. Have they been hashed? Hashed passwords are mathematical one way transformations of the original password, meaning that it is easy to transform the password into a hash, but given a hash, it's very difficult to recover the original password. For example, the password "taco" is stored as "f869ce1c8414a264bb11e14a2c8850ed" when hashed with the MD5 hash algorithm, and the attacker must recover the original password from this hash in order to use it. Have they been salted and hashed? Hashed passwords are good, but there are several tools and methods that can be used to try to reveal the original password. There are even dictionaries that connect hashes back to their original passwords. Submitting "f869ce1c8414a264bb11e14a2c8850ed" to http://md5.gromweb.com/ reveals that the word "taco" was used to generate that hash. Adding a "salt" to a password, means to add extra data to it before it gets hashed. For example, the password "taco" is combined with the word "salsa" before being hashed, and the resulting hash is stored as "6b8dc43f9be3051e994cafdabadc2398". Now, an attacker looking up the hash "6b8dc43f9be3051e994cafdabadc2398" in a dictionary won't find anything, and will be forced to create a new dictionary which ideally is time consuming. Have they been hashed with a well studied unbroken algorithm? The MD5 algorithm has known attacks against it, so it is a good idea to use another algorithm. Have they been hashed multiple times? Or with a computationally expensive algorithm? Or with a memory expensive algorithm? These and other questions get into the nitty gritty of how passwords can be stored scurely so that they are of little use to an attacker once they are made public. Luckily, there are plenty of resources for security engineers to follow in order to make their sites more secure, and in particular, their storage of passwords more secure even if they are disclosed. Dropbox has an interesting post about how they store passwords, and this talk by Alec Muffet from Facebook, which describes their methods for storing passwords, is really interesting. In fact, there is an entire conference dedicated to passwords and the engineering that goes into keeping them secure. This site tracks published details about password storage polices of various sites, and this presentation provides the motivation for doing so. That's great, but I'm not a security engineer, what do I need to know about passwords? There is an unending list of articles, blog posts, howto guides and comics written about passwords. Passwords are going away. Passwords will eventually go away. Passwords are here to stay. Passwords are insecure. Two factor authentication will save us all. Biometrics will save us all. Whatever your opinion you probably have multiple accounts with multiple websites and ideally you're using multiple passwords. It's a good idea to recognize that whether or not the sites you use are doing a good job of protecting your passwords, you too can take steps to make your password use more secure. If you take nothing else away from this post, remember to setup a password manager (there are many), actually use it to create different passwords for each account you have, routinely look into whether your account information has been leaked recently, and if it has, change the password associated with that account. What's the big deal? If you have an account with an online service, like an email provider, a social network, or an ecommerce site, then it is very likely that you have a password associated with that account. It's also likely that you have more than a few accounts, and having so many accounts you have most likely been tempted to use the same or similar usernames and passwords across accounts. While there are clear benefits (among some privacy / tracking drawbacks) to having a consistent identity across services (ironicjen182@gmail.com, ironicjen182@facebook.com, ironicjen182@totallylegitonlinebusiness.biz), there are clear drawbacks to using the same password across services, mainly that if one of these services is attacked and account information is leaked, your accounts with identical or similar usernames at the other services could be vulnerable to misuse by an attacker. Ok, but who cares? It's just my (hotmail | twitter | ebay | farmersonly) account. You should care, these accounts paint a very detailed picture of who you are and what you do. For instance, you email has a record of emails you have sent and of those sent to you, and from that an attacker can learn a surprising amount about you. With email providers that offer effectively unlimited email storage and provide little incentive for users to erase emails, it's nearly impossible for a user to be sure that nothing useful to an attacker is buried somewhere inside. Furthermore, your email (and social media accounts) are effectively an extension of you. When an attacker has control of your account, emails, tweets, snaps sent from your account are accepted as coming from you, and attackers can take advantage of those assumptions and the trust that you've built up with you contacts. For example, consider the Stranded Traveler Scam in which an attacker sends a message to one or more of your contacts claiming to be in a bad situation somewhere far away, and if they could just wire some money, things would surely work out. There are news reports about these types of scams all the time (2011, 2011, 2012. 2013, 2014, 2015, 2016) Because the email has come from your account and bears your name, your relatives, friends and coworkers are more likely to believe it is actually you writing the message than a scammer. Similar attacks involve sending malware in attachments and requesting wire transfers for family members or executives, or requesting w-2 forms for employees. None of these attacks require that takeover of your account, but are certainly strengthened by it. Really, how often does this happen? Can't I just deal with it when I hear about it on the news? You could do that, and it would be better than not doing anything at all, but breaches that leak account information happen surprisingly frequently and they don't always make the news that you read. Sometimes, we don't learn about them for weeks or years after they happen, meaning that passwords you used a long time ago may have been known to attackers for a while before you were made aware of a breach. Is my password really out there? Sometimes. Maybe. It's hard to say. Often, sites will hash passwords before they are stored. However, different sites use different hash methods which have different security characteristics, and some methods previously believed to be secure are no longer considered so. Shouldn't these sites be more secure? That would be nice, but data security is a difficult and quickly changing field and not every site prioritizes security as highly as you might like. Fine, what should I do? You should to a few things: Use a password manager There are many password managers available to you, like LastPass, 1Password, KeepassX or if you're into the command line, try out pass. Use a different password for every account you have Now that you have a password manager storing all your passwords, there's no need to reuse passwords Use complex passwords Most password managers can create long random strings of letters, numbers and symbols for you. Since the password manager stores these passwords and you don't have to remember them, there's no need to use simple or short passwords. Keep an eye on sites that catalog leaked account information. Have a look from time to time at sites that keep track of leaked accounts to see if your account has been leaked. haveibeenpwned.com is usually kept up to date and is easy to use.

InsightIDR & Nexpose Integrate for Total User & Asset Security Visibility

Rapid7's Incident Detection and Response and Vulnerability Management solutions, InsightIDR and Nexpose, now integrate to provide visibility and security detection across assets and the users behind them. Combining the pair provides massive time savings and simplifies incident investigations by highlighting risk across your network ecosystem…

Rapid7's Incident Detection and Response and Vulnerability Management solutions, InsightIDR and Nexpose, now integrate to provide visibility and security detection across assets and the users behind them. Combining the pair provides massive time savings and simplifies incident investigations by highlighting risk across your network ecosystem without writing queries or digging through logs.Nexpose proactively identifies & prioritizes weak points on your network, while InsightIDR helps find unknown threats with user behavior analytics, prioritizes where to look with SIEM capabilities, and combines endpoint detection and visibility to leave attackers with nowhere to hide. Let's look at three specific benefits: (1) putting a "face" to your vulnerabilities, (2) automatically placing vulnerable assets under greater scrutiny, and (3) flagging users that use actively exploitable assets.User Context for Your VulnerabilitiesInsightIDR integrates with your existing network & security infrastructure to create a baseline of your users' activity. By correlating all activity to the users behind them, you're alerted of attacks notoriously hard to detect, such as compromised credentials and lateral movement.When InsightIDR ingests the results of your Nexpose vulnerability scans, vulnerabilities are added to each user's profile. When you search by employee name, asset, or IP address, you get a complete look at their user behavior:How this saves you time:See who is affected by what vulnerability – this helps you get buy-in to remediate a vulnerability by putting a face and context on a vulnerability. (“The CFO has this vulnerability on their laptop – let's prioritize remediation.”)Have instant context on the user(s) behind an asset, so you accelerate incident investigations and can see if the attacker laterally moved beyond that endpoint.Proactively reduce your exposed attack surface, by verifying key players are not vulnerable.Automatic Security Detection for Critical AssetsIn Nexpose, you can dynamically tag assets as critical. For example, they may be in the IP range of the DMZ or contain a particular software package/service unique to domain controllers. Combined with InsightIDR, that context extends to the users that access these assets.When InsightIDR ingests scan results, assets tagged as critical are labeled in InsightIDR as Restricted Assets. This integration helps you automatically place vulnerable assets under greater detection scrutiny.Some examples of alerts for Restricted Assets:First authentication from an unfamiliar source asset: InsightIDR doesn't just alert on the IP address, but whenever possible, shows the exact users involved.An unauthorized user attempts to log-in: This can include a contractor or compromised employee attempting to access a financial server.A unique or malicious process hash is run on the asset: A single Insight Agent deployed on your endpoints performs both vulnerability scanning and endpoint detection. Our vision is to reliably find intruders earlier in the attack chain, which includes identifying every process running on your endpoints. We run these process hashes against the wisdom of 50 virus scanners to identify malicious processes, as well as identify unique processes for further investigation.Lateral movement (both local and domain): Once inside your organization's network, intruders typically run a network scan to identify high-value assets. They then laterally move across the network, leaving behind backdoors & stealing higher privilege credentials.Endpoint log deletion: After compromising an asset, attackers look to delete system logs in order to hide their tracks. This is a high-confidence indicator of compromise.Anomalous admin activity, including privilege escalation: Once gaining access to an asset or endpoint, attackers use privilege escalation exploits to gain admin access, allowing them to dump creds or attempt pass-the-hash. We identify and alert on anomalous admin activity across your ecosystem.Identifying Users that Use Exploitable AssetsMany Nexpose customers purchase Metasploit Pro to validate their vulnerabilities and test if assets can be actively exploited in the wild. As an extension of the critical asset functionality above, customers that own all three products can automatically tag assets that are exploited by Metasploit as critical, and thus mark these as restricted assets in InsightIDR. This ensures that assets which are easy to breach are placed under higher scrutiny until the exploitable vulnerabilities are patched.Configuring the InsightIDR-Nexpose IntegrationIf you have InsightIDR & Nexpose, setting up the Event Source is easy.1. In Nexpose, setup a Global Admin. 2. In InsightIDR, on the top right Data Collection tab -> Setup Event Source -> Add Event Source.3. Add the information about the Nexpose Console (Server IP & Port).4. Add the credentials of the newly created Global Admin.And you're all set! If you have any questions, reach out to your Customer Success Manager or Support. Don't have InsightIDR and want to learn how the technology relentlessly hunts threats? Check out an on-demand 20 minute demo here.Nathan Palanov contributed to this post.

800 Million Compromised Credentials Were Exposed This Month. Were You Notified?

In our previous post on third party breaches, we talked about the risk of public compromised credential leaks providing attackers with another ingress vector. This August, InsightIDR, armed with knowledge from a partner, identified a “Very Large Credentials Dump”. Very large? Over 800 million compromised…

In our previous post on third party breaches, we talked about the risk of public compromised credential leaks providing attackers with another ingress vector. This August, InsightIDR, armed with knowledge from a partner, identified a “Very Large Credentials Dump”. Very large? Over 800 million compromised credentials including usernames, passwords, and password hashes were exposed. This pool includes publicly known credential dumps as well as those where the breach source has not been disclosed, but they are available for attackers to re-purpose. Across our hundreds of customers using InsightIDR to monitor their ecosystem 177 alerts were generated across our U.S. customers 50 alerts were generated across our EMEA & APAC customers Many customers have already reached out to us to learn more about the alert and, whenever possible, we can provide the exposed passwords and hashes to your team. Below is an example of the alert in InsightIDR (click to expand): By highlighting this security risk, teams can proactively reset passwords before attackers try their hand. Even better, this is only one of the many detections built in InsightIDR to help you find threats earlier in the attack chain, before intruders breach critical assets. Related Resource: [Video] Understanding the Attack Chain to Detect Intruders If any users are identified at-risk, one click brings up their user page to see authentications, asset info, cloud services, and more. Today, our corporate emails not only log into network services, but also cloud services such as Office 365, Salesforce, and Box. As InsightIDR has direct API integrations with those services, you'll know about any suspicious authentications, whether it be from an unusual location or anomalous admin activity. By applying User Behavior Analytics to link together IP Addresses, Assets, and Users, InsightIDR detects the top attack vectors behind breaches, including phishing, compromised credentials, and malware. I received this alert. What can I do? For affected accounts, we recommend resetting the account password & adding the user to the InsightIDR Watchlist. If you'd like more on the credential dump, please use the in-app feedback button, which automatically opens an InsightIDR support ticket. Alternatively, feel free to email support@rapid7.com. If available, we can further share the exact passwords and hashes in the dump upon request. As an added value, if you have other company-owned domains, we can add the domain name to be monitored for future third party breaches. I want to receive these alerts. What can I do? Take a serious look at InsightIDR (you can see an on-demand demo here), which not only combines the best capabilities of SIEM, UBA, and EDR, but prioritizes finding intruders earlier in the attack chain, before they cause damage. See our latest webcast on how organizations are benefiting from User Behavior Analytics, or contact us for a free guided demo.

Credential Status in Reporting Data Model

The new version of Reporting Data Model (1.3.1) allows Nexpose users to create CSV reports providing information about credential status of their assets, i.e. whether credentials provided by the user (global or site specific) allowed successful login to the asset during a…

The new version of Reporting Data Model (1.3.1) allows Nexpose users to create CSV reports providing information about credential status of their assets, i.e. whether credentials provided by the user (global or site specific) allowed successful login to the asset during a specific scan. Credential Status Per Service The new Reporting Data Model version contains fact_asset_scan_service enhanced with the new column containing the information about credential status for an asset per service during the particular scan. Credential status information is provided for five services: SNMP (version 1, 2c and 3), SSH, Telnet, CIFS and DCE Endpoint Resolution. For these services the following credential statuses can be reported: Credential status Relevant Services No credentials supplied SNMP, SSH, Telnet, CIFS, DCE Endpoint Resolution Login failed SNMP, SSH, Telnet, CIFS, DCE Endpoint Resolution Login successful SNMP, SSH, Telnet, CIFS, DCE Endpoint Resolution Allowed elevation of privileges SSH Root SSH and Telnet Login as local admin CIFS, DCE Endpoint Resolution Newly added dimension dim_asset_service_credential can be used to report on the most recent credential statuses asserted for services on an asset in the last scan performed on this asset. Both fact_asset_scan_service and dim_asset_service_credential can be joined with the newly added dim_credential_status which provides the above statuses in a human readable form. Examples of queries which can be used to report the credential status per asset per service can be found in the document listed at the bottom. Credential status across services Nexpose users can now create reports providing the snapshot of credential statuses for an asset, i.e. information about credential status for an asset aggregated across all services discovered in the scan. The newly enhanced fact_asset and fact_asset_scan now report the following statuses: Credential status Description No credentials supplied At One or more services for which credential status is reported were detected in the scan, but there were no credentials supplied for any of them. All credentials failed At One or more services for which credential status is reported were detected in the scan, and all credentials supplied for these services failed to authenticate. Credentials partially successful At least two of the four services for which credential status is reported were detected in the scan, and for some services the provided credentials failed to authenticate, but for at least one there was a successful authentication. All credentials successful One or more services for which credential status is reported were detected in the scan, and for all of these services for which credentials were supplied authentication with provided credentials was successful. N/A At None of the five applicable services (SNMP, SSH, Telnet, CIFS, DCE Endpoint Resolution) were discovered in the scan. Both these facts can be joined with the new dim_aggregated_credential_status which provides the above statuses in a human readable form. For examples of queries please refer to the following document: SQL Query Export Example: Credential status

Pentesting in the Real World: Group Policy Pwnage

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…

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.

Pentesting in the Real World: Capturing Credentials on an Internal Network

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…

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.

Passwords and the Devolution of Computer Users

This is a guest post from our frequent contributor Kevin Beaver. You can read all of his previous guest posts here. Recently, I wrote about my thoughts on why we feel like we have to force short-term password changes in the name of “security.” Since…

This is a guest post from our frequent contributor Kevin Beaver. You can read all of his previous guest posts here. Recently, I wrote about my thoughts on why we feel like we have to force short-term password changes in the name of “security.” Since that time, Microsoft made an announcement to step in and help set its users (and itself) up for success with more stringent password requirements for Microsoft Account and Azure Active Directory. Sad it has come to this – a vendor doing what they must do to force people to use stronger passwords. We're devolving as computer users. Shown in study after study, i.e. Ponemon, Verizon, and (especially) this insightful research from Rapid7: the basics are ignored, we cry out for newer and better security controls, government regulations grow – and, yet, nothing gets better. Apparently the information security basics such as weak passwords are just too much to ask for. Take for instance, the work Security, Accuracy, and Privacy in Computer Systems – a great book written by the late James Martin. It covers all sorts of security basics – what's needed and how to balance it all out. That book was written in 1973. We still can't get security right. Not even passwords. So, what is the answer? Is it IT's fault? IT and security teams, and the executives heading things up are certainly complicit. Some ignore password vulnerabilities. Some have trouble getting their messages across. Others are afraid to say anything, especially given the predictable pushback from management. Users are on the hook as well. As much as we try to set them up for success through technical controls and awareness/training, at some point, they need to be held accountable. They're grown-ups and it's not like this whole computer password thing is something new. Maybe we should continue down the path of making things more complex through regulations, lawyers, and technical controls that promise to make everything better. Ha! Not unlike attempts at failed social initiatives involving emotional responses to crises rather than due process, I suspect we'll continue down the path of more laws, more policies, more audits, and a growing false sense of security. Our current approach to passwords is not working. Maybe that's okay – perhaps someone else can figure it out down the road. Mark Matteson was quoted as saying “Good habits are hard to form and easy to live with. Bad habits are easy to form and hard to live with. Pay attention. Be aware. If we don't consciously form good ones, we will unconsciously form bad ones.” With weak passwords – more than any other computer security vulnerability - what I believe we need is need is discipline. Discipline on the part of IT and security teams. Discipline on the part of users. Discipline on the part of management. That and some backbone to see things through over time (again, especially with passwords) until the challenges are resolved. Unless and until something changes in this area, I suspect we'll continue down this path of ignorant bliss and continued breaches.

Weekly Metasploit Wrapup

Steal all the passwords I talk a lot about Authenticated Code Execution, but of course that's not the only thing that authenticated access can get you. This week's update comes with a couple of modules for using known credentials to extract more credentials. The first…

Steal all the passwords I talk a lot about Authenticated Code Execution, but of course that's not the only thing that authenticated access can get you. This week's update comes with a couple of modules for using known credentials to extract more credentials. The first is for Symantec Brightmail, an email filtering gateway that comes with a management interface for administrators. Any account with read access is allowed to look at the encrypted LDAP credentials stored in Brightmail. Fortunately for us, the encryption is reversible and the system also kindly uses a known key. The second module is for Canon multi-function printers, because of course your printer needs to store a bunch of plaintext passwords; I mean, why wouldn't it? This one also requires authentication, but it's a printer, so of course there's a default that no one ever changes. Payload options in jobs output To see the stuff running in the background, msfconsole has a jobs command. There are some pertinent pieces of info you usually want to see in that display, but a console interface makes it kinda tough to view it all because of the limited column width. A recent feature, the ability to control the URI a reverse_http payload calls back to with the LURI option, puts extra pressure on that limited space. To make that a little easier, payload options are now all condensed into a single column, so instead of seperate LPORT, LHOST, and LURI columns, you just have "Payload opts": msf exploit(ie_cbutton_uaf) > jobs Jobs ==== Id Name Payload Payload opts -- ---- ------- ------------ 0 Exploit: windows/browser/adobe_flash_pcre windows/meterpreter/reverse_http http://10.6.0.65:8080/index.php 1 Exploit: windows/browser/ie_cbutton_uaf windows/meterpreter/reverse_tcp tcp://10.6.0.65:8181 msf exploit(ie_cbutton_uaf) > jobs -v Jobs ==== Id Name Payload Payload opts URIPATH Start Time Handler opts -- ---- ------- ------------ ------- ---------- ------------ 0 Exploit: windows/browser/adobe_flash_pcre windows/meterpreter/reverse_http http://10.6.0.65:8080/index.php /flash 2016-06-16 13:50:31 -0500 http://0.0.0.0:8080/index.php 1 Exploit: windows/browser/ie_cbutton_uaf windows/meterpreter/reverse_tcp tcp://10.6.0.65:8181 /cbutton 2016-06-16 13:51:00 -0500 ```  ## <span>Gifts that keep on giving</span> Shellshock is one of my favorite bugs of all time. It's simple to exploit, results in RCE, and is in a thing that everyone takes for granted. The latest incarnaiton of it is in IPFire, an open source Linux firewall, but I'm sure we'll see it again. ## New Modules _Exploit modules_ _(6 new)_ * [IPFire Bash Environment Variable Injection (Shellshock)](https://www.rapid7.com/db/modules/exploit/linux/http/ipfire_bashbug_exec) by Claudio Viviani, and h00die exploits CVE-2014-6271 * [IPFire proxy.cgi RCE](https://www.rapid7.com/db/modules/exploit/linux/http/ipfire_proxy_exec) by Yann CAM, and h00die * [Magento 2.0.6 Unserialize Remote Code Execution](https://www.rapid7.com/db/modules/exploit/multi/http/magento_unserialize) by Netanel Rubin, agix, and mr_me exploits CVE-2016-4010 * [Apache Struts REST Plugin With Dynamic Method Invocation Remote Code Execution](https://www.rapid7.com/db/modules/exploit/multi/http/struts_dmi_rest_exec) by Nixawk exploits CVE-2016-3087 * [HP Data Protector Encrypted Communication Remote Command Execution](https://www.rapid7.com/db/modules/exploit/windows/misc/hp_dataprotector_encrypted_comms) by Ian Lovering, and Jon Barg exploits CVE-2016-2004 * [Poison Ivy 2.1.x C2 Buffer Overflow](https://www.rapid7.com/db/modules/exploit/windows/misc/poisonivy_21x_bof) by Jos Wetzels _Auxiliary and post modules_ _(4 new)_ * [PhoenixContact PLC Remote START/STOP Command](https://www.rapid7.com/db/modules/auxiliary/admin/scada/phoenix_command) by Tijl Deneut exploits CVE-2014-9195 * [Symantec Messaging Gateway 10 Exposure of Stored AD Password Vulnerability](https://www.rapid7.com/db/modules/auxiliary/scanner/http/symantec_brightmail_ldapcreds) by Fakhir Karim Reda exploits CVE-2016-2203 * [Jenkins Server Broadcast Enumeration](https://www.rapid7.com/db/modules/auxiliary/scanner/jenkins/jenkins_udp_broadcast_enum) by Adam Compton, and Matt Schmidt * [Canon IR-Adv Password Extractor](https://www.rapid7.com/db/modules/auxiliary/scanner/printer/canon_iradv_pwd_extract) by Deral "Percentx" Heiland, Dev Mohanty, Pete "Bokojan" Arzamendi, and William Vu ## Get it As always, you can update to the latest Metasploit Framework with a simple `msfupdate` and the full diff since the last blog post is available on GitHub: [4.12.5...4.12.7](https://github.com/rapid7/metasploit-framework/compare/4.12.5...4.12.7) To install fresh, check out the open-source-only [Nightly Installers](https://github.com/rapid7/metasploit-framework/wiki/Nightly-Installers), or the [binary installers](https://www.rapid7.com/products/metasploit/download.jsp) which also include the commercial editions.

If Employee Passwords Get Compromised, Does Your System Make a Sound?

Compromised credentials are the number one attack vector behind breaches, according to the Verizon Data Breach Investigations Report. Armed with an employee username and password, attackers can stealthily gain a foothold on the network, perform reconnaissance, and move laterally to critical targets – all without…

Compromised credentials are the number one attack vector behind breaches, according to the Verizon Data Breach Investigations Report. Armed with an employee username and password, attackers can stealthily gain a foothold on the network, perform reconnaissance, and move laterally to critical targets – all without malware. Phishing and malware are great ways to steal credentials, but there's another much easier way that's largely outside of one's control – third party breaches.The way it works is simple. A company employee uses their work email (e.g. eric_moon@rapid7.com) to sign up for an account, whether it be Adobe or Ashley Madison. That site gets compromised, which can lead to damage ranging from the exposure of real names and passwords to credit card numbers, Social Security numbers, and other personally identifiable information leaked into the public domain. Over the past year alone, millions have had their credentials spilled onto the web from breaches and the subsequent data dumps.Related Resource: Learn to Identify Compromised Users in Your Organization with our ToolkitThe complication is that we often reuse passwords... and they aren't very strong. According to a 2007 Microsoft study, the average web user maintains 25 separate accounts but uses just 6.5 passwords to protect them. Since 2007, we (1) use even more services, (2) create accounts on mobile devices, and (3) haven't made significant strides in password hygiene.Since work emails are easily identifiable as associated with a company, it's not a stretch for attackers to attempt authentication on Outlook Web Access, Cloud Services like Google Apps, Box, Office 365, or elsewhere. If authentication is successful, this results in data loss that is difficult to detect. From there, attackers can dig for VPN credentials, use the compromised account to phish other employees, and laterally move towards prized assets such as credit card databases, Protected Health Information (PHI), or confidential financials or schematics. Image by Troy Hunt, Microsoft MVP for Developer SecurityHow can you check if you or your friend's data has been exposed? Sites like HaveIBeenPwned offer searches where email addresses can be entered to check against their database. User Behavior Analytics (UBA) technology can also baseline normal account authentications and identify suspicious logins for further investigation. With InsightIDR, we alert you of accounts associated with third party breaches and also identify compromised credentials across all of your employees, including their network services, endpoints, and cloud services.InsightIDR helps detect account takeovers through user behavior analytics, automatically provides a visual dossier of your users and assets, and highlights risky behavior from your employees. By integrating with your existing network and security stack, the millions of events generated daily on your network are correlated to the users behind them. This is combined with Rapid7's knowledge of the attacker from the Metasploit project, Incident Response teams, and Pen Testers to help you catch intruders earlier in the attack chain, before data theft occurs.During an evaluation of InsightIDR, a large private university was immediately alerted of three incidents that involved multiple compromised user accounts. In one case, there were authentications coming from the EMEA region. Drilling in further, the ISO saw that the user account in question was trying to connect via VPN from an IP address in Lagos, Nigeria. Although university faculty often travels, the user behavior analytics within InsightIDR automatically identified the authentications as unusual.After confirming that the account owner was not traveling, the Active Directory account and password were reset, and the user was placed on the InsightIDR Watchlist to more closely monitor subsequent activity. 15 minutes later, ingress activity came from the same IP address for a different user account. That user was also confirmed not-traveling, and was also reset & Watchlisted. Both end users were questioned about whether they had fallen victim to phishing campaigns, but neither recalled any suspicious events. This has also proved useful for government agencies and biotech companies – being able to identify and mitigate credential risk transcends verticals and is essential in today's threat landscape.If you'd like to learn more about how attackers use credentials to gain unauthorized access, check out our Rapid7 research report, The Attacker's Dictionary - Auditing Criminal Credential Attacks. For more about our complete incident detection and investigation solution, check out our on-demand 20-minute InsightIDR demo today!

Featured Research

National Exposure Index 2017

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Learn More

Upcoming Event

UNITED 2017

Rapid7's annual security summit is taking place September 12-14, 2017 in Boston, MA. Join industry peers for candid talks, focused trainings, and roundtable discussions that accelerate innovation, reduce risk, and advance your business.

Register Now

Podcast

Security Nation

Security Nation is a podcast dedicated to covering all things infosec – from what's making headlines to practical tips for organizations looking to improve their own security programs. Host Kyle Flaherty has been knee–deep in the security sector for nearly two decades. At Rapid7 he leads a solutions-focused team with the mission of helping security professionals do their jobs.

Listen Now