If you’re an InsightIDR customer, you know that credentials are a huge reason why attackers gain access to unauthorized data. We’re proud to announce that with the Insight Platform, we’re improving your authentication experience across all Rapid7 solutions, giving you tighter role-based access and yes—multi-factor authentication. Also, you now have the option to archive the data stored in InsightIDR in your own Amazon Web Services S3 bucket.

What is the Insight Platform?
We have a simple vision—give you answers to your IT & security questions, fast. Whether it’s detecting malicious behavior with InsightIDR, answering IT Operations questions easily with InsightOps, or finding and testing vulns with InsightVM and InsightAppSec, we want to slot into your workflows and slash out the tasks that clog up your days.

For example, setting up and maintaining data connectors across multiple tools is a big pain. With the Insight platform, you’ll have a single sign-on experience across our portfolio. Once you’ve connected data sources the first time, such as by deploying the Insight Agent, we’ll intelligently analyze that data under multiple lenses, whether it's for vulnerability management or for detection & response.

Sounds good. How does this affect my InsightIDR experience?
Existing InsightIDR customers are currently being migrated in groups onto the new platform identity management. You’ll be notified via the email associated with your login (e.g. eric_moon@rapid7.com), so please stay tuned for further instructions.

Multi Factor Authentication in InsightIDR
You can now mandate InsightIDR logins to require a second layer of authentication in the form of Google Authenticator, Okta Verify, SMS Text, or security question.

From the Settings tab, head to MFA Settings:

Choose the options you want to roll out for users, and set a session time limit—the length of time before it requests multi-factor for the next authentication. Once you apply these settings, all future users will be prompted to setup multi-factor during their next login, as shown below.

Archive InsightIDR Data in Your Own S3 Bucket
With your standard InsightIDR subscription, your data is stored and fully searchable for thirteen months. However, if you want to store an additional copy of your data in your own AWS Simple Storage Service (S3), that’s only a few clicks away.

Also in Settings, there is a new option, “S3 Archiving”:

Note that the archiving process occurs once a day, and only sends new data that comes in once the archiving is enabled. Based on your use case, from your S3 bucket, you can configure data to be sent to AWS Glacier storage for additional cost savings.

That’s it! If you’re having any challenges, please reach out to your Customer Success Manager or ping support@rapid7.com. We’re excited not only to offer you a robust authentication and data archiving experience, but to make it easier to switch between our solutions, try new security use cases, and provide you with answers—fast.

Today we are announcing four issues affecting two popular home automation solutions: Wink's Hub 2 and Insteon's Hub. Neither vendor stored sensitive credentials securely on their associated Android apps. In addition, the Wink cloud-based management API does not properly expire and revoke authentication tokens, and the Insteon Hub uses an

Today we are announcing four issues affecting two popular home automation solutions: Wink's Hub 2 and Insteon's Hub. Neither vendor stored sensitive credentials securely on their associated Android apps. In addition, the Wink cloud-based management API does not properly expire and revoke authentication tokens, and the Insteon Hub uses an unencrypted radio transmission protocol for potentially sensitive security controls such as garage door locks.

As most of these issues have not yet been addressed by the vendors, users should ensure mobile devices enable full disk encryption if possible, and avoid the use of these products for sensitive applications until the vulnerabilities are patched. While the potential impact is high, these vulnerabilities are not exploitable over the internet: access to the user's phone, or close proximity to connected devices in the replay case, is required for exploitation. This post provides additional details on the vulnerabilities and steps users can take to protect themselves.

R7-2017-19.2, CWE 613 (Insufficient Session Expiration): when users log out of the Wink Android application, the authentication token used for that session is not revoked, nor does the generation of new tokens revoke older ones. There is no way currently for users to see all valid authentication tokens connected to their account, but there is a method available to revoke all authentications aside from their current one (detailed below). No CVE was assigned to this issue, as remediation would likely be done on Wink's servers.

Product Description

Wink Hub 2 is a smart home system designed to help consumers manage multiple home IoT products and protocols from various vendors. It is composed of a hub device as well as a mobile application for user interaction. More information can be found on the vendor's product page.

Credit

These issues were discovered by Deral Heiland, Research Lead at Rapid7, Inc. This advisory was prepared in accordance with Rapid7's disclosure policy.

R7-2017-19.1

Details and Exploitation

During analysis of the Android mobile application for Wink (Wink application version 6.1.0.19 on Android 5.1 running kernel 3.10.72), it was discovered that the OAuth token is stored unencrypted within the following file: /data/data/com.quirky.android.wink.wink/shared_prefs/user.xml

To determine the longevity of this preference file, the Android device was rebooted, after which the unencrypted OAuth token shown in Figure 1 below was still present. It was determined that the token remained until the user logged off manually. Based on the nature of IoT technology, users typically stay logged in, however. Thus the authentication tokens are likely to stay valid indefinitely, unless the user doesn't interact with the application for more than 30 days.

Remediation

A vendor-supplied patch for the mobile app should be provided to prevent storing potentially sensitive information, such as authentication tokens, in cleartext. While local storage is likely necessary for normal functionality, sensitive information should be stored in an encrypted format that requires authentication to decrypt. In the case of Android, there is a built-in secure storage method that should be used.

[Updated Sept 22, 2017]The latest version of the Wink Android application, v6.3.0.28, fixed the authentication storage issue. This was released on Sep 13, 2017. Users should update to this version immediately.

Users should also consider enabling full-disk encryption (FDE), and be sure to log out of the Wink application when not in use. Enabling FDE will protect the authentication tokens on the device from being accessed. iPhones enable FDE by default, and most modern Android devices are capable of enabling it. FDE also adds an additional layer of protection by adding a boot password. If FDE is not possible for a particular device, the user should be especially careful not to lose the device, as sensitive data may be recoverable.

R7-2017-19.2

Details and Exploitation

Further examination of the Wink app's use of OAuth revealed that the normal user logout process does not include OAuth token revocation. When the user logs out from the mobile application, it only sends a delete request for the mobile device tracker in specific (as shown in Figure 2 below). This tracker plays no direct roll in the authentication process.

When the user logs back in, they are assigned a new OAuth token. However, testing showed that the previous OAuth token still remained valid. To further validate the security of this, the user's password was changed, at which point revocation of that user's tokens was expected. The system rebooted, but the original OAuth token still remained valid, as shown in Figure 3:

This means that if a user loses their mobile device, or if it is stolen, a malicious actor could extract the unencrypted OAuth token from the user.xml file, giving the malicious actor full access to the Wink Hub 2 remotely.

Remediation

A vendor-supplied patch should be provided to revoke the user's OAuth token after logout from the mobile application. In addition, a mechanism should be added to allow for the revocation of all tokens across all mobile devices with access to the user's Wink Hub 2. This would help prevent unauthorized access to the device and services even if a device is lost or compromised.

[Updated Sept 22, 2017]
Wink reports that they plan to address this issue in the near future through a server-side change.

[Updated Sept 26, 2017]Users are currently able to force a log out of other user sessions. This can only be done by going to change your password, and then selecting the "Log Out Others" option presented in figure 4:

This step will invalidate all associated OAuth tokens, except for the one currently in use by the user. This lowers exposure greatly, as it is much less likely for an attacker to have that current token, rather than an older one.

We recommend users change their password and log out other sessions associated with their account to avoid exposure. If users are able to view sessions associated with their account in the future, they should review that regularly.

CVE-2017-5251, R7-2017-20.2, CWE 294 (Authentication Bypass by Capture-replay): the radio transmissions used for communication between the Hub and connected devices are not encrypted, and do not provide sufficient protections to guard against capture-replay attacks.

These issues can be used to compromise and control an Insteon Hub environment.

Product Description

The Insteon Hub is a smart home system designed to help consumers connect various home IoT products and manage home automation. It is composed of a hub device as well as a mobile application for user interaction. More information can be found on the vendor's product page.

Credit

These issues were discovered by Deral Heiland, Research Lead at Rapid7, Inc. This advisory was prepared in accordance with Rapid7's disclosure policy.

R7-2017-20.1

Details and Exploitation

Analysis of the Android mobile application for Insteon Hub (Insteon application version 1.9.7) revealed that the account and password for both Insteon services and the Hub hardware was stored unencrypted within the following file: /data/data/com.insteon.insteon3/shared_prefs/com.insteon.insteon3_preferences.xml

To determine the longevity of this file, the Android device was rebooted, after which the plaintext username and password shown in Figures 1 and 2 below was still present. It was determined that the account credentials remained in the file until the user logged off manually. Based on the nature of IoT technology, users typically stay logged in.

Remediation

A vendor-supplied patch should be made to the mobile app to prevent storing sensitive information, such as user credentials, unencrypted. While local storage is likely necessary for normal functionality, sensitive information should be stored in an encrypted format that requires authentication to decrypt. In the case of Android, there is a built-in secure storage method that should be used.

Absent a vendor-supplied patch, users should consider full-disk encryption (FDE), and be sure to log out of the Insteon Hub application when not in use. Enabling FDE will protect the authentication tokens on the device from being accessed. iPhones enable FDE by default, and most modern Android devices are capable of enabling it. FDE also adds an additional layer of protection by adding a boot password. If FDE is not possible for a particular device, the user should be especially careful not to lose the device, as sensitive data may be recoverable.

R7-2017-20.2

Details and Exploitation

The Insteon Hub uses radio signals to communicate with connected devices, specifically a 915MHz Frequency Shift Keying (FSK) communication protocol. Analysis of this protocol revealed that the transmissions do not appear to be encrypted, nor to contain any security mechanisms to prevent replay attacks. A malicious actor can easily capture and replay the radio signals at any time to manipulate any device being managed via this communication protocol.

To test the Insteon Hub's security against replay attacks, an Insteon Garage Door Control Kit (Device 43) was configured via an Insteon Hub (2245-222). Using software-defined radio (SDR), the 915MHz radio signal used to open and close the door via the Garage Door Control device was captured. Once captured, the signal was filtered to remove background noise and then replayed to successfully actuate the Insteon Garage Door Control device. This confirmed that the Insteon RF protocol is vulnerable to replay attacks, and is shown in Figure 3 below:

Remediation

A vendor-supplied patch should be provided to configure the 915MHz signal to encrypt the data being communicated, or to apply a rotating certificate to prevent replay of captured RF signals.

Absent a vendor-supplied patch, users should avoid using the Insteon's radio-control features with security-related and access control devices if they are concerned about potential radio eavesdroppers.

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

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.

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

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

]]>

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

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.

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

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

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 directorytraversalbugs 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.

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.

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 Everything

Probably 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 Matter

When 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 Touch

Finally, 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.

]]>

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

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.

]]>

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

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!

]]>

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,

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.

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.

Hashed passwords are good, but there are severaltools 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.

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?

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.

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.

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.

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.

]]>

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

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.

InsightIDR 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.

In 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.

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 Assets

Many 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 Integration

If you have InsightIDR & Nexpose, setting up the Event Source is easy.

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 demohere.

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

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.

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.

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

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:

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 atwww.

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 atwww.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.

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).

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 atwww.

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 atwww.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.

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.

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.