Tag: cesar cerrudo

RESEARCH | March 1, 2017

Hacking Robots Before Skynet

By Cesar Cerrudo & Lucas Apa
Robots are going mainstream in both private and public sectors – on military missions, performing surgery, building skyscrapers, assisting customers at stores, as healthcare attendants, as business assistants, and interacting closely with our families in a myriad of ways. Robots are already showing up in many of these roles today, and in the coming years they will become an ever more prominent part of our home and business lives. But similar to other new technologies, recent IOActive research has found robotic technologies to be highly insecure in a variety of ways that could pose serious threats to the people and organizations they operate in and around.
 
This blog post is intended to provide a brief overview of the full paper we’ve published based on this research, in which we discovered critical cybersecurity issues in several robots from multiple vendors. The goal is to make robots more secure and prevent vulnerabilities from being used maliciously by attackers to cause serious harm to businesses, consumers, and their surroundings. The paper contains more information about the research, findings, and cites many sources used in compiling the information presented in the paper and this post.
 
Robot Adoption and Cybersecurity
Robots are already showing up in thousands of homes and businesses. As many of these “smart” machines are self-propelled, it is important that they’re secure, well protected, and not easy to hack. If not, instead of helpful resources they could quickly become dangerous tools capable of wreaking havoc and causing substantive harm to their surroundings and the humans they’re designed to serve.
 
We’re already experiencing some of the consequences of substantial cybersecurity problems with Internet of Things (IoT) devices that are impacting the Internet, companies and commerce, and individual consumers alike. Cybersecurity problems in robots could have a much greater impact. When you think of robots as computers with arms, legs, or wheels, they become kinetic IoT devices that, if hacked, can pose new serious threats we have never encountered before.
 
With this in mind, we decided to attempt to hack some of the more popular home, business, and industrial robots currently available on the market. Our goal was to assess the cybersecurity of current robots and determine potential consequences of possible cyberattacks. Our results show how insecure and susceptible current robot technology is to cyberattacks, confirming our initial suspicions.
 
Cybersecurity Problems in Today’s Robots
We used our expertise in hacking computers and embedded devices to build a foundation of practical cyberattacks against robot ecosystems. A robot ecosystem is usually composed of the physical robot, an operating system, firmware, software, mobile/remote control applications, vendor Internet services, cloud services, networks, etc. The full ecosystem presents a huge attack surface with numerous options for cyberattacks.
 
We applied risk assessment and threat modeling tools to robot ecosystems to support our research efforts, allowing us to prioritize the critical and high cybersecurity risks for the robots we tested. We focused on assessing the most accessible components of robot ecosystems, such as mobile applications, operating systems, firmware images, and software. Although we didn’t have all the physical robots, it didn’t impact our research results. We had access to the core components, which provide most of the functionality for the robots; we could say these components “bring them to life.”
 
Our research covered home, business, and industrial robots, as well as the control software used by several other robots. The specific robot vendors evaluated in the research are identified in the published research paper.
 
We found nearly 50 cybersecurity vulnerabilities in the robot ecosystem components, many of which were common problems. While this may seem like a substantial number, it’s important to note that our testing was not even a deep, extensive security audit, as that would have taken a much larger investment of time and resources. The goal for this work was to gain a high level sense of how insecure today’s robots are, which we accomplished. We will continue researching this space and go deeper in future projects.
 
An explanation of each main cybersecurity issue discovered is available in the published research paper, but the following is a high-level (non-technical) list of what we found:
·         Insecure Communications
·         Authentication Issues
·         Missing Authorization
·         Weak Cryptography
·         Privacy Issues
·         Weak Default Configuration
·         Vulnerable Open Source Robot Frameworks and Libraries
 
We observed a broad problem in the robotics community: researchers and enthusiasts use the same – or very similar – tools, software, and design practices worldwide. For example, it is common for robots born as research projects to become commercial products with no additional cybersecurity protections; the security posture of the final product remains the same as the research or prototype robot. This practice results in poor cybersecurity defenses, since research and prototype robots are often designed and built with few or no protections. This lack of cybersecurity in commercial robots was clearly evident in our research.
 
Cyberattacks on Robots

Our research uncovered both critical- and high-risk cybersecurity problems in many robot features. Some of them could be directly abused, and others introduced severe threats. Examples of some of the common robot features identified in the research as possible attack threats are as follows:

  • Microphones and Cameras
  • External Services Interaction
  • Remote Control Applications
  • Modular Extensibility
  • Network Advertisement
  • Connection Ports
A full list with descriptions for each is available in the published paper.
 
New technologies are typically prone to security problems, as vendors prioritize time-to-market over security testing. We have seen vendors struggling with a growing number of cybersecurity issues in multiple industries where products are growing more connected, including notably IoT and automotive in recent years. This is usually the result of not considering cybersecurity at the beginning of the product lifecycle; fixing vulnerabilities becomes more complex and expensive after a product is released.
 
The full paper provides an overview of the many implications of insecure robots as they become more prominent in home, business, industry, healthcare, and other applications. We’ve also included many recommendations in the paper for ways to design and build robotic technology more securely based on our findings.
 
Click here for more information on the research and to view the full paper for additional details and descriptions.   
EDITORIAL | July 29, 2015

Black Hat and DEF CON: Hacks and Fun

By IOActive

The great annual experience of Black Hat and DEF CON starts in just a few days, and we here at IOActive have a lot to share. This year we have several groundbreaking hacking talks and fun activities that you won’t want to miss!

For Fun
Join IOActive for an evening of dancing

Our very own DJ Alan Alvarez is back – coming all the way from Mallorca to turn the House of Blues RED. Because no one prefunks like IOActive.
Wednesday, August 5th
6–9PM
House of Blues
Escape to the IOAsis – DEF CON style!
We invite you to escape the chaos and join us in our luxury suite at Bally’s for some fun and great networking.  
Friday, August 7th12–6PM
Bally’s penthouse suite
·      Unwind with a massage 
·      Enjoy spectacular food and drinks 
·      Participate in discussions on the hottest topics in security 
·      Challenge us to a game of pool! 
FREAKFEST 2015
After a two year hiatus, we’re bringing back the party and taking it up a few notches. Join DJs Stealth Duck, Alan Alvarez, and Keith Myers as they get our booties shaking. All are welcome! This is a chance for the entire community to come together to dance, swim, laugh, relax, and generally FREAK out!
And what’s a FREAKFEST without freaks? We are welcoming the community to go beyond just dancing and get your true freak on.
Saturday, August 8th
10PM till you drop
Bally’s BLU Pool
For Hacks
Escape to the IOAsis – DEF CON style!
Join the IOActive research team for an exclusive sneak peek into the world of IOActive Labs. 
Friday, August 7th
12–6PM
Bally’s penthouse suite
 
Enjoy Lightning Talks with IOActive Researchers:
Straight from our hardware labs, our brilliant researchers will talk about their latest findings in a group of sessions we like to call IOActive Labs Presents:
·      Mike Davis & Michael Milvich: Lunch & Lab – an overview of the IOActive Hardware Lab in Seattle
Robert Erbes: Little Jenny is Export Controlled: When Knowing How to Type Turns 8th-graders into Weapons 
·      Vincent Berg: The PolarBearScan
·      Kenneth Shaw: The Grid: A Multiplayer Game of Destruction 
·      Andrew Zonenberg: The Anti Taco Device: Because Who Doesn’t Go to All This trouble? 
·      Sofiane Talmat: The Dark Side of Satellite TV Receivers 
·      Fernando Arnaboldi: Mathematical Incompetence in Programming Languages 
·      Joseph Tartaro: PS4: General State of Hacking the Console
·      Ilja Van Sprundel: An Inside Look at the NIC Minifilter
 
 
Black Hat/DEF CON
 
Speaker: Chris Valasek
Remote Exploitation of an Unaltered Passenger Vehicle
Black Hat: 3PM Wednesday, August 5, 2015
DEF CON: 2PM Saturday, August 8, 2015
In case you haven’t heard, Dr. Charlie Miller and I will be speaking at Black Hat and DEF CON about our remote compromise of a 2014 Jeep Cherokee (http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/). While you may have seen media regarding the project, our presentation will examine the research at much more granular level. Additionally, we have a few small bits that haven’t been talked about yet, including some unseen video, along with a 90-page white paper that will provide you with an abundance of information regarding vehicle security assessments. I hope to see you all there!
Speaker: Colin Cassidy
Switches get Stitches
Black Hat: 3PM Wednesday, August 5, 2015
DEF CON: 4PM Saturday, August 8, 2015
Have you ever stopped to think about the network equipment between you and your target? Yeah, we did too. In this talk we will be looking at the network switches that are used in industrial environments, like substations, factories, refineries, ports, or other homes of industrial automation. In other words: DCS, PCS, ICS, and SCADA switches.
We’ll be attacking the management plane of these switches because we already know that most ICS protocols lack authentication and cryptographic integrity. By compromising the switches an attacker can perform MITM attacks on a live processes.

Not only will we reveal new vulnerabilities, along with the methods and techniques for finding them, we will also share defensive techniques and mitigations that can be applied now, to protect against the average 1-3 year patching lag (or even worse, “forever-day” issues that are never going to be patched).

 

Speaker: Damon Small
Beyond the Scan: The Value Proposition of Vulnerability Assessment
DEF CON: 2PM Thursday, August 6, 2015
It is a privilege to have been chosen to present at DEF CON 23. My presentation, “Beyond the Scan: The Value Proposition of Vulnerability Assessment”, is not about how to scan a network; rather, it is about how to consume the data you gather effectively and how to transform it into useful information that will affect meaningful change within your organization.
As I state in my opening remarks, scanning is “Some of the least sexy capabilities in information security”. So how do you turn such a base activity into something interesting? Key points I will make include:
·      Clicking “scan” is easy. Making sense of the data is hard and requires skilled professionals. The tools you choose are important, but the people using them are critical.
·      Scanning a few, specific hosts once a year is a compliance activity and useful only within the context of the standard or regulation that requires it. I advocate for longitudinal studies where large numbers of hosts are scanned regularly over time. This reveals trends that allow the information security team to not only identify missing patches and configuration issues, but also to validate processes, strengthen asset management practices, and to support both strategic and tactical initiatives.

I illustrate these concepts using several case studies. In each, the act of assessing the network revealed information to the client that was unexpected, and valuable, “beyond the scan.”

 

Speaker: Fernando Arnaboldi
Abusing XSLT for Practical Attacks
Black Hat: 3:50PM Thursday, August 6, 2015
DEF CON: 2PM Saturday, August 8, 2015
XML and XML schemas (i.e. DTD) are an interesting target for attackers. They may allow an attacker to retrieve internal files and abuse applications that rely on these technologies. Along with these technologies, there is a specific language created to manipulate XML documents that has been unnoticed by attackers so far, XSLT.

XSLT is used to manipulate and transform XML documents. Since its definition, it has been implemented in a wide range of software (standalone parsers, programming language libraries, and web browsers). In this talk I will expose some security implications of using the most widely deployed version of XSLT.

 

Speaker: Jason Larsen
Remote Physical Damage 101 – Bread and Butter Attacks

Black Hat: 9AM Thursday, August 6, 2015

 

Speaker: Jason Larsen
Rocking the Pocket Book: Hacking Chemical Plant for Competition and Extortion

DEF CON:  6PM Friday, August 7, 2015

 

Speaker: Kenneth Shaw
The Grid: A Multiplayer Game of Destruction
DEF CON: 12PM Sunday, August 9, 2015, IoT Village, Bronze Room

Kenneth will host a table in the IoT Village at DEF CON where he will present a demo and explanation of vulnerabilities in the US electric grid.

 

Speaker: Sofiane Talmat
Subverting Satellite Receivers for Botnet and Profit
Black Hat: 5:30PM Wednesday, August 5, 2015
Security and the New Generation of Set Top Boxes
DEF CON: 2PM Saturday, August 8, 2015, IoT Village, Bronze Room
New satellite TV receivers are revolutionary. One of the devices used in this research is much more powerful than my graduation computer, running a Linux OS and featuring a 32-bit RISC processor @450 Mhz with 256MB RAM.

Satellite receivers are massively joining the IoT and are used to decrypt pay TV through card sharing attacks. However, they are far from being secure. In this upcoming session we will discuss their weaknesses, focusing on a specific attack that exploits both technical and design vulnerabilities, including the human factor, to build a botnet of Linux-based satellite receivers.

 

Speaker: Alejandro Hernandez
Brain Waves Surfing – (In)security in EEG (Electroencephalography) Technologies
DEF CON: 7-7:50PM Saturday, August 8, 2015, BioHacking Village, Bronze 4, Bally’s

Electroencephalography (EEG) is a non-invasive method for recording and studying electrical activity (synapse between neurons) of the brain. It can be used to diagnose or monitor health conditions such as epilepsy, sleeping disorders, seizures, and Alzheimer disease, among other clinical uses. Brain signals are also being used for many other different research and entertainment purposes, such as neurofeedback, arts, and neurogaming.

 

I wish this were a talk on how to become Johnny Mnemonic, so you could store terabytes of data in your brain, but, sorry to disappoint you, I will only cover non-invasive EEG. I will cover 101 issues that we all have known since the 90s, that affect this 21st century technology.

 

I will give a brief introduction of Brain-Computer Interfaces and EEG in order to understand the risks involved in brain signal processing, storage, and transmission. I will cover common (in)security aspects, such as encryption and authentication as well as (in)security in design. Also, I will perform some live demos, such as the visualization of live brain activity, sniffing of brain signals over TCP/IP, as well as software bugs in well-known EEG applications when dealing with corrupted brain activity files. This talk is a first step to demonstrating that many EEG technologies are vulnerable to common network and application attacks.
INSIGHTS | May 11, 2015

Vulnerability disclosure the good and the ugly

By Cesar Cerrudo

I can’t believe I continue to write about disclosure problems. More than a decade ago, I started disclosing vulnerabilities to vendors and working with them to develop fixes. Since then, I have reported hundreds of vulnerabilities. I often think I have seen everything, and yet, I continue to be surprised over and over again. I wrote a related blog post a year and a half ago (Vulnerability bureaucracy: Unchanged after 12 years), and I will continue to write about disclosure problems until it’s no longer needed.

 

Everything is becoming digital. Vendors are producing software for the first time or with very little experience, and many have no security knowledge. As a result, insecure software is being deployed worldwide. The Internet of Things (IoT), industrial devices and industrial systems (SCADA/ICS), Smart City technology, automobile systems, and so on are insecure and getting worse instead of better.

 

Besides lacking of security knowledge, many vendors do not know how to deal with vulnerability reports. They don’t know what to do when an individual researcher or company privately discloses a vulnerability to them, how to properly communicate the problem, or how to fix it. Many vendors haven’t planned for security patches. Basically, they never considered the possibility of a latent security flaw. This creates many of the problems the research community commonly faces.

 

When IOActive recently disclosed vulnerabilities in CyberLock products, we faced problems, including threats from CyberLock’s lawyers related to the Digital Millennium Copyright Act (DMCA). CyberLock’s response is a very good example of a vendor that does not know how to properly deal with vulnerability reports.

 

On the other hand, we had a completely different experience when we recently reported vulnerabilities to Lenovo. Lenovo’s response was very professional and collaborative. They even publicly acknowledged our collaboration:

 

“Lenovo’s development and security teams worked directly with IOActive regarding their System Update vulnerability findings, and we value their expertise in identifying and responsibly reporting them.”

Source: http://www.absolutegeeks.com/2015/05/06/round-2-lenovo-is-back-in-the-news-for-a-new-security-risk-in-their-computers (no longer active)

IOActive approached both cases in the same way, but with two completely different reactions and results.

 

We always try to contact the affected vendor through a variety of channels and offer our collaboration to ensure a fix is in place before we disclose our research to the public. We invest a lot of time and resources to helping vendors understand the vulnerabilities we find. We have calls with developers and managers, test their fixes, and so on, all for free without expecting anything in return. We do not propose nor discuss business opportunities; our only motive is to see that the vulnerabilities get fixed. We have a great track record; we’ve reported dozens of vulnerabilities and collaborated with many vendors and CERTs too.

 

When a vendor is nonresponsive, we feel that the best solution is usually to disclose the vulnerability to the public. We do this as a last resort, as no vendor patch or solution will be available in such a case. We do not want to be complicit in hiding a flaw. Letting people know can force the vendor to address the vulnerability.

Dealing with vulnerability reports shouldn’t be this difficult. I’m going to give some advice, based on my experience, to help companies avoid vulnerability disclosure problems and improve the security of their products:

 

  • Clearly display a contact email for vulnerability reports on the company/product website
  • Continuously monitor that email address and instantly acknowledge when you get a vulnerability report
  • Agree on response procedures including regular timeframes for updating status information after receiving the report
  • Always be collaborative with the researcher/company, even if you don’t like the reporter
  • Always thank the researcher/company for the report, even if you don’t like the reporter
  • Ask the reporter for help if needed, and work together with the reporter to find better solutions
  • Agree on a time for releasing a fix
  • Agree on a time for publicly disclosing the vulnerability
  • Release the fix on time and alert customers

That’s it! Not so difficult. Any company that produces software should follow these simple guidelines at a minimum.

It comes down to this: If you produce software, consider the possibility that your product will have security vulnerabilities and plan accordingly. You will do yourself a big favor, save money, and possibly save your company’s reputation too.
RESEARCH | July 31, 2014

Hacking Washington DC traffic control systems

By Cesar Cerrudo

This is a short blog post, because I’ve talked about this topic in the past. I want to let people know that I have the honor of presenting at DEF CON on Friday, August 8, 2014, at 1:00 PM. My presentation is entitled “Hacking US (and UK, Australia, France, Etc.) Traffic Control Systems”. I hope to see you all there. I’m sure you will like the presentation.

I am frustrated with Sensys Networks (vulnerable devices vendor) lack of cooperation, but I realize that I should be thankful. This has prompted me to further my research and try different things, like performing passive onsite tests on real deployments in cities like Seattle, New York, and Washington DC. I’m not so sure these cities are equally as thankful, since they have to deal with thousands of installed vulnerable devices, which are currently being used for critical traffic control.

The latest Sensys Networks numbers indicate that approximately 200,000 sensor devices are deployed worldwide. See http://www.trafficsystemsinc.com/newsletter/spring2014.html. Based on a unit cost of approximately $500, approximately $100,000,000 of vulnerable equipment is buried in roads around the world that anyone can hack. I’m also concerned about how much it will cost tax payers to fix and replace the equipment.

One way I confirmed that Sensys Networks devices were vulnerable was by traveling to Washington DC to observe a large deployment that I got to know.

When I exited the train station, the fun began.

INSIGHTS | April 30, 2014

Hacking US (and UK, Australia, France, etc.) Traffic Control Systems

By Cesar Cerrudo
Probably many of you have watched scenes from “Live Free or Die Hard” (Die Hard 4) where “terrorist hackers” manipulate traffic signals by just hitting Enter or typing a few keys. I wanted to do that! I started to look around, and while I couldn’t exactly do the same thing (too Hollywood style!), I got pretty close. I found some interesting devices used by traffic control systems in important US cities, and I could hack them 🙂 These devices are also used in cities in the UK, France, Australia, China, etc., making them even more interesting.
After getting the devices, it wasn’t difficult to find vulnerabilities (actually, it was more difficult to make them work properly, but that’s another story).

The vulnerabilities I found allow anyone to take complete control of the devices and send fake data to traffic control systems. Basically anyone could cause a traffic mess by launching an attack with a simple exploit programmed on cheap hardware ($100 or less).
I even tested the attack launched from a drone flying at over 650 feet, and it worked! Theoretically, an attack could be launched from up to 1 or 2 miles away with a better drone and hardware equipment, I just used a common, commercially available drone and cheap hardware. Since it seems flying a drone in the US is not illegal and anyone will be able to get drones on demand soon, I would be worried about attacks from the sky in the US.
It might also be possible to create self-replicating malware (worm) that can infect these vulnerable devices in order to launch attacks affecting traffic control systems later. The exploited device could then be used to compromise all of the same devices nearby.
 
What worries me the most is that if a vulnerable device is compromised, it’s really, really difficult and really, really costly to detect it. So there could already be compromised devices out there that no one knows about or could know about. 
 
Let me give you an idea of how affected some cities are. The following is from documentation from vulnerable vendors:
  • 250+ customers in 45 US states and 10 countries
  • Important US cities have deployments: New York, Washington DC, San Francisco, Los Angeles, Boston, Seattle, etc.
  • 50,000+ devices deployed worldwide (most of them in the US)
  • Countries include US, United Kingdom, China, Canada, Australia, France, etc. For instance, some UK cities with deployments: London, Shropshire, Slough, Bournemouth, Aberdeen, Blackburn with Darwen Borough Council, Belfast, etc. 
  • Australia has a big deployment on one of the most important and modern freeways.


As you can see, there are 50,000+ devices out there that could be hacked and cause traffic messes in many important cities.

Going onsite
I knew that the devices I have are vulnerable, but I wanted to be 100% sure that I wasn’t missing anything with my tests. Real-life deployments could have different configurations (different hardware/software versions)  

and it seemed that the vendor provided wrong information when I reported the vulnerabilities, so maybe what I found didn’t affect real-life deployments. I put my “tools” in my backpack and went to Seattle, New York, and Washington DC to do some “passive” onsite tests (“no hacking and nothing illegal” :)). Luckily, I could confirm that what I found applied to real-life deployments. BTW, many thanks to Ian Amit for the pictures and videos and for daring to go with me to DC :).
Vulnerabilities
As you may have already realized, I’m not going to share specific nor technical details here (for that, you will have to wait and go to Infiltrate 2014 in a couple of weeks. What I would like to mention is that the vendor was contacted a long time ago (September 2013) through ICS-CERT (the initial report to ICS-CERT was sent on July 31st, 2013). I was told by ICS-CERT that the vendor said that they didn’t think the issues were critical nor even important. For instance, regarding one of the vulnerabilities, the vendor said that since the devices were designed that way (insecure) on purpose, they were working as designed, and that customers (state/city governments) wanted the devices to work that way (insecure), so there wasn’t any security issue. Yes that was the answer, I couldn’t believe it. 
 
Regarding another vulnerability, the vendor said that it’s already fixed on newer versions of the device. But there is a big problem, you need to get a new device and replace the old one. This is not good news for state/city governments, since thousands of devices are already out there, and the time and money it would take to replace all of them is considerable. Meanwhile, the existing devices are vulnerable and open to attack.
 
Another excuse the vendor provided is that because the devices don’t control traffic lights, there is no need for security. This is crazy, because while the devices don’t directly control traffic control systems, they have a direct influence on the actions and decisions of these systems.
I tried several times to make ICS-CERT and the vendor understand that these issues were serious, but I couldn’t convince them. In the end I said, if the vendor doesn’t think they are vulnerable then OK, I’m done with this; I have tried hard, and I don’t want to continue wasting time and effort. Also, since DHS is aware of this (through ICS-CERT), and it seems that this is not critical nor important to them, then there isn’t anything else I can do except to go public.
 
This should be another wake up call for governments to evaluate the security of devices/products before using them in critical infrastructure, and also a request to providers of government devices/products to take security and security vulnerability reports seriously.
 
Impact
 
By exploiting the vulnerabilities I found, an attacker could cause traffic jams and problems at intersections, freeways, highways, etc. 
Electronic signs
It’s possible to make traffic lights (depending on the configuration) stay green more or less time, stay red and not change to green (I bet many of you have experienced something like this as a result of driving during non-traffic hours late at night or being on a bike or in a small car), or flash. It’s also possible to cause electronic signs to display incorrect speed limits and instructions and to make ramp meters allow cars on the freeway faster or slower than needed. 
 
These traffic problems could cause real issues, even deadly ones, by causing accidents or blocking ambulances, fire fighters, or police cars going to an emergency call.
I’m sure there are manual overrides and secondary controls in place that can be used if anomalies are detected and could mitigate possible attacks, and some traffic control systems won’t depend only on these vulnerable devices. This doesn’t mean that attacks are impossible or really complex; the possibility of a real attack shouldn’t be disregarded, since launching an attack is simple. The only thing that could be complex is making an attack have a bigger impact, but complex doesn’t mean impossible.
 

Traffic departments in states/cities with vulnerable devices deployed should pay special attention to traffic anomalies when there is no apparent reason and closely watch the device’s behavior.
 
“In 2012, there were an estimated 5,615,000 police-reported traffic crashes in which 33,561 people were killed and 2,362,000 people were injured; 3,950,000 crashes resulted in property damage only.” US DoT National Highway Traffic Safety Administration: Traffic Safety Facts
 
“Road crashes cost the U.S. $230.6 billion per year, or an average of $820 per person” Association for Safe International Road Travel: Annual US Road Crash Statistics
 
If you add malfunctioning traffic control systems to the above stats, the numbers could be a lot worse.
INSIGHTS | February 17, 2014

INTERNET-of-THREATS

By Cesar Cerrudo
At IOActive Labs, I have the privilege of being part of a great team with some of the world’s best hackers. I also have access to really cool research on different technologies that uncovers security problems affecting widely used hardware and software. This gives me a solid understanding of the state of security for many different software and hardware devices, not just opinions based on theories and real life experience.
 
Currently, the term Internet-of-Things (IoT) is becoming a buzzword used in the media, announcements from hardware device manufacturers, etc. Basically, it’s used to describe an Internet with everything connected to it. It describes what we are seeing nowadays, including:
  • Laptops, tablets, smartphones, set-top boxes, media-streaming devices, and data-storage devices
  • Watches, glasses, and clothes
  • Home appliances, home switches, home alarm systems, home cameras, and light bulbs
  • Industrial devices and industrial control systems
  • Cars, buses, trains, planes, and ships
  • Medical devices and health systems
  • Traffic sensors, seismic sensors, pollution sensors, and weather sensors
     …and more; you name it, and it is or soon will be connected to the Internet.
 
While the devices and systems connected to the Internet are different, they have something in common–most of them suffer from serious security vulnerabilities. This is not a guess. It is based on IOActive Labs’ security research into many of these types of devices currently being used worldwide. Sadly, we are seeing almost the exact same vulnerabilities on these devices that have plagued software vendors over the last decade. Vulnerabilities that the most important software vendors are trying hard to eradicate. It seems that many hardware companies are following really poor security practices when adding software to their products and connecting them to the Internet. What is worse is that sometimes vendors don’t even respond to security vulnerability reports or just downplay the threat and don’t fix the vulnerabilities. Many vendors don’t even know how to properly deal with the security vulnerabilities being reported.
 
Some of common vulnerabilities IOActive Labs finds include:
  • Sensitive data sent over insecure channels
  • Improper use of encryption
    • No SSL certificate validation
    • Things like encryption keys and signing certificates easily available to anyone
  • Hardcoded credentials/backdoor accounts
  • Lack of authentication and/or authorization
  • Storage of sensitive data in clear text
  • Unauthenticated and/or unauthorized firmware updates
  • Lack of firmware integrity check during updates
  • Use of insecure custom made protocols
Also, data ambition is working against vendors and is increasing attack surfaces considerably. For example, all data collected is sent to “vendor cloud” and device commands are sent from “vendor cloud”, instead of just allowing users to connect directly to and command their devices. Hacking into “vendor cloud” = thousands of devices compromised = lots of lost money.
 
Why should we worry about all of this? Well, these devices affect our everyday life and will continue to do so more and more. We’ve only seen the tip of the iceberg when it comes to the attacks that people, companies, and governments face and how easily they can be performed. If the situation doesn’t change soon, it is just matter of time before we witness attacks with tragic consequences.
 
If a headline like “+100K Digital Toilets from XYZ1.3 Inc. Found Sending Spam and Distributing Malware” doesn’t scare you because you think it’s funny and improbable, you could be wrong. We shouldn’t wait for headlines such as “Dozens of People Injured When Home Automation Devices Hacked” before we react.
 
Something must be done! From enforcing secure practices during product development to imposing high fines when products are hacked, action must be taken to prevent the loss of money and possibly even lives.
 
Companies should strongly consider:
    • Training developers on secure development
    • Implementing security development practices to improve software security
    • Training company staff on security best practices
    • Implementing a security patch development and distribution process
    • Performing product design/architecture security reviews
    • Performing source code security audits
    • Performing product penetration tests
    • Performing company network penetration tests
    • Staying up-to-date with new security threats
    • Creating a bug bounty program to reward reported vulnerabilities and clearly defining how vulnerabilities should be reported
    • Implementing a security incident/emergency response team
It is difficult to give advice to end users given that the best solution is just not to buy or use many products because they are insecure by design. At this stage, it’s just matter of being lucky and hoping that you won’t be hacked. Maybe opportunistic vendors could come up with some novel solution such as an IPS/anti* device that will protect all of your devices from attacks. Just pray that the protection device itself is not vulnerable.
 
Sometimes end users are forced to live with insecure devices since there isn’t any way to turn them off or not to use them. These include devices provided by TV cable companies, electricity and gas companies, public services companies, governments, etc. These companies and the government should take responsibility for deploying secure products.
 
This is not BS–in a couple of days we will be releasing some of the extensive research I mentioned and on which this blog post is based.
 
I intend for this post to be a wakeup call for everyone! I’m really concerned about the current situation. In the meantime, I will use the term INTERNET-of-THREATS (not Internet-of-Things). Maybe this new buzzword will make us more conscious of the situation. If it doesn’t, then at least I have tried.
INSIGHTS | December 4, 2013

Practical and cheap cyberwar (cyber-warfare): Part II

By Cesar Cerrudo
Disclaimer: I did not perform any illegal attacks on the mentioned websites in order to get the information I present here. No vulnerability was exploited on the websites, and they are not known to be vulnerable.
 
Given that we live in an age of information leakage where government surveillance and espionage abound, I decided in this second part to focus on a simple technique for information gathering on human targets. If an attacker is targeting a specific country, members of the military and defense contractors would make good human targets. When targeting members of the military, an attacker would probably focus on high ranking officers and for defense contractors, an attacker would focus on key decision makers, C-level executives, etc. Why? Because if an attacker compromises these people, they could gain access to valuable information related to their work, their personal life, and family. Data related to their work could help an attacker strategically by enabling them to build better defenses, steal intellectual property, and craft specific attacks. Data related to a target’s personal life could help attackers for blackmailing or attacking the target’s families.
 
 
There is no need to work for the NSA and have a huge budget in order to get juicy information. Everything is just one click away; attackers only need to find ways to easily milk the web. One easy way to gather information about people is to get their email addresses as I have described last year here http://blog.ioactive.com/2012/08/the-leaky-web-owning-your-favorite-ceos.html . Basically you use a website registration form and/or forgotten password functionality to find out if an email address is already registered on a website. With a list of email addresses attackers can easily enumerate the websites/services where people have accounts. Given the ever-increasing number of online accounts one person usually has, this could provide a lot of useful information. For instance, it could make perform phishing attacks and social engineering easier (see http://www.infosecurity-magazine.com/view/35048/hackers-target-mandiant-ceo-via-limo-service/). Also, if one of the sites where the target has an account is vulnerable, that website could be hacked in order to get the target’s account password. Due to password reuse, attackers can compromise all the target accounts most of the time. 
 
 
This is intended to be easy and practical, so let’s get hands on. I did this research about a year ago. First, I looked for US Army email addresses. After some Google.com searches, I ended up with some PDF files with a lot of information about military people and defense contractors:
I extracted some emails and made a list. I ended up with:
 
1784 total email addresses: military (active and retired), civilians, and defense contractors.
 
I could have gotten more email addresses, but that was enough for testing purposes. I wasn’t planning on doing a real attack.
 
I had a very simple (about 50 LoC or so) Python tool (thanks to my colleague Ariel Sanchez for quickly building original tool!) that can be fed a list of websites and email addresses. I had already built the website database with 20 or so common and well known websites (I should have used military related ones too for better results, but it still worked well), I loaded the list of email addresses I had found, and then ran the tool. A few minutes later I ended up with a long list of email addresses and the websites where those email addresses were used (meaning where the owners of those email addresses have accounts):
 
Site
Accounts
     %
Facebook
  308
17.26457
Google
  229
12.83632
Orbitz
  182
10.20179
WashingtonPost
  149
8.352018
Twitter 
  108
6.053812
Plaxo
  93
5.213004
LinkedIn
  65
3.643498
Garmin
  45
2.522422
MySpace
  44
2.466368
Dropbox
  44
2.466368
NYTimes
  36
2.017937
NikePlus
  23
1.289238
Skype
  16
0.896861
Hulu
  13
0.7287
Economist
  11
0.616592
Sony Entertainment Network
  9
0.504484
Ask
  3
0.168161
Gartner
  3
0.168161
Travelers
  2
0.112108
Naymz
  2
0.112108
Posterous
  1
0.056054
 
Interesting to find accounts on Sony Entertainment Network website, who says the military can’t play Playstation 🙂
 
I decided that I should focus on something juicier, not just random .mil email addresses. So, I did a little research about high ranking US Army officers, and as usual, Google and Wikipedia ended up being very useful.
 
Let’s start with US Army Generals. Since this was done in 2012, some of them could be retired now.
 
I found some retired ones that now may be working for defense contractors and trusted advisors:
 
Active US Army Generals seem not to use their .mil email addresses on common websites; however, we can see a pattern that almost all of them use orbitz.com. For retired ones, since we got the personal (not .mil) email addresses, we can see they use them on many websites.
After US Army Generals, I looked at Lieutenant Generals (we could say future Generals):
Maybe because they are younger they seem to use their .mil email address in several common websites including Facebook.com. Even more, they have most of their Facebook information available to public! I was thinking about publishing the related Facebook information, but I will leave it up to you to explore their Facebook profiles.
 
I also looked for US Army Mayor Generals and found at least 15 of them:
 
Robert Abrams
Email: robert.abrams@nullus.army.mil
 
 
 
Found account on site: orbitz.com
 
Found account on site: washingtonpost.com
 
 
Jamos Boozer
Email: james.boozer@nullus.army.mil
 
 
 
Found account on site: orbitz.com
 
Found account on site: facebook.com
 
 
Vincent Brooks
Email: vincent.brooks@nullus.army.mil
 
 
 
Found account on site: facebook.com
 
Found account on site: linkedin.com
 
 
James Eggleton
Email: james.eggleton@nullus.army.mil
 
 
 
Found account on site: plaxox.com
 
 
Reuben Jones
Email: reuben.jones@nullus.army.mil
 
 
 
Found account on site: plaxo.com
 
Found account on site: washingtonpost.com
 
 
 
 
David quantock
Email: david-quantock@nullus.army.mil
 
 
 
Found account on site: twitter.com
 
Found account on site: orbitz.com
 
Found account on site: plaxo.com
 
 
 
 
Dave Halverson
Email: dave.halverson@nullconus.army.mil
 
 
 
Found account on site: linkedin.com
 
 
Jo Bourque
Email: jo.bourque@nullus.army.mil
 
 
 
Found account on site: washingtonpost.com
 
 
 
 
Kev Leonard
Email: kev-leonard@nullus.army.mil
 
 
 
Found account on site: facebook.com
 
 
James Rogers
Email: james.rogers@nullus.army.mil
 
 
 
Found account on site: plaxo.com
 
 
 
 
William Crosby
Email: william.crosby@nullus.army.mil
 
 
 
Found account on site: linkedin.com
 
 
Anthony Cucolo
Email: anthony.cucolo@nullus.army.mil
 
 
 
Found account on site: twitter.com
 
Found account on site: orbitz.com
 
Found account on site: skype.com
 
Found account on site: plaxo.com
 
Found account on site: washingtonpost.com
 
Found account on site: linkedin.com
 
 
Genaro Dellrocco
Email: genaro.dellarocco@nullmsl.army.mil
 
 
 
Found account on site: linkedin.com
 
 
Stephen Lanza
Email: stephen.lanza@nullus.army.mil
 
 
 
Found account on site: skype.com
 
Found account on site: plaxo.com
 
Found account on site: nytimes.com
 
 
Kurt Stein
Email: kurt-stein@nullus.army.mil
 
 
 
Found account on site: orbitz.com
 
Found account on site: skype.com
 
 
Later I found about 7 US Army Brigadier General and 120 US Army Colonel email addresses, but I didn’t have time to properly filter the results. These email addresses were associated with many website accounts.
 
Basically, the 1784 total email addresses included a broad list of ranking officers from the US Army.
 
Doing a quick analysis of the gathered information we could infer: 
  • Many have Facebook accounts exposing to public the family and friend relations that could be targeted by attackers. 
  • Most of them read and are probably subscribed to The Washington Post (makes sense, no?). This could be an interesting avenue for attacks such as phishing and watering hole attacks. 
  • Many of them use orbitz.com, probably for car rentals. Hacking this site can give attackers a lot of information about how they move, when they travel, etc. 
  • Many of them have accounts on google.com probably meaning they have Android devices (Smartphones, tablets, etc.).This could allow attackers to compromise the devices remotely (by email for instance) with known or 0days exploits since these devices are not usually patched and not very secure.
  • And last but not least, many of them including Generals use garmin.com or nikeplus.com. Those websites are related with GPS devices including running watches. These websites allow you to upload GPS information making them very valuable for attackers for tracking purposes. They could know on what area a person usually runs, travel, etc.

 

 
As we can see, it’s very cheap and easy to get information about ranking members of the US Army. People serving in the US Army should take extra precautions. They should not make their email addresses public and should only use them for “business” related issues, not personal activities.
INSIGHTS | November 11, 2013

Practical and cheap cyberwar (cyber-warfare): Part I

By Cesar Cerrudo
Every day we hear about a new vulnerability or a new attack technique, but most of the time it’s difficult to imagine the real impact. The current emphasis on cyberwar (cyber-warfare if you prefer) leads to myths and nonsense being discussed. I wanted to show real life examples of large scale attacks with big impacts on critical infrastructure, people, companies, etc.
 

The idea of this post is to raise awareness. I want to show how vulnerable some industrial, oil, and gas installations currently are and how easy it is to attack them. Another goal is to pressure vendors to produce more secure devices and to speed up the patching process once vulnerabilities are reported.


The attack in this post is based on research done by my fellow pirates, Lucas Apa and Carlos Penagos. They found critical vulnerabilities in wireless industrial control devices. This research was first presented at BH USA 2013. You can find their full presentation here https://www.blackhat.com/us-13/archives.html#Apa
 
A common information leak occurs when vendors highlight how they helped Company X with their services or products. This information is very useful for supply chain attacks. If you are targeting Company X, it’s good to look at their service and product providers. It’s also useful to know what software/devices/technology they use.

 

In this case, one of the vendors that sells vulnerable wireless industrial control devices is happy to announce in a press release that Company X has acquired its wireless sensors and is using them in the Haynesville Shale fields. So, as an attacker, we now know that Company X is using vulnerable wireless sensors at the Haynesville Shale fields. Haynesville Shale fields, what’s that? Interesting, with a quick Google search you end up with:
 
 
 
How does Google know about shale well locations? It’s simple, publically-available information. You can display wells by name, organization, etc.:
 
 
 
 
 
Even interactive maps are available:
 
 
 
You can find all of Company X’s wells along with their exact location (geographical coordinates). You know almost exactly where the vulnerable wireless sensors are installed.
 
Since the wells are at a remote location, exploiting the wireless sensor vulnerabilities becomes an interesting challenge. Enter drones, UAV unmanned aerial vehicles. Commercially available drones range from a couple hundred dollars to tens of thousands dollars, depending on range, endurance, functionality, etc. You can even build your own and save some money. The idea is to put the attack payload in a drone, send it to the wells’ location, and launch the attack. This isn’t difficult to do since drones can be programmed to fly to x,y coordinates and execute the payload while flying around the target coordinates (no need to return). 
 
Depending on your budget, you can launch an attack from a nearby location or very far away. Depending on the drone’s endurance, you can be X miles away from the target. You can extend the drone’s range depending on the radio and antenna used. 
 
The types of exploits you could launch from the drone range from bricking all of the wireless devices to causing some physical harm on the shale gas installations. Manipulating device firmware or injecting fake data on radio packets could make the control systems believe things like the temperature or pressure are wrong. Just bricking the devices could result in significant lost money to Company X. The devices would need to be reconfigured/reflashed. The exploits could interfere with shale gas extraction and even halt production. The consequences of an attack could be even more catastrophic depending on how the vulnerable devices are being used.
 
Attacks could be expanded to target more than just one vendor’s device. Drones could do reconnaissance first, scan and identify devices from different vendors, and then launch attacks targeting all of the specific devices.
 
In order to highlight attack possibilities and impact consequences I extracted the following from http://www.onworld.com/news/newsoilandgas.html (the companies mentioned in this article are not necessarily vulnerable, this is just for illustrative purposes):
 
“…Pipelines & Corrosion Monitoring
Wireless flow, pressure, level, temperature and valve position monitoring are used to streamline pipeline operation and storage while increasing safety and regulatory compliance. In addition, wireless sensing solutions are targeted at the billions of dollars per year that is spent managing pipeline corrosion. While corrosion is a growing problem for the aging pipeline infrastructure it can also lead to leaks, emissions and even deadly explosions in production facilities and refineries….”
 
Leaks and deadly explosions can have sad consequences.
 
Cyber criminals, terrorists, state actors, etc. can launch big impact attacks with relatively small budgets. Their attacks could produce economical loses, physical damage, even possible explosions.
 
While isolated attacks have a small impact when put in the context of cyberwar, they can cause panic in populations, political crisis, or geopolitical problems if combined with other larger impact attacks.
Probably in a future post I will describe more of these kinds of large scale, big impact attacks.
INSIGHTS | October 18, 2013

NCSAM – an Interview with Cesar Cerrudo

By Cesar Cerrudo & Craig Brophy
Today we continue our support for National Cyber Security Awareness Month, by interviewing Cesar Cerrudo, Chief Technology Officer for IOActive Labs. Cesar provides us with some insight of how he got into IT security and why it’s important to be persistent!

IOActive: How did you get into security?
 
Cesar: I think my first hacks were when I was 10 years old or so. I modified BASIC code on CZ Spectrum games and also cheated games by loading different parts of the code from a cassette (yes not floppy disk at that time and loading games from a cassette took around 5-10mins and if something went wrong you have to try again, I don’t miss that at all ), but after that I was mostly away from computers until I was 19 years old and went to college.
I was always interested on learning to hack but didn’t have enough resources or access to a PC. So while I was at college I started to read books, articles, etc. – anything I could get my hands on. I used to play (and sometimes break) a friend’s PC (hi Flaco ) once in a while when I had the opportunity. I remember learning Assembly language just from reading books and looking at virus code printed in papers. Finding that virus code and learning from it was amazing (not having a PC wasn’t a problem; a PC is just a tool).
Later on, with some internet access (an hour or so a week), it became easier since lots of information became available and I got access to a PC; so I started to try the things I read about and started to build my own tools, etc.
When you’re learning and reading, one topic takes you to another topic and so on, but I focused on things that I was more familiar with – like web apps, database servers, Microsoft Windows, etc.
Luckily in Argentina it wasn’t illegal to hack at that time so I could try things in real life and production systems . A long time ago, I remember walking to the office of the CEO of my local ISP provider handing him hundred thousands of users, passwords and credit card information and telling him that their servers where hackable and that I hacked them. I know this sounds crazy but I was young and in the end they thank me, and I helped them identify and fix the vulnerabilities. I asked for a job but no luck, don’t know why .
I also did other crazy hacks when I was young but better to not talk about that , nothing criminal. I used to report the vulnerabilities but most admins didn’t like it. I recommend not engaging in anything illegal, as nowadays you can easily end up in jail if you try to hack a system. Today it is simpler to build a lab and play safely at home.
Luckily those crazy times ended and soon I started to find vulnerabilities in known and widely used software such as SQL Server, Oracle, Windows, etc., I was then also able to create some new attack and exploitation techniques, etc.
IOActive: What do you find most exciting about security?
 
Cesar: Learning new things, challenges, solving difficult problems, etc. You get to deeply study how some technologies work and can identify security problems on software/hardware massively used worldwide that sometimes have big impact on everyone’s lives since everything has become digital nowadays.
IOActive: What do you like to research, and why?
 
Cesar: This is related to previous answers, but I like challenges, learning and hacking stuff.
IOActive: What advice would you give to someone who would like to become a pentester/researcher?
 
Cesar: My advice would be if you are interested in or like hacking, nothing can stop you. Everything is out there to learn. You just need to try hard and put in a lot of effort without ever giving up. Nothing is impossible it’s just matter of effort and persistence.
INSIGHTS | September 10, 2013

Vulnerability bureaucracy: Unchanged after 12 years

By Cesar Cerrudo

One of my tasks at IOActive Labs is to deal with vulnerabilities; report them, try to get them fixed, publish advisories, etc. This isn’t new to me. I started to report vulnerabilities something like 12 years ago and over that time I have reported hundreds of vulnerabilities – many of them found by me and by other people too.

Since the early 2000’s I have encountered several problems when reporting vulnerabilities:
  • Vendor not responding
  • Vendor responding aggressively
  • Vendor responding but choosing not to fix the vulnerability
  • Vendor releasing flawed patches or didn’t patch some vulnerabilities at all
  • Vendor failing to meet deadlines agreed by themselves

It’s really sad to tell that, as of right now, 12 years later, I continue to see most (if not all) of the same problems. Not only that, but some organizations that are supposed to help and coordinate vulnerability reporting and disclosure (CERTs) are starting to fail, being non responsive and not contributing much to the effort.

This shouldn’t be a big problem if you are reporting low impact or unimportant vulnerabilities, but most of the time the team here at IOActive report critical vulnerabilities affecting systems ranging from critical infrastructure to the most popular commercial applications, OS’s, etc. used by millions of people around the world. There is a big responsibility upon us to work with the affected vendors to get the vulnerabilities fixed and thinking about how bad things could be if they are exploited.

It’s also surprising to sometimes see the tardy response from some teams that are supposed to act and respond fast such as Android security team given that Google has some strong vulnerability polices (1, 2):

It would be nice if most vendors, CERTs, etc. are aware of the following:
  • Independent researchers and security consulting companies report vulnerabilities on a voluntary basis.
  • Independent researchers and security consulting companies have no obligation to report security vulnerabilities.
  • Independent researchers and security consulting companies often invest a lot of time, effort and resources finding vulnerabilities and trying to get them fixed.
  • Vendors and CERTs should be more appreciative of the people reporting vulnerabilities and, at the very least, be more responsive than they typically are today.
  • Vendors and CERTs should adhere and comply with their own defined deadlines.
I would like for vendors and CERTs to start improving a little and becoming more responsive; the attack surface grows everyday and vulnerabilities affect our lives more and more. The more we depend on technology the more the vulnerabilities will impact us.

There shouldn’t be vulnerability bureaucracy.

If there’s one thing that vendors and CERTs could do to improve the situation, that would be for them to step-up and be accountable for the vulnerability information entrusted to them.

 

I hope that in the following 12 years something will change for the better.