Jump to content

(Embedded) Vulnerability Discovery Intro

Recommended Posts

An Introduction to (Embedded) Vulnerability Discovery 


- The 90's called, they want their bugs back - 


The Internet of Things is gaining momentum, more and more "things" are getting smart. However due to strong competition rapid product deployment is the main priority, security is not. Couple this with production lines which have moved to third-world countries, secure coding is often absent. This had led to interesting vulnerabilities: 


The bad: 

- Attackers taking over your router. Now they are in control of your network traffic

- Security camera's give an attacker a real-time view of your business or shower, err house


The ugly: 

- Car's can be remotely controlled (steering, acceleration, breaking)

- Aiming assistance on a firearm can be re-targeted or block the gun from shooting

- ATM's give you money .... without a valid card & pin

- Medical devices, might kill you ...


The root causes are varied but most devices suffer from: 

  • Design phase: limited security incorporated in the design. E.g. privilege separation (Oprah Winfrey voice: You get root, and you get root, everyone gets root)
  • Coding phase: lack of secure coding practices E.g. sending random chars to a device kills it.. (no input validation / mitigation: DEP, ASLR)
  • Operations phase: update difficulties (no central mechanism like Windows), malicious code detection, etc. 
Many devices share a code base or certain libraries. If a vulnerability is found multiple vendors and product ranges could be impacted.  


- The Methodology -

You can keep the same structure as for penetration testing however payload execution might be, and post-exploitation is, usually omitted. If you sell vulnerabilities there usually is a difference between an exploit and weaponized exploit. The former starts "calc" or a messagebox. The latter will contain a payload such as bind shell or account modification. So the methodology comes down to:

  1. Information Gathering
  2. Vulnerability Identification
  3. Exploitation

- The Discovery Process - 


This differs per tester however the following process works well for me:


01: Look for existing vulnerabilities in the product

Detect which parts have been covered by previous researchers, prevents duplicate bug reports. See what might have been overlooked.


02: Look for existing vulnerabilities in related products 

Check from the same vendor and vendors with a similar product. Often code and libraries are shared.


03: Are there new exploitation techniques?

Look if the device you test could be impacted by it. Keep an eye on exploit-db, packetstorm, Defcon / Blackhat / other sec. conferences.


04: Look at actual working versus intended working (especially when 3rd party code is integrated)

Sometimes a developer assumes a function will act in a particular way but when you look in the details there is some discrepancy which you might be able to abuse.


05: Perform entry point enumeration.

This means you look at all the different ways you can interact with the system. Any of these ways could lead to compromise. Common entry points: 

- Physical access (JTAG, USB and such)

- Network ports / services (wifi, eth, bluetooth, ftp, telnet, etc)

- Web GUI / API & SOAP calls

- Vendor supplied software

- Mobile app integration


Once discovered, look for “interesting” functionality and dig deeper to see if and how it could be exploited.


06: Use Attack Trees & Think Malicious

Attack Trees group together various vulnerability types, for example "Memory Errors" or "Cryptographic Weaknesses". These help you to think up new ways of compromising  a device and can help ensure your test is comprehensive. 


My main sources here are:

- MITRE Common Attack Pattern Enumeration and Classification (https://capec.mitre.org/) + OWASP. Used to focus on specific vulnerability types.

- Threat modeling + a Microsoft technique called "Stride". I use this while uncovering "interesting functionality". Stride is an acronym. It is used to determine if certain functionality might be vulnerable by looking for specific generic vulnerabilities:





Information Disclosure

Denial of Service

Elevation of Privilege 


Repudiation deals with logging. Can you influence logging in the product? For example disable it, attack an admin viewing the log, etc.)


- The Tools -

Some virtual machines as attack and host VM. I run Kali, Windows XP SP3 and Windows 7

Proxy: BurpSuite for web application testing

Debuggers: OllyDbg, Ida Pro, Windbg, gdb 

Metasploit Framework: creating payloads, assist in BoF exploitation

Portscanners: Nmap / Unicorn

Binwalk (Linux): to extract firmware images

Strings (also available for Windows): to search for specific text strings

Some hash calculator: validate file signatures

Wireshark: to intercept and look at network traffic

Colasoft Packet builder (Windows): to modify / replay network packets, Scapy could be used in Linux

Python / Ruby / Perl interpreters: for automation

To Add: network + file fuzzers, ActiveX auditing tools


- Real World Example 01 - 

Vendor: ProLink

Type: AP/Router

Version: PRN2001

Firmware: Ver 1.2


For this device I focused on web application penetration testing to find the majority of the vulnerabilities. The firmware image was partially extracted by Binwalk and allowed me to search for sensitive information with the Linux "strings" command. 



- Real World Example 02, Ongoing project - 


Vendor: Hikvision DVR

Type: Network DVR

Version: DS-7208HFI-SH

Firmware: Baseline NVR_V3.1.1 140314


Information Gathering


The device has various entry points:

- firmware image

- a web interface

- various network services

- a mobile App

- a Windows based password reset utility

- a software development kit (SDK)

- possibly an ActiveX control (I lost access to my device, I have to recheck)


Various public exploits exist which give you full control over a vulnerable device through a buffer overflow in the RTSP protocol. 


- Information Leak, Automatic Device Discovery - 

Today I had a look at the Password Reset utility for Windows. It has some anti-debugging inside so I need to take the ARES class :-) Dynamic analysis uncovered the following: after a straight forward installation the utility will run and automatically detect your Hikvision device. It will display the following device information:




A Wireshark capture shows two outgoing broadcast packets from the software, followed by two incoming replies from the Hikvision device. 


We isolated the two outgoing packets and placed them into ColaSoft Packet Builder. 




After starting Wireshark we replayed the two packets and received a valid reply from the device. 





Plain-text strings are visible in the returned packets which disclose device version information:


@@DS-7208HFI-SH0820131118AAWR441465660WCVU | @V2.2.8build 130730V5.0, build 1307292014-09-12 11:32:29HB

This maps to: 

Device-Type: DS-7208HFI-SH

Software Version: V2.2.8build 130730

Serial Number: DS-7208HFI-SH0820131118AAWR441465660WCVU

DSP Version: V5.0, build 130729

Start Time: 2014-09-12 11:32:29


As the reply contains all this information in plain-text we are now able to code a portable solution which can detect Hikvision devices, together with version information, on your LAN! We could code it in Python, because it is easy, or create an auxiliary module to use in Metasploit. [to do]


This a classic case of: CWE-200: Information Exposure / https://cwe.mitre.org/data/definitions/200.html 


- Future research: -


Other functionality offered by the utility:


Function 1: Device Configuration Change, protected by the admin password

Function 2: Device Password Reset, requires a unique string from Hikvision tech-support




We play with both functions and uncover the following:


Function 1 Device Config Change: 

- The maximum password size = 16

- The password is not sent in clear text


Function 2 Password Reset:

- The maximum string size = 25

- The security code is sent as clear text (01 string in sample below)




- Thinking Maliciously -


Function 1: 

Is the data obfuscated or encrypted and could we reverse this?

Can we bypass any password request limits? (not sure yet if the device locks after x invalid attempts)


Function 2: 

Could we replay the intercepted code and would it reset the password? 

Can we reverse engineer code on the embedded device to understand/break/reverse the encryption used?


Both functions: 

What if we replace values in the request or response packets? 

  • Can we crash the device or Windows software?
  • Could a crash lead to DoS or RCE?

IPv6 is supported, could this introduce a weakness?



Resources used:

- Google, a brain, coffee and beer to keep me on track


- eLearnSecurity: eCPPT Gold and Silver course content laid the foundation for my tinkering on the offensive side of security.


- Embedded Insecurity (the gun, the ATM, medical): 



- Embedded Security research: http://www.devttys0.com/



To be continued ... 


All errors are mine and unintentional. As always, I am not responsible for any misuse of this information and/or exploits, and blah blah blah.


  • Like 2

Share this post

Link to post

This is a really great post Herman. Thank you for sharing!

Share this post

Link to post

An introduction to Packet Analysis:


Did you ever take a close look at packets going over the network? No? Have a look, it is not that difficult.


I am looking at packets travelling between the embedded device and a Windows utility which can perform basic configuration tasks remotely. The software is installed in a Windows 7 x64 VM image.


The software has three separate functions which generate network packets. By comparing the different requests and replies we can determine how the custom protocol is implemented. 


This helps us:

- Parse packets with a custom script or software. For example print version or model strings.


- Fuzz the embedded device and Windows software

Intelligent fuzzing tries to maintain packet integrity and only fuzz specific sections. This improves the change of the packet being consumed instead of discarded.


- Tools Used: -





- Software Functions -

01: Device Discovery Broadcast: Request & Reply

02: Device Remote Configuration Change: Request & Reply

03: Device Password Reset: Request & Reply


In total we are able to examine six different packets.


- Broadcast Packets In Detail -

As we try to create a discovery utility this is the functionality we are currently most interested in.


The software generates the broadcast packet in various ways (analyzed with Wireshark):

- Automatically sent once software is started

- Repeated every 15 seconds after that

- Manually invoked by the refresh button


Decoding The Protocol: 

Sending and received is done on the Ethernet layer so we use MAC addressing. A custom protocol type is used 0x8033. The packet is 80 bytes big of which 66 bytes is a custom payload.


As observed in Wireshark: 

No.     Time        Source                Destination           Protocol Length Info
      1 0.000000    HonHaiPr_dc:a7:ad     Broadcast             0x8033   80     Ethernet II

Raw payload:

0000  21 01 01 42 00 00 1b 58 06 04 03 00 29 ae 1c 3e   !..B...X....)..>
0010  84 dc a7 ad c0 a8 01 c6 ff ff ff ff ff ff 00 00   ................
0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0040  00 00                                             .. 


The payload differs per packet but it seems to use a fixed header. When we compare a broadcast request and a broadcast reply we observe the following structure:


Static 6 bytes Packet Source
Dynamic 2 bytes Counter, increments
Static 4 bytes Packet Type
Dynamic 2 bytes Counter, decrements
-> More payload, dynamic, depends on packet type

How did we decode what the bytes stand for? 

We compare the packets and try to draw a conclusion based on the behavior we see: 


Packet Source: once a packet is sent from the software this value is: 21 01 01 42 00 00, when a reply is received from the embedded device the value is: 21 01 01 f6 00 00 


Packet Type: in a broadcast packet the request is set to 06 04 03 00 and the reply to 06 04 04 00. Other packets have a similar structure.


This behavior is observed over all six packets.


The broadcast reply is around 400 bytes so it is too big to discuss here. 

In raw output we can determine various strings relating to model version, etc. However in the software utility we also can see MAC and IP address information. 


By breaking down the packet we end up with a bunch of Hex data / strings. Converting these values uncovers the MAC and IP information. Now we can parse this with custom software or scripts, for example Metasploit.


- Now what? -

Create the discovery script


Test the software and embedded device for weaknesses: 


Broadcast Replay

A replay of any broadcast packet is accepted and replied to by Hikvision devices. Partial replies are discarded, I tried to cut off the packet at the various static values to see if we could cut down on network traffic.


Broadcast Reply Spoofing

I have yet to look into broadcast response structure. Replay of a valid response fails to spoof the software that is listening for a reply. Changing the MAC address to a Hikvision OUI did also not help to spoof a reply successfully. 


Fuzzing: DoS?



- Scripting The Discovery Packet -


Scripting the packet replay under Linux required some work :-) For Python, Google indicated raw socket support was implemented differently across major OS versions (Win vs Lin vs BSD), so I decided to start in Ruby as I would need to move all into Metasploit anyway.


In Ruby I wrote a quick and dirty script to put the packet on the wire (no error handling at all). With Wireshark I confirmed the format and received a reply from the embedded device. 


#!/usr/bin/env ruby
require 'packetfu'
require 'rubygems'

$ipcfg = PacketFu::Utils.whoami?(:iface => 'eth0')
puts "Broadcast test"

#Create discovery packet
eth_pkt = PacketFu::EthPacket.new

#Send the packet
puts "Sending the discovery packet"

- Creating a Metasploit Module: -


I found conflicting information on how to go with this. The following did work for me: 



Find an existing module or exploit and create a copy: /opt/metasploit/apps/pro/msf3/modules/auxiliary/scanner/misc/[script.rb]



Open your new module and change the title + description. Leave other content "as is". Save the script. Reload or restart MSF: reload_all

Search for the new name: search [script.rb]

Once this works move on.



Define what options the script needs. Mine requires the user to set their interface (required), source MAC address (optional) and a timeout (optional). It works as follows:

specify the option, specify if it is required T|F, add a description, set a default value.


Example: register_options([OptString.new('INTERFACE', [true, "Interface Name", 'eth0'])])


Deregister the options that are not needed. 


Example: deregister_options('RHOSTS','THREADS')


Run the module again in Metasploit and issue a "show options" to review everything is correct.



Code the module. I currently have my main section going and a broadcast function. I am working on the receiver to intercept and parse the packet. 


If you make some mistake Metasploit will either crash or give a meaningful error message. 


Once my module is fully functional I will paste it here.



- Browser Plugin Fuzzing -


Once you authenticate to the WebGUI a special plugin is required to view video output. In the past it would automatically ask you to download and install it. However the control is now blocked by default as it is a NPAPI plugin. No new version had been released yet. NPAPI is similar to an ActiveX control. More details here: https://en.wikipedia.org/wiki/NPAPI


In Chrome you can enable it: chrome://flags/#enable-npapi

Google: "In September 2015 we will remove the override and NPAPI support will be permanently removed from Chrome." 


Once enabled you can download the file and run it (requires admin privs). Upon execution it will install various files on your system under a sub-folder in "program files". The files installed are a .OCX and five DLL's. 


We can now view details and/or fuzz the .ocx control with COMRaider to look for vulnerabilities (BoF). Start COMRaider, browse to the control, select which functions to fuzz and wait. I have another fuzzer I like to test however it fails to load the control so I have to fix it.


Latest edit: rewrote the packet discovery part to make it easier to follow and replicate. Currently writing the parser for my Metasploit script.

Edited by herman

Share this post

Link to post
Back from holiday, so only played around a little bit more.
- Metasploit Scripting -
I am finishing the Metasploit discovery script, it receives and partially parses a valid response. Still have to RE a few bytes. Once finished I put a heavily commented version here.
- Packet Replay -
A replay of a "broadcast discovery reply" packet to the software did not work. What have I tried?
I have captured various request and reply packets in order to determine the structure. The overall structure is static with the exception of two counters. 

Counter 01 must be the same value in a request / reply sequence so it acts like a sequence number.

Counter 02 unknown, decrements 

The module [path+dll] was loaded but the entry-point DLLRegisterServer was not found.

Make sure that [path+dll] is a valid DLL or OCX and then try again.

Running a capture while sending a discovery request let's us predict valid values in the near future. With Colasoft Packet Builder (Windows) we ensure the Hikvision Mac Address is used and modify the two counter values and replay it at the correct time.

The software does not fall for this. Right now out of idea's.
- Password Reset by Serial Code -
Another online user has reversed the Windows software code and was able to generate valid password reset codes. I will look at this later as exercise. I would first need to learn some anti-debugging bypasses and more RE. 
- The .OCX control / NPAPI -
I am able to fuzz it with COMRaider but I cannot load into FuzzSaw. Anybody have an idea why? 
These are the steps I take: 
01 Choose a new ActiveX project
02 Paste the CLSID obtained from COMRaider. This gives the following error: 

The module [path+dll] was loaded but the entry-point DLLRegisterServer was not found.

Make sure that [path+dll] is a valid DLL or OCX and then try again.

Online solution: register the ocx file

Command: admin cmd prompt, regsvr32 [path+ocx file]
Result: DLLRegisterServer [path] succeeded.
Reloading it in the fuzzer still gives the same 80040154 error. 
Online solution: register the DLL's which the application uses. 
In the install directory their are several so let's try this.
Command: admin cmd prompt, regsvr32 [path+dll file] 
Gives an error:

The module [path+dll] was loaded but the entry-point DLLRegisterServer was not found.

Make sure that [path+dll] is a valid DLL or OCX and then try again.
Online solution: 
Regsvr32.exe was unable to find the required entry point in the module specified in the command line. This can occur if the entry points are not exported correctly from the module or if the module is not a .DLL or .OCX file.
You are attempting to register a dll that is not a COM library
Anybody knows how to solve this?
Once finished I will publish some info about firmware unpacking to get back on topic.

Share this post

Link to post

Please sign in to comment

You will be able to leave a comment after signing in

Sign In Now