Category: INSIGHTS

INSIGHTS | August 23, 2013

IE heaps at Nordic Security Conference

By Chris Valasek
Remember when I used to be the Windows Heap guy? Yeah, me neither ;). I just wanted to give everyone a heads up regarding my upcoming presentation “An Examination of String Allocations: IE-9 Edition” at Nordic Security Conference (www.nsc.is). The presentation title is a bit vague so I figured I would give a quick overview.
First, I’ll briefly discuss the foundational knowledge regarding heap based memory allocations using JavaScript strings in IE-6 and IE-7. These technics to manipulate the heap are well documented and have been known for quite some time [1].

While heap spraying and allocation techniques have continued to be used, public documentation of such techniques has been lacking. I specifically remember Nico Waisman talking about using the DOM [2] to perform precise allocations, but I don’t recall specific details being released. Nico’s presentation inspired me to reverse engineer a small portion of IE-9’s JavaScript implementation when it came to string based memory manipulation techniques. (Editor’s note: I’ve been holding onto this for 2 years, WTF Chris?).

Next I’ll cover, in detail, the data structures and algorithms used in IE-9 that are common during the exploitation process when performing typical string manipulations. Hopefully the details will give insight into what actually happens for vanilla exploitation attempts.

Lastly, I’ll demo a library which I’m calling heapLib2. HeapLib2 is an extension of Alex Sotirov’s original heap library that will work with modern versions of Internet Explorer when requiring precise heap-based allocations. You can now do some neat memory tricks with a few simple lines.

 



One final reflection; if you haven’t been to Nordic Security Conference (or Iceland in general) you should consider going. The conference has an attentive but laid back atmosphere while providing both highly technical and high level security presentations. If you’ve been looking for an excuse to go to Iceland get yourself to Nordic Security Conference!

 
[1] – http://www.phreedom.org/research/heap-feng-shui/
P.S. These techniques _MAY_ work with versions of IE that are greater than version 9

 

P.P.S. Ok, they DO work.
INSIGHTS | August 20, 2013

FDA Medical Device Guidance

By Gunter Ollmann

Last week the US Food and Drug Administration (FDA) finally released a couple of important documents. The first being their guidance on using radio frequency wireless technology in medical devices (replacing a draft from January 3,2007), and a second being their new (draft) guidance on premarket submission for management of cybersecurity in medical devices.

The wireless technology guidance document seeks to address many of the risks and vulnerabilities that have been disclosed in medical devices (embedded or otherwise) in recent years – in particular those with embedded RF wireless functionality…

The recommendations in this guidance are intended for RF wireless medical devices including those that are implanted, worn on the body or other external wireless medical devices intended for use in hospitals, homes, clinics, clinical laboratories, and blood establishments.  Both wireless induction-based devices and radiated RF technology device systems are within the scope of this guidance.

The FDA wishes medical device manufacturers to consider the design, testing and use of wireless medical devices…

In the design, testing, and use of wireless medical devices, the correct, timely, and secure transmission of medical data and information is important for the safe and effective use of both wired and wireless medical devices and device systems. This is especially important for medical devices that perform critical functions such as those that are life-supporting or life-sustaining. For wirelessly enabled medical devices, risk management should include considerations for robust RF wireless design, testing, deployment, and maintenance throughout the life cycle of the product.

For most of you reading the IOActive Labs blog, the most important parts of the guidance document are the advice on security and securing “wireless signals and data”. Section 3.d covers this…

Security of RF wireless technology is a means to prevent unauthorized access to patient data or hospital networks and to ensure that information and data received by a device are intended for that device. Authentication and wireless encryption play vital roles in an effective wireless security scheme. While most wireless technologies have encryption schemes available, wireless encryption might need to be enabled and assessed for adequacy for the medical device’s intended use. In addition, the security measures should be well coordinated among the medical device components, accessories, and system, and as needed, with a host wireless network. Security management should also consider that certain wireless technologies incorporate sensing of like technologies and attempt to make automatic connections to quickly assemble and use a network (e.g., a discovery mode such as that available in Bluetooth™ communications). For certain types of wireless medical devices, this kind of discovery mode could pose safety and effectiveness concerns, for example, where automatic connections might allow unintended remote control of the medical device. 

FDA recommends that wireless medical devices utilize wireless protection (e.g., wireless encryption,6 data access controls, secrecy of the “keys” used to secure messages) at a level appropriate for the risks presented by the medical device, its environment of use, the type and probability of the risks to which it is exposed, and the probable risks to patients from a security breach. FDA recommends that the following factors be considered during your device design and development: 

* Protection against unauthorized wireless access to device data and control. This should include protocols that maintain the security of the communications while avoiding known shortcomings of existing older protocols (such as Wired Equivalent Privacy (WEP)). 

* Software protections for control of the wireless data transmission and protection against unauthorized access. 

Use of the latest up-to-date wireless encryption is encouraged. Any potential issues should be addressed either through appropriate justification of the risks based on your device’s intended use or through appropriate design verification and validation.

Based upon the parts I’ve highlighted above, you’ll probably be feeling a little foreboding. From a “guidance” perspective, it’s less useful than a teenager with a CISSP qualification. The instructions are so general as to be useless.

If I was the geek charged with waving the security batton at some medical device manufacturer I wouldn’t be happy at all. Effectively the FDA are saying “there are a number of security risks with wireless technologies, here are some things you could think about doing, hope that helps.” Even if you followed all this advice, the FDA could turn around later during your submission for certification and say you did it wrong…

The second document the FDA released last week (Content of Premarket Submissions for Management of Cybersecurity in Medical Devices – Draft Guidance for Industry and Food and Drug Administration Staff) is a little more helpful – at the very least they’re talking about “cybersecurity” and there’s a little more meat for your CISSP folks to chew upon (in fact parts of it read like they’ve been copy-pasted right out of a CISSP training manual).

This guidance has been developed by the FDA to assist industry by identifying issues related to cybersecurity that manufacturers should consider in preparing premarket submissions for medical devices. The need for effective cybersecurity to assure medical device functionality has become more important with the increasing use of wireless, Internet- and network-connected devices, and the frequent electronic exchange of medical device-related health information.

Again, it doesn’t go in to any real detail of what device manufacturers should or shouldn’t be doing, but it does set the scene for understanding the scope of part of the threat.

If I was an executive at one of the medical device manufacturers confronted with these FDA Guidance documents for the first time, I wouldn’t feel particularly comforted by them – in fact I’d be more worried about the increased exposure I would have in the future. If a future product of mine was to get hacked, regardless of how close I thought I was following the FDA guidance, I’d be pretty sure that the FDA could turn around and say that I wasn’t really in compliance.

With that in mind, let me slip on my IOActive CTO hat and clearly state that I’d recommend any medical device manufacturer that doesn’t want to get bitten in the future for failing to follow this FDA “guidance” reach out to a qualified security consulting company to get advice on (and to assess) the security of current and future product lines prior to release.

Engaging with a bunch of third-party experts isn’t just a CYA proposition for your company. Bringing to bear an external (impartial) security authority would obviously add extra weight to the approval process; proving the companies technical diligence, and working “above and beyond” the security checkbox of the FDA guidelines. Just as importantly though, securing wireless technologies against today’s and tomorrow’s threats isn’t something that can be done by an internal team (or a flock of CISSP’s) – you really do need to call in the experts with a hackers-eye for security… Ideally a company with a pedigree in cutting-edge security research, and I know just who to call…

INSIGHTS | August 5, 2013

Car Hacking: The Content

By Chris Valasek & Charlie Miller
Hi Everyone, 
As promised, Charlie and I are releasing all of our tools and data, along with our white paper. We hope that these items will help others get involved in automotive security research. The paper is pretty refined but the tools are a snapshot of what we had. There are probably some things that are deprecated or do not work, but things like ECOMCat and ecomcat_api should really be all you need to start with your projects. Thanks again for all the support! 
 
Content: http://illmatics.com/content.zip

 

INSIGHTS | July 25, 2013

Las Vegas 2013

By IOActive
Again, that time of the year is approaching; thousands of people from the security community are preparing to head to Las Vegas for the most important hacking events: Black Hat USA and DefCon. IOActive will (as we do every year) have an important presence at these conferences.

We have some great researchers from our team presenting at Black Hat USA and DefCon. At Black Hat USA, Barnaby Jack will be presenting “Implantable medical devices: hacking humans”, and Lucas Apa and Carlos Mario Panagos will be presenting “Compromising industrial facilities from 40 miles away”. At DefCon, Chris Valasek will be presenting “Adventures in automotive networks and control units”.
These will be probably the most commented on talks, so don’t miss them!
During Black Hat USA, IOActive will also be hosting IOAsis. This event gives you an opportunity to meet our researchers, listen to some interesting presentations, participate in a hacking hardware workshop, and more—all while enjoying great drinks, food, and a massage.

 

Also back by popular demand and for the third time in a row, IOActive will be sponsoring and hosting Barcon. This is an invitation-only event where our top, l33t, sexy (maybe not ) researchers meet to drink and talk.

 

Lastly (but not least important), we are once again hosting “Freakshow”, our popular and greatest DefCon party, on Saturday, August 3rd at 9am at The Rio pools.

 

For your convenience, here are the details on our talks at Black Hat USA and DefCon:

 

IMPLANTABLE MEDICAL DEVICES: HACKING HUMANS
Who: Barnaby Jack
Where & When: Black Hat USA, August 1st, 2:15pm

 

In 2006, approximately 350,000 pacemakers and 173,000 ICD’s (Implantable Cardioverter Defibrillators) were implanted in the US alone. 2006 was an important year; this is when the FDA began approving fully wireless-based devices. Today there are well over 3 million pacemakers and over 1.7 million ICDs in use.
In this talk, I will focus on the security of wireless implantable medical devices and discuss how these devices operate and communicate and the security shortcomings of the current protocols. I will reveal IOActive’s internal research software that uses a common bedside transmitter to scan for and interrogate individual medical implants. Finally, I will discuss techniques that manufacturers can implement to improve the security of these devices.

 

COMPROMISING INDUSTRIAL FACILITIES FROM 40 MILES AWAY
Who: Lucas Apa and Carlos Mario Panagos
Where & When: Black Hat USA, August 1st, 3:30pm

 

The evolution of wireless technologies has allowed industrial automation and control systems (IACS) to become strategic assets for companies that rely on processing plants and facilities in industries such as energy production, oil, gas, water, utilities, refining, and petrochemical distribution and processing. Effective wireless sensor networks have enabled these companies to reduce implementation, maintenance, and equipment costs and enhance personal safety by enabling new topologies for remote monitoring and administration in hazardous locations.
However, the manner in which sensor networks handle and control cryptographic keys is very different from the way in which they are handled in traditional business networks. Sensor networks involve large numbers of sensor nodes with limited hardware capabilities, so the distribution and revocation of keys is not a trivial task.
In this presentation, we will review the most commonly implemented key distribution schemes, their weaknesses, and how vendors can more effectively align their designs with key distribution solutions. We will also demonstrate some attacks that exploit key distribution vulnerabilities, which we recently discovered in every wireless device developed over the past few years by three leading industrial wireless automation solution providers. These devices are widely used by many energy, oil, water, nuclear, natural gas, and refined petroleum companies.
An untrusted user or group within a 40-mile range could read from and inject data into these devices using radio frequency (RF) transceivers. A remotely and wirelessly exploitable memory corruption bug could disable all the sensor nodes and forever shut down an entire facility. When sensors and transmitters are attacked, remote sensor measurements on which critical decisions are made can be modified. This can lead to unexpected, harmful, and dangerous consequences.

 

Adventures in Automotive Networks and Control Units
Who: Chris Valasek
Where & When: DefCon, August 2nd, 10:00am
Automotive computers, or Electronic Control Units (ECU), were originally introduced to help with fuel efficiency and emissions problems of the 1970s but evolved into integral parts of in-car entertainment, safety controls, and enhanced automotive functionality.
In this presentation, I will examine some controls in two modern automobiles from a security researcher’s point of view. I will first cover the requisite tools and software needed to analyze a Controller Area Network (CAN) bus. I will also demo software to show how data can be read and written to the CAN bus. Then I will show how certain proprietary messages can be replayed by a device hooked up to an ODB-II connection to perform critical car functionality, such as braking and steering. Finally, I will discuss aspects of reading and modifying the firmware of ECUs installed in today’s modern automobile.

 

INSIGHTS | July 24, 2013

DefCon 21 Preview

By Chris Valasek
Hi Internet!
You may have heard that Charlie Miller (@0xcharlie) and I (@nudehaberdasher) will present a car hacking presentation at DefCon 21 on Friday, August 2 at 10:00am.
“Adventures in Automotive Networks and Control Units” (Track 3)
(https://www.defcon.org/html/defcon-21/dc-21-schedule.html)
I wanted to put up a blog explaining what exactly we’ll be talking about in a bit more detail than was provided in the abstract. Our abstract was purposefully vague because we weren’t really sure what we were going to release at the time of submission, but obviously have a much more concrete set of items now.

Also we wanted to remind everyone that although we did not focus on remote attack vectors, intricate knowledge of a car’s internals / CAN network would be necessary after remotely compromising the vehicle for any amount of control (steering, braking, acceleration, etc).
Talking points
  1.  We will briefly discuss the ISO / Protocol standards that our two automobiles used to communicate on the CAN bus, also providing a Python and C API that can be used to replicate our work. The API is pretty generic so it can easily be modified to work with other makes / models.
  2.  The first type of CAN traffic we’ll discuss is diagnostic CAN messages. These types of message are usually used by mechanics to diagnose problems within the automotive network, sensors, and actuators. Although meant for maintenance, we’ll show how some of these messages can be used to physically control the automobile under certain conditions.
  3.  The second type of CAN data we’ll talk about is normal CAN traffic that the car regularly produces. These types of CAN messages are much more abundant but more difficult to reverse engineer and categorize (i.e. proprietary messages). Although time consuming, we’ll show how these messages, when played on the CAN network, have control over the most safety critical features of the automobile.
  4.  Finally we’ll talk about modifying the firmware and using the proprietary re-flashing processes used for each of our vehicles. Firmware modification is most likely necessary for any sort of persistence when attempting to permanently modify an automobile’s behavior. It will also show just how different this process is for each make/model, proving that ‘just ask the tuning community’ is not a viable option a majority of the time.
So there you have it. While we are NOT covering any remote attack vectors/exploits, we will be releasing documentation, code, tools, sample traffic from each vehicle, and more. At the very least you will be able to recreate our results, and with a little work should be able to start hacking your own car!
Make sure you come by DefCon Friday morning at 10am to see our talk. We promise that it will be worth getting up that early (or staying up through the night). Also, please keep checking back as we’ll post our paper, slides, code, and videos after DefCon.

P.S. If you’re lucky, you too can completely brick your car!

INSIGHTS | July 16, 2013

2013 ISS Conference, Prague

By Lucas Lundgren
I had the opportunity to attend the 2013 ISS conference in Prague a few weeks ago. The conference is a place where company representatives and law enforcement (and other government agency) officials can meet to share ideas and products information (such as appliances). Even though I had a sore throat, I still found it quite interesting; although not necessarily in terms of the products and presentations – which I felt was overall a bit flat.

It was easy to differentiate between company representatives and government officials. Government officials wore yellow ID tags, while company representatives wore purple ID tags. These tags stated the individual’s first and last name and the company or government agency they represented.

I didn’t know what to expect, because I had never been to an ISS conference. However, I quickly realized that the conference itself could be an attacker’s paradise. For example, one could easily use a camera phone to take undetected photographs of the various government officials.

Being inquisitive by nature, I decided to conduct an experiment. First, I turned my ID tag (which I was supposed to visibly wear around my neck at all times) backwards so that nobody could see who I was. Even with hotel security guards stationed at all entrances, nobody stopped me or checked my badge.

This is an attack scenario in and of itself. My only interaction with a security guard occurred when I tried to take a shortcut to exit the conference—but even then, I was not asked to show my badge.

The first day had many presentations given. I attended a few of these but found that they were not particularly interesting. A law enforcement official illustrated how to find and check EXIF data in pictures. I asked a question relating to a page with “right-click” protection on. He answered by saying that they needed a third-party program (an open source one) to download the page. I was baffled and wondered what ever happened to “View Source”, which exists in most browsers. What about blocking JavaScript? What happened to File > Save As? This disturbed me, but not as much as what happened later on in the day.

Some of the presentations required a yellow (government) ID tag to attend. With security guards stationed outside of each presentation, I wanted to see if I could successfully enter any of these. I used a yellow piece of paper, borrowed the hotel printer to create a new ID tag, and wrote my name as Mr. Sauron Chief of Security, Country of Mordor. Just like that! I smiled, nodded, and entered the presentation as a yellow-badged participant. To be clear, the presentation had not yet begun, so I quickly exited after a minute or two.

Later in the day, I attended a presentation on TOR, Darknet, and so on. During the presentation, I overheard a number of yellow-badged participants indicating they had never heard of TOR. As the presentation went on, I had a general feeling that the presenter viewed TOR as a safe way to stay anonymous. However, I see it as a network by which attackers can obtain a substantial amount of data (usernames, passwords, credentials, and so on) after setting up their own TOR networks.

There were problems with Wi-Fi access at the hotel. Guests had to pay, for example, 80 Euros per day for a 1MB line (per day). No cables and wiring had been set up beforehand for attendees, so technicians were busy setting these up during the conference. I found this to be a bit dangerous.

When I checked the wireless network, I found that the hotel had a “free” access point to which I quickly connected. I found it ironic, being at an ISS conference, that the hotel used insecure items such as clear text as part of their free connection!

If you happen to represent law enforcement in your country, do not (I repeat, DO NOT)…
  • Connect to anything anywhere in the area,
  • Accept invalid SSL certificates,
  • Use your Viber or What’s Up messenger to send messages (clear text protocols),
  • Use non-encrypted protocols to check your email,
  • Publicly display your name and the agency you represent unless asked to do so by a security representative wearing the proper badge

 

The same rules that apply to the Defcon and Blackhat conferences should apply at the ISS conference—or any security conference for that matter!

If I had been an evil attacker at the ISS conference, I could have easily sat in the lounge downstairs all day and overheard all kinds of conversations about products, firewalls, and solutions used by a variety of countries. Also, by simply using the “free” hotel Wi-Fi, I could have gained access to a number of participant email messages, text messages, and web pages sending username and password credentials in clear text. Imagine what I could have done with a hotel voucher containing a locked account!

A colleague of mine attending the conference decided to perform a quick experiment using the SSLstrip tool to test for hotel network vulnerabilities. Moxie Marlinspike introduced this tool at the Black Hat DC 2009 conference to demonstrate how attackers can perform HTTP stripping attacks. SSLstrip prompts users to use an invalid certificate, which they can accept or reject. Much to our surprise, ISS conference participants accepted our invalid certificate. My colleague and I were completely baffled and blown away by this! I would like to note that we were not performing this experiment for malicious reasons. We simply wanted to verify the network vulnerability at the conference and provide our feedback to ISS conference and hotel stakeholders in this blog.

Using a tool similar to SSLstrip, an attacker would not even have to enter the main conference area to perform attacks. He could sit back in the smoker’s lounge, order a beverage of choice, set up sniffing, lean back on the couch, and let participants do the rest of the work!
Don’t get me wrong. The conference offered a lot of interesting topics and presentations. Someone presented a board equipped with Bluetooth, wireless, and a 3g module (for listening to calls) that had Linux as a base operating system. Anyone can buy this, not just government officials. The potential an attacker getting this into his hands is huge, and it is only the size of a Rasberry Pi.

Another security concern at the conference involved the use of Bluetooth and Wi-Fi. People everywhere were using the Internet on their phones and had Bluetooth activated. You have to ask yourself, would these be activated at a Blackhat conference?

It’s obvious that law enforcement and other governmental agencies need training with regard to the popular hacking techniques used at conferences. We encourage such agencies to contact us at IOActive for help in this arena.

 

Perhaps you are reading this blog post and realizing that you too have used free Wi-Fi to check email, turned Bluetooth/Wi-Fi on in public places, or accepted a faulty SSL certificate. Promise me one thing… at the next conference you attend make sure everything at the hotel is safe and turn Bluetooth/Wi-Fi off on your devices. Do not talk loudly about things that are supposed to be confidential Do so after the conference! Also, if you are an organizer at the next ISS conference, please be sure to properly check participant badges. Also, consider using something more secure than a paper ID tag with a name on it.
INSIGHTS | July 11, 2013

Why Vendor Openness Still Matters

By Mike Davis
When the zombies began rising from their graves in Montana it had already been over 30 days since IOActive had reported issues with Monroe Electronics DASDECS.
 
And while it turned out in the end that the actual attacks which caused the false EAS messages to be transmitted relied on the default password never having been changed, this would have been the ideal point to publicize that there was a known issue and that there was a firmware update available, or would soon be to address this and other problems… maybe a mitigation or two in the mean time right?

At a minimum it would have been an ideal time to provide the simple mitigation:
“rm ~/.ssh/authorized_keys”
 
Unfortunately this never happened, leading to a phenomena I like to call “admin droop”.  This is where an administrator, after discovering the details of a published vulnerability, determines that he’s not vulnerable because he doesn’t run the default configuration and everything is working and doesn’t bother to upgrade to the next version.
 
… it happens…
 
In the absence of reliable information other outlets such as the FCC provided pretty minimal advice about changing passwords and using firewalls; I simply commented to the media that this was “inadequate” advice.
 
Eventually, somewhere around April 24 Monroe, with the assistance of CERT begin contacting customers about a firmware fix, we provided a Shodan XML file with a few hundred vulnerable hosts to help track them down. Finally it looked like things were getting fixed but I was somewhat upset that I still had not seen official acknowledgement of the issue from Monroe but on June 13 Monroe finally published this https://www.ioactive.com/wp-content/uploads/2013/07/130604-Monroe-Security-PR.pdf 
security advisory where it stated “Removal of default SSH keys and a simplified user option to load new SSH keys”, ok its not much of an “announcement” but its something and  I know it says April 24, but both the filename and metadata (pdfinfo) point to cough later origins…
 
Inside the advisory is this wonderful sentence: 
“The company notes that most of its users already have obtained this update.”… That sound s like something worth testing!
 
Then it happened, before I could say “admin droop”… 
 
Found/Vulnerable hosts before we reported the issue:   222
Found hosts After the patch was released, as found by a survey on July  11:  412
 
Version numbers       
         Hosts Found
       Vulnerable (SSH Key)
1.8-5a
                1
                 Yes
1.8-6
                2
                 Yes
2.0-0
              110
                 Yes
2.0-0_a01
                1
                 Yes
2.0-1
               68           
                 Yes
2.0-2 (patched)
               50
                  No
unreachable                              180

While most users may have “obtained” the update, someone certainly didn’t bother applying it…
 
Yep… it’s worse now than it was before we reported the issue in January, and everyone thinks everything is just fine. While I’m sure this would still be a problem had a proper security notice been issued.
 
I can’t say it any better than these awesome folks over at Google http://googleonlinesecurity.blogspot.com/2013/05/disclosure-timeline-for-vulnerabilities.html : “Our standing recommendation is that companies should fix critical vulnerabilities within 60 days — or, if a fix is not possible, they should notify the public about the risk and offer workarounds.”

 

INSIGHTS | July 4, 2013

Why sanitize excessed equipment

By Reid Wightman

My passion for cybersecurity centers on industrial controllers–PLCs, RTUs, and the other “field devices.” These devices are the interface between the integrator (e.g., HMI systems, historians, and databases) and the process (e.g., sensors and actuators). Researching this equipment can be costly because PLCs and RTUs cost thousands of dollars. Fortunately, I have an ally: surplus resellers that sell used equipment.

I have been buying used equipment for a few years now. Equipment often arrives to me literally ripped from a factory floor or even a substation. Each controller typically contains a wealth of information about its origin. I can often learn a lot about a company from a piece of used equipment. Even decades-old control equipment has a lot of memory and keeps a long record about the previous owner’s process. It is possible to learn the “secret recipe” with just a few hours of work at reverse engineering a controller to collect company names, control system network layout, and production history. Even engineers’ names and contact information is likely to be stored in a controller’s log file. For a bad guy, the data could be useful for all sorts of purposes: social engineering employees, insider trading of company stock, and possibly direct attacks to the corporate network.
I reach out to the origin of used equipment when I find these types of information. I help them wipe the equipment, and I point them to where the rest of the equipment is being sold in an attempt to recall it before the stored information ends up in the wrong hands. I am not the only one doing this kind of work. Recently, Billy Rios and Terry McCorkle revealed surplus equipment that they had purchased from a hospital. It had much of the same information about its origin.

These situations can be prevented by sanitizing the equipment before it’s released for disposal. Many equipment manufacturers should be able to provide instructions for this process. One option may be to send the controller back to the manufacturer to be sanitized and refurbished.
A way to provide another layer of protection against information disclosure is to have a robust and well-practiced Incident Response plan. Most places that I contact are great to work with and are receptive to the information.

Ignoring the issue, especially where a public utility is concerned, may be considered a violation. Set up an Incident Response program now and make sure that your process control engineers know to send equipment disposal issues through the IR group.

 

A great deal can be accomplished to keep a control system secure. With a little planning, proper equipment disposal is one of the cheapest things that can be done to keep proprietary process information safe.
INSIGHTS | June 20, 2013

FDA Safety Communication for Medical Devices

By Gunter Ollmann
The US Food and Drug Agency (FDA) released an important safety communication targeted at medical device manufacturers, hospitals, medical device user facilities, health care IT and procurements staff, along with biomedical engineers in which they warn of risk of failure due to cyberattack – such as through malware or unauthorized access to configuration settings in medical devices and hospital networks.
Have you ever been to view a much anticipated movie based upon an exciting book you happened to have read when you were younger, only to be sorely disappointed by what the director finally pulled together on the big screen? Well that’s how I feel when I read this newest alert from the FDA. Actually it’s not even called an alert… it’s a “Safety Communication”… it’s analogous to Peter Jackson deciding that his own interpretation of JRR Tolkien’s ‘The Hobbit’ wasn’t really worthy of the title so to forestall criticism he named the movie ‘Some Dwarves and a Hobbit do Stuff’.
This particular alert (and I’m calling it an alert because I can’t lower myself to call it a safety communication any longer) is a long time coming. Almost a decade ago me and my teams at the time raised the red flag over the woeful security of hospital networks, then back in 2005 my then research teams raised new red flags related to the encroachment of unsecured WiFi in to medical equipment, for the last couple of years IOActive’s research team have been raising new red flags over the absence of security within implantable medical devices, and then on June 13th 2013 the FDA releases a much watered down alert where the primary recommendations and actions section simply states “[m]any medical devices contain configurable embedded computer systems that can be vulnerable to cybersecurity breaches”. It’s as if the hobbit has been interpreted as a midget with hairy feet.
Yes I joke a little, but I am very disappointed with the status of this alert covering an important topic.
The vulnerabilities being uncovered on a daily basis within hospital networks, medical equipment and implantable devices by professional security teams and researchers are generally more serious than what outsiders give credit. Much of the public cybersecurity discussion as it relates to the medical field to date has been about people hacking hospital data systems for patient records and, most recently, the threat of targeted slayings of people who happen to have vulnerable implanted insulin pumps and heart defibrillators. While both are certainly possible, they’re what I would associate with fringe events.
I believe that the biggest and most likely threats lie in non-malicious actors – the tinkerers, the cyber-crooks, and the “in the wrong place at the wrong time” events. These medical systems are so brittle that even the slightest knock or tire-kicking can cause them to fail. I’ll give you some examples:
  • Wireless heart and drug monitoring stations within emergency wards that have open WiFi connections; where anyone with an iPhone searching for an Internet connection can make an unauthenticated connection and have their web browser bring up the admin portal of the station.
  • Remote surgeon support and web camera interfaces used for emergency operations brought down by everyday botnet malware because someone happened to surf the web one day and hit the wrong site.
  • Internet auditing and scanning services run internationally and encountering medical devices connected directly to the Internet through routable IP addresses – being used as drop-boxes for file sharing groups (oblivious to the fact that it’s a medical device under their control).
  • Common WiFi and Bluetooth auditing tools (available for android smartphones and tablets) identifying medical devices during simple “war driving” exercises and leaving the discovered devices in a hung state.
  • Medial staff’s iPads without authentication or GeoIP-locking of hospital applications that “go missing” or are borrowed by kids and have applications (and games) installed from vendor markets that conflict with the use of the authorized applications.
  • NFC from smartphone’s and payment systems that can record, playback and interfere with the communications of implanted medical devices.
These are really just the day-to-day noise of an Internet connected life – but one that much of the medical industry is currently ill prepared to defend against. Against an experienced attacker or someone determined to cause harm – well, it’s as one sided as a lone hobbit versus the combined armies of Middle Earth.
I will give the alert some credit though, that did clarify a rather important point that may have been a stumbling block for many device vendors in the past:
“The FDA typically does not need to review or approve medical device software changes made solely to strengthen cybersecurity.”
IOActive’s experience when dealing with a multitude of vulnerable medical device manufacturers had often been disheartening in the past. A handful of manufacturers have made great strides in securing their devices and controlling software recently – and there has been a change in the hearts and minds over the last 6 months (pun intended) as more publicity has been drawn to the topic. The medical clients we’ve been working most closely with over recent months have made huge leaps in making their latest devices more secure, and their next generation of devices will be setting the standard for the industry for years to come.
In the meantime though, there’s a tremendous amount of work to be done. The FDA’s alert is significant. It is a formal recognition of the poor state of security within the industry – providing some preliminary guidance. It’s just not quite a call to arms I’d have liked to see after so many years – but I guess they don’t want to raise too much fear, nor the ire of vendors that could face long and costly FDA re‑evaluations of their technologies. Gandalf would be disappointed.
(BTW I actually liked Peter Jackson’s rendition of The Hobbit).
INSIGHTS | June 14, 2013

Red Team Testing: Debunking Myths and Setting Expectations

By Ian Amit
The term “cyber” seems to be overused in every corner of the information security industry. Now there is a new buzz phrase in computer security, “red team engagements.” Supposedly (to get “cyber” on you), you can have a red team test, and it will help move your organization in the correct “cyber direction.”
But what is red team testing really? And what is it not? In this post I’ll try to make some sense of this potent term.
The red team concept has been around for ages. It started as a military term for a team dedicated to simulating all of an enemy’s activities, including everything from methodology to doctrine, strategy, techniques, equipment, and behaviors. The red team was tasked with mastering how the adversary thinks and operates, and then executing the enemy’s strategies and tactics in the field. This allows your own forces to experience what it would be like to combat this enemy in real life − without the risk of getting injured or killed.
Fast forward 10-12 years and red teams are being used in civilian industry as well as in the military. In private industry, red teams simulate adversaries (not necessarily foreign armies) that could impact the organization. The adversary could be criminals vying to get your money, competitors trying to get their hands on your latest designs, or random attackers who want to exploit, destroy, or simply harm your organization. Their motivations can range from social activism, political strategy, financial gain, and so on.

When IOActive is asked to conduct a red team test, our main goal is to accurately and realistically simulate these types of adversaries. So the first, and probably most important, element of a red team test is to define the threat model:

·      Who is your adversary?
·      What are their motivations?
·      Which adversaries are you most afraid of? (This is usually any party that wants to put you out of business.)
Defining the threat model is crucial to the success of a red team engagement, because it determines the value your organization will get from the project.
After we articulate the threat model, the fun part of the engagement begins.
Fun? Yes, because in the real world most tests, such as penetration tests do not really depict a persistent adversary. Instead, engagements such as pen tests simulates specific strategies that a persistent adversary will use as part of an overall attack.
The red team engagement, on the other hand, includes all possible elements that an adversary might use in such an attack (which is why it is often referred to as “no scope” or “full scope” testing).
In this context, everything including your employees, your infrastructure, the physical office locations, your supply chain − that’s every third party you use as part of your ongoing operations  − and more. When developing attack scenarios for red team engagements, every element has to fit in perfectly.

Think of it as an “Ocean’s Eleven” type of attack that can include:

·      Social engineering
·      Electronic and digital attacks
·      Bypassing physical controls
·      Equipment tampering
·      Getting into the supply chain to access your assets
·      And more

This is full scope testing. Unlike in other types of engagement, all or almost all assets are “in scope”.

Note: Red team engagements do commonly use “reverse scoping” techniques to identify assets that are critical to operations and the types of tampering, access, or removal that are off limits for these assets. These sensitive assets are still in scope. But reverse scoping defines and restricts actions that may substantially disrupt operations.)
So far this sounds like a fun game. But hold on, it isn’t just about the attack. What I like the most is seeing how an organization’s ongoing security operations handle red team attacks.
In a red team test, very few people in the organization know about the test, and even fewer actually know when the test will happen. This means that from an operational security view, all red team activities are treated as if they involve a real adversary.

We gain a lot of insights from the actions and reactions of the organization’s security team to a red team attack. These are the types of insights that matter the most to us:

  • Observing how your monitoring capabilities function during the intelligence gathering phase. The results can be eye opening and provide tremendous value when assessing your security posture.
  • Measuring how your first (and second) responders in information security, HR, and physical security work together. Teamwork and coordination among teams is crucial and the assessment allows you to build processes that actually work.
  • Understanding what happens when an attacker gains access to your assets and starts to exfiltrate information or actually steals equipment. The red team experience can do wonders for your disaster recovery processes.
These are some of the rewards and benefits of a red team test. As you can see, they go well above and beyond what you would get from other types of focused tests.
I hope this explanation eliminates some of the confusion about red team testing that I have seen lately in Internet discussions. I am not saying that there is no value in pen tests, social engineering engagements, physical assessments, or anti-phishing campaign. However, to see how all of these different types of security considerations work in the real world, they also need to be considered as part of a larger (and relevant) context so that you can see how well your organization is prepared for any type of attack.
Last but not least, if you’d like to get hands-on training in how red team engagements are conducted, considering attending our two-day Red Team Training (https://www.blackhat.com/us-13/training/red-team-training.html) at BlackHat 2013 in Las Vegas.
Chris Nickerson and I will cover everything discussed in this post, with particular focus on the elements that go beyond penetration testing. Our topics will include lock picking, social engineering, physical assessments, and, most importantly, how to combine all of these elements into a realistic and successful simulation of an adversary. We also plan to give each of our students a very interesting goodie bag.
Hint: You’ll have fun walking through airport security with that bag :-).