Security Resources

Archive for the Hardware Hacking Category

Linux Worm Targets Embedded Devices

newsDark Reading (12/06/13) Chickowski, Ericka

A newly discovered Linux worm targeting embedded devices is the latest example of such attacks aimed at the Internet of Things. The Zollard worm was identified shortly before Thanksgiving by Symantec researchers, and targets a PHP vulnerability that was patched in May 2012, but remains in many older and unpatched embedded devices such as printers, conference call equipment, and security cameras, as well as network routers and switches. Such devices, which often run a basic version of Linux and remain freely accessible fro the Internet in their default configurations, are proving to be a vexing problem for enterprise information security. “They’re small enough that a lot of administrators forget they’re there and forget to patch them, change default passwords, and things like that,” says SecureState researcher Spencer McIntyre. Cisco researcher Craig Williams says these devices are easy targets for attacks that can be used to spread malware or serve as base to further infiltrate networks. Rapid7’s HD Moore expects to see a proliferation of botnets composed of compromised embedded devices in coming years. Williams says the best defense against attacks targeting embedded devices is network level protection, such as IDS systems that can identify and block attacks against vulnerabilities such as the one leveraged by Zollard.

Internet Scans Turn Up More Unsecured Hardware

warning

Vulnerable terminal servers reflect bigger security problem

April 26, 2013 — CSO — Security weaknesses uncovered in terminal servers used to provide an Internet connection to a wide variety of business and industrial equipment exemplify the risk inherent in adapting older systems to modern technology, experts say.

A recent study by the security firm Rapid7 found more than 114,000 terminal servers, mostly from Digi International or Lantronix, configured to let anyone gain access to the underlying systems. A terminals server, also called a network access server, makes any equipment with a serial port accessible through the Internet.

The systems found vulnerable to tampering included industrial control equipment, traffic signal monitors, fuel pumps, retail point-of-sale terminals and building automation equipment. A hacker scanning the Internet for the serial ports on these devices could easily use a command line program to gain administrative privileges and control the equipment.

Skimmer Innovation Coming to a POS Near You

Matt Krebs recently posted another entry to his detailed and entertaining catalog of skimming devices, available at Krebs on Security. The device in question was found inside the credit card terminals of a yet-to-be-named U.S. retailer, and is presently being evaluated by Trustwave Spiderlabs. By itself, this is not particularly newsworthy, since there have been many similar cases involving devices attached PIN pads at retailers like Barnes and Noble, as well skimmers on/inside gas pumps and ATMs. So what makes this one interesting? The engineering and installation are worth a closer look:

  • The stolen data is encrypted using AES before being stored/transmitted
  • Card numbers and PINs can be retrieved by Bluetooth, and optionally, via cellular
  • The microprocessor was secured against tampering (lock bit set)
  • The PCB appears to have been produced professionally
  • There was delicate soldering work required to attach the device inside the credit card terminal

There is [very reasonable] speculation that the skimming devices were installed either early in the card terminal supply chain, prior to installation, or that the terminals were swapped out at some point with modified versions. Given the complexity of the connections, it is highly unlikely that the devices could have been modified on-site, even by a dishonest service technician.

The quality of these devices is increasingly impressive, and it seems plausible that future versions will be integrated into replacement system boards or peripherals, making their identification even more difficult.

Here are some photos of the Bluetooth skimming module:

BTSkimmer1 BTSkimmer2

DVR Flaw Discovered – Swann, Lorex, Others Affected

RaySharp_DVRThe latest in a string of DVR and IP camera vulnerabilities was posted last week by a blogger using the pseudonym “someLuser” and affects an OEM design from RaySharp whose products are reportedly sold under a number of brand names, including Swann, Lorex, KGuard, Zmodo, Hi-View, Soyo, and others. These are often sold direct-to-consumer in kit form, bundled with several cameras and remote viewing software.

In the post, the blogger provided example scripts to demonstrate several exploitable weaknesses in the DVRs, including:

  • Unauthenticated access to the device configuration files
  • Ability to view usernames and passwords in clear text
  • Ability to execute system commands as root (after obtaining the passwords)

The security researchers at Rapid7 (who help maintain and distribute the Metasploit framework) attempted to determine the number and location of systems exposed to the Internet by searching for the devices’ web interface signatures. This effort identified over 58,000 unique IPs in over 150 countries running these vulnerable platforms – 19,000 of which were located in the U.S.  (A chart of the geographic distribution can be seen here)

As discussed previously, embedded systems are often found to have similar vulnerabilities, but are usually hidden by a firewall, limiting the ability of a hacker to locate or attack them. Since DVRs are routinely placed in DMZs or otherwise exposed to the Internet, their vulnerabilities are much easier to exploit. For devices inside the firewall that also communicate on a private LAN/WAN, the risks posed by insecure devices is potentially significant.

As of this writing, there are no known patches or updates that address the problem. Concerned users should consider removing the devices from their network, or disabling access via the Internet.

 

Technician Infects Control Systems via USB

dhs_logo_smIn the 4th quarter of 2012, the Industrial Control Systems (ICS) team within CERT responded to multiple instances of power plant and utility control systems being infected with malware. In at least two of these, featured in ICS-CERT Monitor articles, the use of infected USB drives was identified as the means of transmission. Both cases illustrate the need for rigid backup and removable device policies. In one, the drive was used as the sole method of backing up critical workstations, and the other involved a third-party technician unwittingly infecting equipment while updating software using a USB drive. An important reminder to all who service networked devices…

As discussed in previous posts (see Hardware Hacking category), vulnerabilities in equipment connected directly to the Internet are capturing most of the attention these days. ICS-CERT recently summarized “Project SHINE,” which filtered and researched systems identified via the SHODAN search engine, looking for those most likely to control critical infrastructure. In the end, they determined that 7,200 devices (out of an initial list of more than 500,000) were directly related to control systems. With assistance from CERT, the group of researchers has been notifying owners about the potential exposure to attack, but this issue will be with us for a long time to come.

ICS-CERT also published a summary of the incidents by sector for 2012:

ICS-CERT Incidents by Sector 2012

————–

Additional Information about SHINE:  “SHINE stands for SHodan INtelligence Extraction. Managed by Bob Radvanovsky and Jake Brodsky of InfraCritical, it is a project to locate probable sites where control systems hardware may be running openly (without encryption or authentication of any sort) on the Internet. These include everything from hospital patient monitoring systems, building automation, Distribution SCADA RTUs, PLC gear, smart meters, traffic control systems, point of sale systems, security and fire alarm systems, and so on.”

The Shodan search engine can be found here.

Printer Backdoor Found – Lessons for Security Equipment Manufacturers

As reported by Parity News and others, certain Samsung printers (as well as some Dell printers manufactured by Samsung) have been found to contain a hardcoded SNMP “community string” with administrative privileges that remains active even when SNMP is turned off. This could allow a remote attacker to take control of the device, and potentially use it to launch attacks or otherwise compromise the integrity of the printer and network. This type of vulnerability has been seen in copy machines and printers before, but it is a reminder that unused or undocumented capabilities in network devices can be a very weak link.

Consider the multitude of IP cameras, some of which have already been shown to contain similar weaknesses, then add the growing range of network-enabled alarm panels, access control devices, DVR/NVRs, and EAS pedestals. Even large manufacturers who have deep expertise in network security are not immune, as the Samsung story illustrates, so as an industry we will need to partner closely with IT to add layers of protection where they make sense. Some of the precautions insisted upon by experienced CIO/CSOs, like network isolation and port/IP filtering, will need to make their way down into smaller deployments to reduce the chances of a flaw being exploited. Integrators are wise to take these potential threats seriously when designing a system.

Here is the US-CERT Vulnerability Report

DVR and IP Camera Hacking – Only the Beginning

There have been a number of articles and proof-of-concept hacks in recent years illustrating vulnerabilities in IP camera software, access control systems, and the like. Some have raised awareness about fundamental flaws in technology – like the relative insecurity of common proximity card readers, unprotected programming access to a locking system, and simple methods to access a camera’s video feed. Most of the attention following these announcements is focused on the ability of a device to be bypassed or viewed (in the case of a camera), which misses a critical point.

While it is concerning that a replay attack can spoof an access card, and that an IP camera may not provide adequate security against unauthorized viewing, the real danger lies in the potential of these systems to be hacked and modified to serve some other purpose. Here are a few examples – and a prediction: We will see one or more of these in the wild within 24 months.

Scenario One:  The IP Camera Worm
Many IP cameras are designed using FPGAs, not microprocessors, so their ability to run arbitrary code is limited. This trend is changing, however, and as cameras adopt a more standards-based architecture, they will become powerful edge devices running operating systems that can be attacked like any other. Some higher-end models can already run cron scripts, handle video analytics, and manage local storage of data. They are, without exaggeration, computers with a lens and network connection. They are also commonly thought of as “appliances,” with a plug-and-play approach applied to many projects. It is feasible that a worm or other malware could infect these devices as early as the point of manufacturing, or when they are plugged into the installer’s laptop for programming. The software might lie dormant or attempt to infect other cameras or computers on the same network. Affected devices could even be used to launch a Denial of Service (DoS) attack against the recording server or some other target. The common practice – at least in larger systems – of segmenting cameras onto their own LAN might help to reduce this potential, but since the recording server is usually connected to other network(s) for remote viewing and administration, malware capable of infecting the server is a logical progression of this threat.

Scenario Two:  The surveillance DVR/NVR (Network Video Recorder) as a point of entry into corporate networks
Executives like video surveillance systems – and for good reason. As networks and video quality have improved, these systems have saved organizations tremendous amounts of money. Investigations can be performed more efficiently, guards can be reduced, travel costs can be cut, and the list goes on. This means, of course, that the video systems need to be accessible to various departments via the corporate network. Most implement some type of basic security, like requiring a remote user to connect over a VPN, but few have taken steps to totally isolate the video traffic from other network systems. Since many DVRs and NVRs are full-fledged PCs running Windows or Linux, they are vulnerable to the same kinds of attacks as any other server or workstation, but they are easily overlooked and could become a “zero-day” vulnerability or convenient back door into the network.

Scenario Three:  Unintended “Integration”
Every year, security hardware and software moves closer to delivering on the promise of interoperability. It has been a long road, and there are still miles to go, but today’s systems come equipped with protocols for a variety of devices, in order to enable integration. This means that building a “security network” within an enterprise often makes sense. To gain the full benefit from your systems, they need to be able to interact, and since capabilities are sure to be added later – anything that might need to share data ends up on the same segment. When industrial controllers, manufacturing equipment, or other critical systems make this list, the scene is set for security devices to be used as a launchpad for espionage or manipulation. It can seem logical to group these systems together – after all, the “security network” should be a safe place for any important devices, right?

So, why is a hack inevitable?
Fundamental to the problem is that these systems and devices are routinely installed without sufficient thought given to security, and without a plan for ongoing monitoring and maintenance. Furthermore, some of the latest features of alarm panels, home automation controllers, IP cameras and DVRs require Internet access or remote server connections just to function properly, opening a vector of attack that, again, is not well understood or monitored. This means that segmenting a network or “sandboxing” the application may not be an option unless the owner is willing to sacrifice functionality.

I realize that it is not much of a stretch to predict that a hackable device connected to a network might be used in a new and nefarious way… but let’s hope I’m just plain wrong.

 

For More:

DVRs are being targeted by hackers, says security expert – Article discussing vulnerabilities in consumer DVRs

Bypassing IP Camera Authentication (example)

OpenIPCam site, dedicated to hacking various cameras and the development of custom firmware

Widespread Industrial Controller Vulnerability

Digital Bond, a control system security consulting company, released information about a critical vulnerability in numerous programmable logic controllers (PLCs) and other hardware used to automate everything from motors to complex industrial processes. The affected software is known as the CoDeSys ladder logic system, from 3S Software Gmbh.  CoDeSys is used by 261 manufacturers of control equipment to execute programming and operate connected devices. Essentially, Digital Bond discovered that the software allows a remote connection without user authentication. They created Python scripts that take advantage of this lack of security and provide a method for execution of commands and gaining access to data on the devices.

This vulnerability could have major implications for public utilities, manufacturing plants, and anywhere else this type of valve, motor, and system control is used. Of particular concern are controllers that are exposed on the Internet, but even systems behind a firewall are likely to be targeted, given the nature of the weakness and the simplicity of the exploit.

More information about Digital Bond’s findings and the Python scripts can be found here.

The U.S. ICS-CERT issued an alert as a result of the above, and Matt Krebs wrote an informative blog post that expands on the issue. In it, he notes that the availability of online search tools that scrape the Internet looking for all types of connected devices (including PLCs) make this problem even more serious. It appears, at present, that even the most novice hacker could launch an attack on exposed controllers, possibly causing severe damage or disruption of service.

At least for now, it would be prudent to isolate these devices – especially in cases where they control critical processes/equipment. Of course, it would be nice to think such measures were already in place for such important applications – but we know better.

RFID and Zigbee Hacking – Security Directors Beware…

In the security world, few technologies have become more entrenched than proximity-based access control. The cards and readers are everywhere – and overall, they provide a level of convenience and security that far exceeds the systems they replaced, such as mechanical locks, barcodes, magnetic stripes, and the like. A typical access card operates in the same manner as an RFID tag – since it is essentially the same thing. A reader emits RF energy, which energizes a coil inside the card powering a small circuit, which in turn, communicates a unique ID number back to the reader. There are many data formats and matched reader/card frequencies involved, but almost all systems operate in this (simplified) manner.

Over the years, there have been many documented examples of proximity access control hacking. From card emulation and brute-force transmissions at the reader, to surreptitious card data capture. So with that in mind, why revisit the subject here? The answer lies in the proliferation and rapidly declining cost of RFID components and other low-energy RF communications, which are poised to transform the way in which we connect and interact with systems and assets of all types.

The growing popularity of RFID tagging (especially in retail), environmental monitoring, intelligent edge devices, and building automation has spurred the development of a wide range of wireless/RF-enabled data collection and triggering. Examples include Zigbee (and similar 802.15.4 products), advanced RFID readers, and Z-Wave. For some developers, security is an afterthought, since the equipment is believed to be so obscure and/or specialized that it is unlikely to be attacked. What we are beginning to see, however, is that the same tactics used by “war-drivers” in the early days of commercial WiFi can expose insecure platforms and potentially open the door (pun intended) to serious security problems.

The good news is that security can be engineered into most of these platforms – in fact, it is often a core component – but it must be “switched on” and used properly. Follow the links below to read about some of the vulnerabilities and hacks that exist today. In practice, being aware of the potential for hacking – especially with immature products, proximity cards, etc… will help you make good design decisions. For example, once you understand how an access badge can be cloned – you probably won’t allow that badge to also disarm your alarm system, even if the vendor promotes it as a convenience feature. Likewise, if you are testing a new Zigbee-based data collection solution in your retail store, have a discussion with your vendor about how security has been implemented – and even if you like the answer, keep that network isolated until it is well-proven.

More on this subject:

Wardriving for Zigbee: Blog article describing a method for finding and mapping Zigbee networks

Kisbee: Open-source hardware project to capture Zigbee wireless communication

Bootable RFID Live Hacking System: A platform for hacking MIFARE access control cards

Proximity Card Cloning: HID ProxCard-II, ISOProx, and others

iClass Card Details and Cloning

RFID Tutorial

Long Range Cloning: 125KHz Proximity Cards

Barnes & Noble PIN Pads “Hacked”

Barnes and Noble reported today that PIN pads at their registers had been tampered with at 63 stores across nine states.

Even though only one pad per store was compromised, this clearly represents an organized effort to target the chain. B&N has advised customers to change their PIN numbers, and keep a watchful eye for fraudulent charges on cards used at their stores. At this time, the retailer reports that the perpetrator(s) did not gain access to their customer database, and that online/mobile transactions are secure.

All existing PIN pads were disconnected on September 14th until the situation could be addressed.

Some POS vendors have begun supervising the connection between the PIN pad and POS terminal in an effort to detect device substitution. It will be interesting to learn more about the approach used here, and whether such a feature would have prevented the hack. The official statement references a “bug” being placed in the devices, but it is unclear whether the bugs were installed “hot” in the field, or if the PIN pads were swapped out with matching devices that were modified elsewhere.

Here is the company’s press release.

Page 1 of 212