IOActive researchers give you an inside view of the IOActive Labs research facilities and highlight research hacking ATMs, Segways, and skimmers. (more…)
Year: 2017
Physical and Authentication Bypass in Diebold Opteva ATM
Historically, ATMs have been designed without privileged separation between the safe and the internal operating system. In an attempt to address this security concern, Diebold developed the AFD platform. The Opteva line of ATMs with the AFD platform contain an upper cabinet for the operating system and a lower cabinet for the safe, each with its own authentication requirements.
Using reverse engineering and protocol analysis, IOActive found a critical vulnerability in the tested version of the Opteva ATM with the AFD platform. Despite its separation of privilege and authentication requirements, the ATM is still vulnerable to a malicious attacker, compromising its integrity and causing unauthenticated vending from the AFD. (more…)
Multiple Critical Vulnerabilities Found in Popular Motorized Hoverboards
Not that long ago, motorized hoverboards were in the news – according to widespread reports, they had a tendency to catch on fire and even explode. Hoverboards were so dangerous that the National Association of State Fire Marshals (NASFM) issued a statement recommending consumers “look for indications of acceptance by recognized testing organizations” when purchasing the devices. Consumers were even advised to not leave them unattended due to the risk of fires. The Federal Trade Commission has since established requirements that any hoverboard imported to the US meet baseline safety requirements set by Underwriters Laboratories.
Since hoverboards were a popular item used for personal transportation, I acquired a Ninebot by Segway miniPRO hoverboard in September of 2016 for recreational use. The technology is amazing and a lot of fun, making it very easy to learn and become a relatively skilled rider.
The hoverboard is also connected and comes with a rider application that enables the owner to do some cool things, such as change the light colors, remotely control the hoverboard, and see its battery life and remaining mileage. I was naturally a little intrigued and couldn’t help but start doing some tinkering to see how fragile the firmware was. In my past experience as a security consultant, previous well-chronicled issues brought to mind that if vulnerabilities do exist, they might be exploited by an attacker to cause some serious harm.
When I started looking further, I learned that regulations now require hoverboards to meet certain mechanical and electrical specifications with the goal of preventing battery fires and various mechanical failures; however, there are currently no regulations aimed at ensuring firmware integrity and validation, even though firmware is also integral to the safety of the system.
Let’s Break a Hoverboard
Using reverse engineering and protocol analysis techniques, I was able to determine that my Ninebot by Segway miniPRO (Ninebot purchased Segway Inc. in 2015) had several critical vulnerabilities that were wirelessly exploitable. These vulnerabilities could be used by an attacker to bypass safety systems designed by Ninebot, one of the only hoverboards approved for sale in many countries.
Using protocol analysis, I determined I didn’t need to use a rider’s PIN (Personal Identification Number) to establish a connection. Even though the rider could set a PIN, the hoverboard did not actually change its default pin of “000000.” This allowed me to connect over Bluetooth while bypassing the security controls. I could also document the communications between the app and the hoverboard, since they were not encrypted.
Additionally, after attempting to apply a corrupted firmware update, I noticed that the hoverboard did not implement any integrity checks on firmware images before applying them. This means an attacker could apply any arbitrary update to the hoverboard, which would allow them to bypass safety interlocks.
Upon further investigation of the Ninebot application, I also determined that connected riders in the area were indexed using their smart phones’ GPS; therefore, each riders’ location is published and publicly available, making actual weaponization of an exploit much easier for an attacker.
To show how this works, an attacker using the Ninebot application can locate other hoverboard riders in the vicinity:
Using the pin “111111,” the attacker can then launch the Ninebot application and connect to the hoverboard. This would lock a normal user out of the Ninebot mobile application because a new PIN has been set.
Using DNS spoofing, an attacker can upload an arbitrary firmware image by spoofing the domain record for apptest.ninebot.cn. The mobile application downloads the image and then uploads it to the hoverboard:
“CtrlVersionCode”:[“1337″,”50212”]
Create a matching directory and file including the malicious firmware (/appversion/appdownload/NinebotMini/v1.3.3.7/Mini_Driver_v1.3.3.7.zip) with the modified update file Mini_Driver_V1.3.3.7.bin compressed inside of the firmware update archive.
When launched, the Ninebot application checks to see if the firmware version on the hoverboard matches the one downloaded from apptest.ninebot.cn. If there is a later version available (that is, if the version in the JSON object is newer than the version currently installed), the app triggers the firmware update process.
Analysis of Findings
Even though the Ninebot application prompted a user to enter a PIN when launched, it was not checked at the protocol level before allowing the user to connect. This left the Bluetooth interface exposed to an attack at a lower level. Additionally, since this device did not use standard Bluetooth PIN-based security, communications were not encrypted and could be wirelessly intercepted by an attacker.
Exposed management interfaces should not be available on a production device. An attacker may leverage an open management interface to execute privileged actions remotely. Due to the implementation in this scenario, I was able to leverage this vulnerability and perform a firmware update of the hoverboard’s control system without authentication.
Firmware integrity checks are imperative in embedded systems. Unverified or corrupted firmware images could permanently damage systems and may allow an attacker to cause unintended behavior. I was able to modify the controller firmware to remove rider detection, and may have been able to change configuration parameters in other onboard systems, such as the BMS (Battery Management System) and Bluetooth module.
Hoverboard and Android Application
As a result of the research, IOActive made the following security design and development recommendations to Ninebot that would correct these vulnerabilities:
- Implement firmware integrity checking.
- Use Bluetooth Pre-Shared Key authentication or PIN authentication.
- Use strong encryption for wireless communications between the application and hoverboard.
- Implement a “pairing mode” as the sole mode in which the hoverboard pairs over Bluetooth.
- Protect rider privacy by not exposing rider location within the Ninebot mobile application.
IOActive recommends that end users stay up-to-date with the latest versions of the app from Ninebot. We also recommend that consumers avoid hoverboard models with Bluetooth and wireless capabilities.
Responsible Disclosure
After completing the research, IOActive subsequently contacted and disclosed the details of the vulnerabilities identified to Ninebot. Through a series of exchanges since the initial contact, Ninebot has released a new version of the application and reported to IOActive that the critical issues have been addressed.
- December 2016: IOActive conducts testing on Ninebot by Segway miniPro hoverboard.
- December 24, 2016: Ioactive contacts Ninebot via a public email address to establish a line of communication.
- January 4, 2017: Ninebot responds to IOActive.
- January 27, 2017: IOActive discloses issues to Ninebot.
- April 2017: Ninebot releases an updated application (3.20), which includes fixes that address some of IOActive’s findings.
- April 17, 2017: Ninebot informs IOActive that remediation of critical issues is complete.
- July 19, 2017: IOActive publishes findings.
Ninebot by Segway miniPRO Vulnerabilities
Ninebot Limited, which purchased Segway Inc. in 2015, sells a line of self-balancing motorized electric scooters used for transportation under 30km/h. Recently, issues regarding the safety of scooters have surfaced, primarily caused by poor manufacturing quality or a general lack of safety-centered design. (more…)
Go Nuclear: Breaking Radiation Monitoring Devices
Radioactivity is a part of our environment; we are continuously exposed to natural radiation arising from the Earth and even from outer space. We are also exposed to artificial sources of radiation, derived from human activities. Ionizing isotopes are used across multiple sectors: agriculture, medicine, research, biochemistry, and manufacturing.
The need for sophisticated devices to measure and detect the presence of radiation seems clear. Critical infrastructure, such as nuclear power plants, seaports, borders, and even hospitals, are equipped with radiation-monitoring devices. This equipment detects and prevents threats ranging from smuggling nuclear material to radiation contamination.
The purpose of this research is to provide a comprehensive description of the technical details and approach IOActive used to discover vulnerabilities affecting widely deployed radiation monitoring devices. Our work involved software and firmware reverse engineering, RF analysis, and hardware hacking. (more…)
24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them
Fully updated to cover the latest security issues, 24 Deadly Sins of Software Security reveals the most common design and coding errors and explains how to fix each one-or better yet, avoid them from the start. Michael Howard and David LeBlanc, who teach Microsoft employees and the world how to secure code, have partnered again with John Viega, who uncovered the original 19 deadly programming sins. They have completely revised the book to address the most recent vulnerabilities and have added five brand new sins. This practical guide covers all platforms, languages, and types of applications. (more…)
WannaCry vs. Petya: Keys to Ransomware Effectiveness
With WannaCry and now Petya we’re beginning to see how and why the new strain of ransomware worms are evolving and growing far more effective than previous versions.
I think there are 3 main factors: Propagation, Payload, and Payment.*
- Propagation: You ideally want to be able to spread using as many different types of techniques as you can.
- Payload: Once you’ve infected the system you want to have a payload that encrypts properly, doesn’t have any easy bypass to decryption, and clearly indicates to the victim what they should do next.
- Payment: You need to be able to take in money efficiently and then actually decrypt the systems of those who pay. This piece is crucial, otherwise people will quickly learn they can’t get their files back even if they do pay and be inclined to just start over.
WannaCry vs. Petya
WannaCry used SMB as its main spreading mechanism, and its payment infrastructure lacked the ability to scale. It also had a kill switch, which was famously triggered and halted further propagation.
Petya on the other hand appears to be much more effective at spreading since it’s using both EternalBlue and credential sharing
/ PSEXEC to infect more systems. This means it can harvest working credentials and spread even if the new targets aren’t vulnerable to an exploit.
[NOTE: This is early analysis so some details could turn out to be different as we learn more.]
What remains to be seen is how effective the payload and payment infrastructures are on this one. It’s one thing to encrypt files, but it’s something else entirely to decrypt them.
The other important unknown at this point is if Petya is standalone or a component of a more elaborate attack. Is what we’re seeing now intended to be a compelling distraction?
There’s been some reports indicating these exploits were utilized by a sophisticated threat actor against the same targets prior to WannaCry. So it’s possible that WannaCry was poorly designed on purpose. Either way, we’re advising clients to investigate if there is any evidence of a more strategic use of these tools in the weeks leading up to Petya hitting.
*Note: I’m sure there are many more thorough ways to analyze the efficacy of worms. These are just three that came to mind while reading about Petya and thinking about it compared to WannaCry.
APIs are 2FA Backdoors
It’s time we accept as an industry that API keys and secrets are essentially usernames and passwords, except they’re designed to be used in an automated way to perform your company’s most sensitive functions, often instrumented by developers who don’t prioritize security.
They’ll probably respond, “Of course.”
Now ask them what you can do with that API.
“Oh, it’s a great API. You can do pretty much everything.”
“Great. How many people have access?”
“It’s super popular. We give access to all our developers, and any account can ask for and receive a key.”
“Cool. So how many of those keys are out there, and how do you control them?”
“…”
Exactly.
API keys often have full access to the platform, and guess what the access method is: a string of characters for your key, and a string of characters for your secret.
Sound familiar? How is this different from a username and password?
“Oh, but this is different because it’s all code-ey and stuff. Lots of programming and hard things.”
No.
That’s not a defense. Good APIs also share something else: great documentation.
It’s easy to do things like adding users, adjusting permissions, or pulling data using this interface because it’s meant to be easy. In fact, the easier it is to do something powerful, the better.
And this is all happening on 2FA-enabled accounts, despite that supposed higher level of security.
Summary
- Everyone understands that 2FA is better than just a username and password.
- Everyone is also trying to add an API to their new services.
- API keys are just usernames and passwords used in code.
- Few people realize this, and think it’s safe because “programming is hard” or because “APIs are magic.”
- APIs are not magic. They’re an entry point into your application, and there are far too many keys and secrets floating around Slack, Github, and many other places on services that are 2FA-enabled.
- This presents a false sense of security.
2FA is great. Enable it where you can. But it’s not the end of the conversation. Be sure to look at your API as well. Know what you can do with it, know who has keys, know how often they expire, and have a plan for monitoring and response.
For all intents and purposes, you should treat API access like legacy username and password access. After all, API keys and secrets are credentials.
Credentials can be stolen, and credentials can be used to do bad things.
This post is adapted from Daniel Miessler’s original blog post, which you can find at https://danielmiessler.com/blog/apis-2fas-achilles-heel/.
Post #WannaCry Reaction #127: Do I Need a Pen Test?
In the wake of WannaCry and other recent events, everyone from the Department of Homeland Security to my grandmother is recommending penetration tests as a silver bullet to prevent falling victim to the next cyberattack. But a penetration test is not a silver bullet, nor is it universally what is needed for improving the security posture of an organization. There are several key factors to consider. So I thought it might be good to review the difference between a penetration test and a vulnerability assessment since this is a routine source of confusion in the market. In fact, I’d venture to say that while there is a lot of good that comes from a penetration test, what people actually more often need is a vulnerability assessment.
First, let’s get the vocabulary down:
Vulnerability Assessments
Vulnerability Assessments are designed to yield a prioritized list of vulnerabilities and are generally best for organizations that understand they are not where they want to be in terms of security. The customer already knows they have issues and need help identifying and prioritizing them.
With a vulnerability assessment, the more issues identified the better, so naturally, a white box approach should be embraced when possible. The most important deliverable of the assessment is a prioritized list of vulnerabilities identified (and often information on how best to remediate).
Penetration Tests
Penetration Tests are designed to achieve a specific, attacker-simulated goal and should be requested by organizations that are already at their desired security posture. A typical goal could be to access the contents of the prized customer database on the internal network or to modify a record in an HR system.
The deliverable for a penetration test is a report on how security was breached in order to reach the agreed-upon goal (and often information on how best to remediate).
No organization has an unlimited budget for security. Every security dollar spent is a trade-off. For organizations that do not have a highly developed security program in place, vulnerability assessments will provide better value in terms of knowing where you need to improve your security posture even though pen tests are generally a less expensive option. A pen test is great when you know what you are looking for or want to test whether a remediation is working and has solved a particular vulnerability.
Here is a quick chart to help determine what your organization may need.
VULNERABILITY ASSESSMENT
|
PENETRATION TEST
|
|
Organizational Security Program Maturity Level
|
Low to Medium. Usually requested by organizations that already know they have issues, and need help getting started.
|
High. The organization believes their defenses to be strong, and wants to test that assertion.
|
Goal
|
Attain a prioritized list of vulnerabilities in the environment so that remediation can occur.
|
Determine whether a mature security posture can withstand an intrusion attempt from an advanced attacker with a specific goal.
|
Focus
|
Breadth over depth.
|
Depth overbreadth.
|
So what now?
Most security programs benefit from utilizing some combination of security techniques. These can include any number of tasks, including penetration tests, vulnerability assessments, bug bounties, white/grey/black testing, code review, and/or red/blue/purple team exercises.
We’ll peel back the different tools and how you might use them in a future post. Until then, take a look at your needs and make sure the steps you take in the wake of WannaCry and other security incidents are more than just reacting to the crisis of the week.
#WannaCry: Examining Weaponized Malware
Attribution: You Keep Using That Word, I Do Not Think It Means What You Think It Means…
In internal discussions in virtual halls of IOActive this morning, there were many talks about the collective industry’s rush to blame or attribution over the recent WanaCry/WannaCrypt ransomware breakouts. Twitter was lit up on #Wannacry and #WannaCrypt and even Microsoft got into the action, stating, “We need governments to consider the damage to civilians that comes from hoarding these vulnerabilities and the use of these exploits.”
Opinions for blame and attribution spanned the entire spectrum of response, from the relatively sane…
As a community, we can talk and debate who did what, and why, but in the end it really doesn’t matter. Literally, none (well, almost none) of us outside the government or intelligence communities have any impact on the discussion of attribution. Even for the government, attribution is hard to nearly impossible to do reliably, and worse – is now politicized and drawn out in the court of public opinion. The digital ink on malware or Internet attacks is hardly even dry, yet experts are already calling out “Colonel Mustard, Lead Pipe, Study” before we even know what the malware is fully capable of doing. We insist on having these hyperbolic discussions where we wax poetic about the virtues of the NSA vs. Microsoft vs. state actors.
It’s more important to focus on the facts and what can be observed in the behavioral characteristics of the malware and what organizations need to do to prevent infection now and in the future.
How people classify them varies, but there are essentially three different classes of weaponized malware:
- Semi-automatic/automatic kits that exploit “all the things.”These are the Confickers, Code-red, SQL Slamming Melissa’s of the world
- Manual/point targeted kits that exploit “one thing at a time.” These are the types of kit that Shadow Brokers dropped. Think of these as black market, crew-served weapons, such as MANPADS
- Automatic point target exploit kits that exploit based on specific target telemetry AND are remotely controllable in flight. This includes Stuxnet. Think of these as the modern cyber equivalent of cruise missiles
Nation state toolkits are typically elegant. As we know, ETERNALBLUE was part of a greater framework/toolkit. Whoever made WannaCrypt/Cry deconstructed a well written (by all accounts thus far) complex mechanism for point target use, and made a blunt force weapon of part of it. Of those three types above, nation states moved on from the first one over a decade ago because they’re not controllable and they don’t meet the clandestine nature that today’s operators require. Nation states typically prefer type two; however, this requires bi-directional, fully routed IP connectivity to function correctly. When you cannot get to the network or asset in question, type three is your only option. In that instance, you build in the targeting telemetry for the mission and send it on its way. This requires a massive amount of upfront HUMINT and SIGINT for targeting telemetry. As you can imagine, the weaponized malware in type three is both massive in size and in sunk cost.
WannaCry/WanaCrypt is certainly NOT types two or three and it appears that corners were cut in creating the malware. The community was very quick in actively reversing the package and it doesn’t appear that any major anti-reversing or anti-tampering methods were used. Toss in the well-publicized and rudimentary “kill switch” component and this appears almost sloppy and lacks conviction. I can think of at least a dozen more elegant command and control functions it could have implemented to leave control in the hands of the malware author. Anyone with reverse engineering skills would eventually find this “kill switch” and disable it using a hex editor to modifying a JMP instruction. Compare this to Conficker, which had password brute-forcing capabilities as well as the ability to pivot after installation and infect other hosts without the use of exploits, but rather through simple login after passwords were identified.
This doesn’t mean that WannaCry/WanaCrypt is not dangerous, on the contrary depending upon the data impacted, its consequences could be devastating. For example, impacting the safety builder controlling Safety Instrumented Systems, locking operators out of the Human Machine Interfaces (HMI’s, or computers used in industrial control environments) could lead to dangerous process failures. Likewise, loss of regulatory data that exists in environmental control systems, quality systems, historians, or other critical ICS assets could open a facility up to regulatory action. Critical infrastructure asset owners typically have horrific patch cycles with equally appalling backup and disaster recovery strategies. And if businesses are hit with this attack and lose critical data, it may open up a door to legal action for failure to follow due care and diligence to protect these systems. It’s clear this ransomware is going to be a major pain for quite some time. Due care and preventative strategies should be taken by asset owners everywhere to keep their operations up and running in the safest and secure manner possible.
It really doesn’t do much good to philosophically discuss attribution, or play as a recent hashtag calls it, the #smbBlameGame. It’s relatively clear that this is amateur hour in the cybercrime space. With a lot of people panicking about this being the “next cyber cruise missile” or equivalent, I submit that this is more akin to digital malaria.