eEye Digital Security
Vice Newsletter - March 1, 2005
On behalf of the eEye Research team, welcome to the premiere edition of VICE, a free email newsletter featuring content from the team representing the foundation of eEye as a company and culture. VICE complements our VERSA newsletter, which highlights trends and news in the network security industry and delivers articles on the technical issues impacting network security professionals.
In contrast, the contributing authors of VICE are asked not to refrain from providing technical details –- including source code and specific methods -- related to their recent research, interests, or whatever they choose to disclose. In doing so, eEye now presents a collaborative publication that is meant to captivate the segment of our audience that strives to understand the technical aspects of information security and those who are not intimidated by electronic schematics and assembly code. Hence the choice of names: VICE and VERSA, like yin and yang, pair related but fundamentally opposing themes and together they comprise a whole. Now, with VICE and VERSA eEye has a monthly written voice that caters to network security professionals and researchers alike.
VICE will be released monthly with content from eEye's engineering team related to current interests, projects, and/or network security research. As editor, I have set forth just one requirement, and that is that the authors will have the freedom to choose their own topics. This open environment should promise regular content written with a passion lacking in "forced" journalism.
Enjoy!
Christopher Imes, Editor
In This Issue
| 1. | ||
| • | Exploiting ARM/RTOS-Based Embedded Systems Using the JTAG Emulator | |
| 2. | ||
| • | Client Side Hacking: Automated Client File Fuzzing | |
| 3. | ||
| • | What should I know about trojans? | |
| 4. | ||
| • | New Whitepaper: Remote Windows Kernel Exploitation - Step Into the Ring 0 | |
| • | Career Opportunity: Junior Security Researcher | |
Vulnerability Exposed!
Exploiting ARM/RTOS-Based Embedded Systems Using the JTAG Emulator
Real Time Operating Systems (RTOS) are used in mobile communication devices, household appliances, and even control devices for cars. In this paper, I will describe basic techniques used to exploit vulnerabilities in RTOS systems using a JTAG emulator.
Base Environment for Most Embedded Systems
The firmware for most embedded systems is based on the real-time operating system (RTOS). Many appliances used by the public have built-in networking features based on TCP/IP. Some of these RTOSes are thread-based, such as VxWorks and Micro-ITRON, and are generally used because they have better speed/memory performance, in comparison to process-based real-time OSes such as RT-Linux and QNX. In the case of thread-based RTOSes, to gain better performance, the memory space for each task is not independent, and system calls which would typically be provided by a kernel are instead implemented as C functions.
The majority of embedded systems use different kinds of MPUs (Microprocessor Unit) in order to reduce the amount of power consumed. Currently, the ARM [1] core MPU is the most widely-used in embedded systems such as routers, wireless LAN chips, cell phones, digital cameras, many kinds of household appliances, cars, and so on.
We will describe exploitation techniques for network appliances built on thread-based RTOSes with the ARM core MPU system.
Debugging
To construct a successful machine code injection exploit, such as the exploitation of a buffer overflow bug, we must analyze the contents of memory and registers at the time the bug occurs. In the case of exploitation for an embedded system that lacks a special debugging interface, we must connect some kind of external debugging hardware to the target system. In the development of an embedded system, the JTAG emulator is usually used.
The JTAG emulator is a type of hardware-based in-circuit emulator (ICE) that emulates the target device's MPU and memory, so that we can debug running firmware on the system efficiently. It can be controlled from a connected PC, so that we can use a debugging UI that facilitates dumping memory and registers, breaking, single-stepping, etc. You can get a JTAG emulator and the accompanying debugger software from some equipment makers. We used the "UniSTAC II/J" JTAG emulator for ARM7 provided by Sophia-Systems Inc [2]. It can be connected to a Windows PC via USB, and we can use the GUI-based debugger "Watch Point" which is bundled with the package. We show a screen shot in Fig. 1.
Fig. 1
Most MPUs for embedded systems feature an interface for connecting a JTAG emulator. In Fig. 2, we show an example of a JTAG interface on the ARM-based MPU "Samsung S3C4510B" [2], which is widely used for home routers. In many cases, we can get detailed information about the JTAG interface for this kind of general-purpose MPU at the chip vendor's website.
To connect the JTAG emulator, we must connect wires to the JTAG pins on the MPU and attach a standard JTAG emulator interface connector. We show one of these standard interfaces, called a "Multi-ICE interface", in Fig.3. The JTAG pins on the actual device are usually not used, so we can remove these pins to apply the solder and connect the wires (an example of this is shown in Fig. 4 and Fig. 5). You should note that, in the case of most MPUs, you must put some resistors and condensers between the JTAG connector and JTAG pins. You can get the circuit diagram to make a connector in the manuals for most MPUs, which are published at chip vendor's website.
Fig. 2 Fig. 3
Fig. 4 Fig. 5
We need to do some detailed work to make a JTAG port for most commercially-available devices. However, there are some embedded devices that feature an actual JTAG connector which was used during the development phase. We show an example in Fig. 6. This JTAG connector is small and has a non-standard shape, so we cannot connect the JTAG directly; however, the pin layout is same as for the Multi-ICE interface shown in Fig.2, so we can connect the JTAG emulator and debug the target using the hand-made converter shown in Fig. 7.
Fig. 6 Fig. 7
Buffer Overflow Exploitation in Embedded Systems
The conditions for exploitation of an embedded system are: (1) There is a buffer overflow bug which is actually exploitable. (2) We can see the model number of the MPU, and we can download or get the application notes for this MPU. (3) We can analyze the memory and registers using some kind of debugging method, such as a JTAG emulator. (4) We can use integrated on-chip functions like an Ethernet controller, flash memory, I/O, etc., in our shellcode.
If a regular stack-based buffer overflow occurs, then the instruction pointer will change to the address specified in the payload. For instance, if we put lot of 0x04 bytes into the buffer which will overflow, the instruction pointer will become 0x04040404. So, we can determine whether a regular stack-based buffer overflow happens or not if we put a breakpoint at 0x04040404. We show an example of the results of a network device which has experienced a buffer overflow condition in Fig. 8. The R15 register, which is the instruction pointer, is shown as 0x04040404.
Fig. 8
The shellcode should be coded using machine language, as it will be sent in the payload and executed on the target system. For general operating systems such as Windows or Linux, we can use various kinds of system calls in the shellcode, so it is very easy to show the actual risk of vulnerability. However, in case of a thread-based RTOS, it is difficult to use system calls and useful library functions such as standard socket APIs or C standard functions, because the entry point addresses of these APIs are usually system-dependent, and the implementations for them also depend on the kernel/middleware vendors.
So, it is hard to create shellcode that poses as serious a thread as what would typically be produced on a regular operating system, but it is not impossible. The majority of ARM-based MPUs for embedded systems have some extra features, such as an Ethernet controller, an image/video/sound processor, a flash memory controller, PCMCIA, UART, etc. Usually, chip vendors for this kind of MPU publish detailed information on them for potential users who must evaluate the features of the MPU. Thread-based RTOSes are basically single-state, so we can control the hardware directly via memory-mapped I/O from the regular task. It means that we can make shellcode which sends and receives IP packets if the target chip has an Ethernet controller and we can get usage information about it. If we can also control the flash memory, we might overwrite the firmware via the network. The information for the I/O memory map can also be obtained from the manuals for the target chip.
When developing shellcode, the 16-BIS (Bits per Instruction) mode is useful. The ARM MPU has two kinds of instruction modes, 32-BIS and 16-BIS. 32-BIS mode is usually used for devices which require high-speed processing. 16-BIS mode is used for producing more cost-efficient products because the size of the ROM can be reduced. In the case of 32-BIS mode, it is very difficult to remove null bytes (0x00) from the shellcode instructions. However, most 16-BIS mode instructions will not contain nulls, so we can also reduce the size of shellcode easily. The method for changing instruction modes is written in the ARM instruction manual provided ARM Inc.
Current Condition of This Research and Future Works
We have found buffer overflow bugs in some embedded systems. We could send our payload and execute it in a surveillance digital camera running a VxWorks RTOS using the ARM7TDMI core, based on the processes described in this paper. We will try to make some sample shellcodes for these appliances using the integrated on-chip functions of the MPU.
References
ARM, Inc.
Sophia-Systems UniSTAC II/J
Samsung S3C4510B
Source: Yuji Ukai, Senior Software Engineer, eEye Digital Security
Ask Research
Q: What should I know about trojans?
A: A trojan is an application designed in someway to take remote control of a system. For instance, some of the most popular trojans give the controller complete remote access to the system. Trojans can flip the screen, they can browse your file system as if it was their own, and they can log every site you surf and every key you press. There are a lot of different types of trojans, from the full fledged remote access capability ones to the extremely small and stealthy.
Typically, trojans end up on your system by being combined with additional binaries. For instance, a trojan can be combined with a piece of pirated software, and it compacted as a second program in an otherwise normal executable which, upon installation, separates from the original application and embeds itself into your system.
In a worst case scenario, a malicious attacker may use a security hole in one of your applications to install this trojan. For instance, they can run the application silently through a security hole in your IM, P2P, email, web browser, or server application. A seemingly innocent spam email could silently install a trojan while being read. While your IM client is left on, a remote attacker could connect to it and install a trojan. Once the remote attacker can run code of his choice on your system -- be it through by simply trojanizing binaries or by utilizing a known or unknown security flaw -- he can install a trojan which will continue to spy on you, day after day.
The most common motive for such is spying is mere curiosity. Attackers want to exert control over other people's systems. The second most common trojan attack motive is to install a trojan that works as a robot with other trojans so they can combine their network influence and issue a Distributed Denial of Service attack. This kind of trojan generally connects to a centralized messaging system such as IRC and can post your data there. But, the general purpose of the tool is merely to be one of hundreds or thousands of bots to be used by the attacker against the victim of his choice.
The more nefarious, but rarer usages of trojans may include: users spying on one another; users trying to exact revenge by gathering personal details; employees trying to gain unauthorized control; and corporate spies. Identity theft for financial gain can happen through trojans, and we may continue to see a large increase in this kind of crime.
Have a question you would like answered? Send it to vice@eeye.com, and win an eEye t-shirt if we select your question for an upcoming newsletter.
Etcetera
New Whitepaper: Remote Windows Kernel Exploitation - Step Into the Ring 0
Over eight years have passed and almost every possible method and technique regarding Windows exploitation has been discussed in depth. Surprisingly, a topic that has yet to be touched on publicly is the remote exploitation of Win32 kernel vulnerabilities; a number of kernel vulnerabilities have been published, yet no exploit code has surfaced in the public arena.
Career Opportunity: Junior Security Researcher
eEye Digital Security is looking for a junior research team member with a basic level of network security knowledge. Primary responsibilities will be to keep Retina's vulnerability detection robust and current. This is an opportunity to gain valuable experience in an exciting field surrounded by others that are highly motivated to help manage security threats.
How to Subscribe
To subscribe to this and other eEye newsletters, please visit: http://www.eeye.com/html/resources/newsletters/subscribe.html
Feedback
The eEye newsletter staff welcomes any comments, questions or suggestions from our readers. We hope that you will not hesitate to contact us with any feedback you may have. Send all feedback to vice@eeye.com.
Disclaimer
The information within this newsletter may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. Opinions expressed are not necessarily those of eEye Digital Security.
Notice
Permission is hereby granted for the redistribution of this newsletter electronically. It is not to be edited in any way without the express consent of eEye. If you wish to reprint the whole or any part of this newsletter in any other medium excluding electronic medium, please email vice@eeye.com for permission. Permission to reprint readers' comments or questions, and edit where necessary for length and clarity, is assumed unless explicitly forbidden.