CTF Box: Kioptrix level 1 walk-through

This is a walk-through of the first level of the CTF box series named Kioptrix. The virtual machines images can be downloaded from:

https://www.vulnhub.com/entry/kioptrix-level-1-1,22/

There are two methods I used to exploit this machine, but first, let's enumerate the server.

Enumeration

To start, I ran a Nmap scan on the server to see what services are running on it.

 # Nmap 7.70 scan initiated Sat Apr 13 14:05:06 2019 as: nmap -O -A -sV -sC -oA nmap/knoptrix1 192.168.56.5
Nmap scan report for 192.168.56.5
Host is up (0.00040s latency).
Not shown: 994 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 2.9p2 (protocol 1.99)
| ssh-hostkey: 
| 1024 b8:74:6c:db:fd:8b:e6:66:e9:2a:2b:df:5e:6f:64:86 (RSA1)
| 1024 8f:8e:5b:81:ed:21:ab:c1:80:e1:57:a3:3c:85:c4:71 (DSA)
|_ 1024 ed:4e:a9:4a:06:14:ff:15:14:ce:da:3a:80:db:e2:81 (RSA)
|_sshv1: Server supports SSHv1
80/tcp open http Apache httpd 1.3.20 ((Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
| http-methods: 
|_ Potentially risky methods: TRACE
|_http-server-header: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-title: Test Page for the Apache Web Server on Red Hat Linux
111/tcp open rpcbind 2 (RPC #100000)
| rpcinfo: 
| program version port/proto service
| 100000 2 111/tcp rpcbind
| 100000 2 111/udp rpcbind
| 100024 1 1024/tcp status
|_ 100024 1 1024/udp status
139/tcp open netbios-ssn Samba smbd (workgroup: MYGROUP)
443/tcp open ssl/https Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-server-header: Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-title: 400 Bad Request
|_ssl-date: 2019-04-13T22:05:23+00:00; +3h59m59s from scanner time.
| sslv2: 
| SSLv2 supported
| ciphers: 
| SSL2_RC2_128_CBC_WITH_MD5
| SSL2_RC4_128_EXPORT40_WITH_MD5
| SSL2_DES_192_EDE3_CBC_WITH_MD5
| SSL2_RC4_64_WITH_MD5
| SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
| SSL2_DES_64_CBC_WITH_MD5
|_ SSL2_RC4_128_WITH_MD5
1024/tcp open status 1 (RPC #100024)
MAC Address: 08:00:27:1E:E3:F7 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 2.4.X
OS CPE: cpe:/o:linux:linux_kernel:2.4
OS details: Linux 2.4.9 - 2.4.18 (likely embedded)
Network Distance: 1 hop
Host script results:
|_clock-skew: mean: 3h59m58s, deviation: 0s, median: 3h59m58s
|_nbstat: NetBIOS name: KIOPTRIX, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
|_smb2-time: Protocol negotiation failed (SMB2)
TRACEROUTE
HOP RTT ADDRESS
1 0.40 ms 192.168.56.5
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Apr 13 14:09:34 2019 -- 1 IP address (1 host up) scanned in 267.98 seconds

In the output above you will see there are two interesting services Apache HTTPD 1.3.20 with mod_ssl/2.8.4 OpenSSL/0.9.6b and Samba. The version of HTTPD version is quite old and will be of interest. Next, I'll take a look at Samba using enum4linux.

Starting enum4linux v0.8.9 ( http://labs.portcullis.co.uk/application/enum4linux/ ) on Sat Apr 13 14:11:01 2019
 ========================== 
| Target Information |
 ========================== 
Target ........... 192.168.56.5
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none
 ==================================================== 
| Enumerating Workgroup/Domain on 192.168.56.5 |
 ==================================================== 
[+] Got domain/workgroup name: MYGROUP
 ============================================ 
| Nbtstat Information for 192.168.56.5 |
 ============================================ 
Looking up status of 192.168.56.5
 KIOPTRIX <00> - B <ACTIVE> Workstation Service
 KIOPTRIX <03> - B <ACTIVE> Messenger Service
 KIOPTRIX <20> - B <ACTIVE> File Server Service
 ..__MSBROWSE__. <01> - <GROUP> B <ACTIVE> Master Browser
 MYGROUP <00> - <GROUP> B <ACTIVE> Domain/Workgroup Name
 MYGROUP <1d> - B <ACTIVE> Master Browser
 MYGROUP <1e> - <GROUP> B <ACTIVE> Browser Service Elections
 MAC Address = 00-00-00-00-00-00
 ===================================== 
| Session Check on 192.168.56.5 |
 ===================================== 
[+] Server 192.168.56.5 allows sessions using username '', password ''
 =========================================== 
| Getting domain SID for 192.168.56.5 |
 =========================================== 
Domain Name: MYGROUP
Domain Sid: (NULL SID)
[+] Can't determine if host is part of domain or part of a workgroup
 ====================================== 
| OS information on 192.168.56.5 |
 ====================================== 
[+] Got OS info for 192.168.56.5 from smbclient: 
[+] Got OS info for 192.168.56.5 from srvinfo:
 KIOPTRIX Wk Sv PrQ Unx NT SNT Samba Server
 platform_id : 500
 os version : 4.5
 server type : 0x9a03
 ============================= 
| Users on 192.168.56.5 |
 ============================= 
 ========================================= 
| Share Enumeration on 192.168.56.5 |
 ========================================= 
 Sharename Type Comment
 --------- ---- -------
 IPC$ IPC IPC Service (Samba Server)
 ADMIN$ IPC IPC Service (Samba Server)
Reconnecting with SMB1 for workgroup listing.
 Server Comment
 --------- -------
 KIOPTRIX Samba Server
 Workgroup Master
 --------- -------
 MYGROUP KIOPTRIX
[+] Attempting to map shares on 192.168.56.5
//192.168.56.5/IPC$ [E] Can't understand response:
NT_STATUS_NETWORK_ACCESS_DENIED listing \*
//192.168.56.5/ADMIN$ [E] Can't understand response:
tree connect failed: NT_STATUS_WRONG_PASSWORD
<...SNIP...>
enum4linux complete on Sat Apr 13 14:11:09 2019

There is a lot of useful information in this output; however this a bug in the version of enum4linux that does not show the version of Samba running on the server. This missing information becomes important in the second method for getting into the server. Now let us take a look at the first method I used to get on to the server.

Method 1

The first method of getting a shell on the server exploits the mod_ssl module in Apache HTTPd. I found in the enumeration phase that the server is running Apache HTTPD 1.3.20 with mod_ssl/2.8.4 OpenSSL/0.9.6b. After a quick search in Exploit-DB, I found that there are two versions of an exploit for CVE-2002-0082 named OpenFuck and OpenFuck2. First I used OpenFuck found at https://www.exploit-db.com/exploits/21671

This exploit ran without issue and gave an unprivileged shell as the user apache using, the output of the exploit is below.

After running the exploit and getting on the server, I found the reverse shell died regularly. Once I changed the shell syntax to add "nohup" to background the reverse shell process making the shell not die regularly.

There is a better version of this exploit named OpenFuckv2. This version chains a kernel exploit to get root and can be found at https://www.exploit-db.com/exploits/764. There are issues building this version of the exploit on Linux distributions that have newer versions of libssl. The following link has instructions on how to modify the code from exploit-db to work on more modern distributions.

https://www.hypn.za.net/blog/2017/08/27/compiling-exploit-764-c-in-2017/

Now that we have exploited the mod_ssl service to get unprivileged access on the server we can move onto the next method to get into and finally get root on this box.

Method 2

After getting an unprivileged shell on the server using Method 1 I started enumerating the server and found that this is a Red Hat Linux release 7.2 (Enigma) server running Samba 2.2.1a. This version of Samba service has the RCE vulnerability, CVE-2003-0201 - Buffer overflow in the call_trans2open function in trans2.c for Samba 2.2.x before 2.2.8a, 2.0.10 and earlier 2.0.x versions.

This CVE has a published exploit in exploit-db at https://www.exploit-db.com/exploits/10. The output when running the exploit in brute force mode is shown below,

Since this service is running as root, boom, we have a root shell!

Overall, This was a pretty straightforward box and would have been easier if I had found the version of Samba earlier.

DIGOO DG-HOSA – Part 2 Firmware Extraction and Initial Analysis

This is a continuation from a previous post: https://ben.the-collective.net/2019/08/21/digoo-dg-hosa-part-1-teardown-and-hardware/

Finding the connections

Now that I have the lay of the land for the device (which that I outlined in my previous part of the series) the first thing I looked for is the debugging connections for the main GigaDevices processor. This processor looks to be the primary processor for the device and has the most valuable firmware. Since the board was well labeled I didn't need to use any tools like a JTAGulator or an Arduino board with the JTAGenum firmware to identify which test points are the debug interface. I was able to find the SWDIO, SWCLK, +3.3 and GND connections for the Serial Wire Debug (SWD) debug interface. This is the same interface that STM32 chips utilize and it provides similar functionality as a "standard" JTAG interface.

Serial Wire Debug (SWD) is a 2-pin (SWDIO/SWCLK) electrical alternative JTAG interface that has the same JTAG protocol on top. SWD uses an ARM CPU standard bi-directional wire protocol, defined in the ARM Debug Interface v5. This enables the debugger to become another AMBA bus master for access to system memory and peripheral or debug registers.

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2014/10/21/serial_wire_debugs-qKCT

In the image below you can see the debug test points along with the with wires soldered to them to connect to my debugger. The proximity of these test points to the GD32F105 processor, it is a good assumption that they are for that chip.

As a bonus also pictured is my wire soldered around the switch on the upper left to bypass the intrusion detection function.

For this project, I soldered wires to most of the test points across the board. This board has a ton of test points that maybe be useful to monitor signals over the course of this project. To manage the wiring for all of the test points on this project I created a test jig to keep the setup organized. The next picture shows my test setup.

The firmware extraction setup

This jig was inspired by some tweets long ago by cybergibbons where he recommended doing something similar. Once all of the test wires were in place, I hooked up my ARM debugger of choice the Black Magic Probe (BMP) from 1BitSquared and the process to started to extract the firmware.

Initially, I tried to power the board using the BMP but I found that the BMP was not able to provide enough power to the board to support the minimum number of peripherals. The BMP can only supply 100mA of power. Some lights would come on but gdb would not detect any devices connected. I ended up adding the USB connection you see in the photo to provide more power to the board.

Now that everything is powered and connected I was able to use gdb to attach to the board and dump the firmware of the device.

Extracting the firmware: gdb

The first step is to attach my local arm gdb build to the Blackmagic Probe which acts as a remote gdb server. I always find the Useful GDB commands wiki page in the BMP wiki to be very useful in refreshing my memory. The syntax and terminal output I started with are:

╭─locutus@theborgcube ~/Projects/RE-Digoo_DG-HOSA
╰─$ arm-none-eabi-gdb -ex "target extended-remote /dev/tty.usbmodemC2D9BBC31"
 GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160616-cvs
 Copyright (C) 2015 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
 and "show warranty" for details.
 This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
 Type "show configuration" for configuration details.
 For bug reporting instructions, please see:
 http://www.gnu.org/software/gdb/bugs/.
 Find the GDB manual and other documentation resources online at:
 http://www.gnu.org/software/gdb/documentation/.
 For help, type "help".
 Type "apropos word" to search for commands related to "word".
 /Users/locutus/.gdbinit:1: Error in sourced command file:
 No symbol table is loaded.  Use the "file" command.
 Remote debugging using /dev/tty.usbmodemC2D9BBC31
 (gdb) monitor
 Black Magic Probe (Firmware v1.6.1-1-g74af1f5) (Hardware Version 3)
 Copyright (C) 2015  Black Sphere Technologies Ltd.
 License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
 (gdb) monitor swdp_scan
 Target voltage: 3.3V
 Available Targets:
 No. Att Driver
  1      STM32F1 high density
 (gdb) attach 1
 Attaching to Remote target
 0x08007b46 in ?? ()
 (gdb) dump binary memory firmware.bin 0x08000000 0x080FFFFF
 Cannot access memory at address 0x8080000

When I ran into the error at the end of the terminal output I was a bit confused until I looked at this memory layout of the chip in the datasheet and saw that I was overrunning the size of the first flash memory bank.

datasheet

After I adjusted the GDB dump command...

(gdb) dump binary memory firmware.bin 0x08000000 0x0807FFFF
(gdb)

...success!

╭─locutus@theborgcube ~/Projects/RE-Digoo_DG-HOSA
╰─$ ls -l firmware.bin
 -rw-r--r--  1 locutus  staff  524287 Nov 16 14:13 firmware.bin

I now have a copy of the firmware we can do some initial analysis of it.

Initial Analysis

First thing first like with any binary I start by running strings to get some hints on the contents of the binary and make sure it is a valid dump. I found a ton of strings showing this is a valid dump of the firmware, most notably the same markings on the board showing up in the firmware:

PCB:PG-103 VER2.3/FIRMWARE: 103-2G-J

and other strings indicate that they are using the Real-Time Operating system (RTOS) OS-III (link2) as the operating system. The Micrium site does not specifically list the Gigadevices chip in the supported just the general ARM Cortex-M3 cores as supported.

Seeing this let me know that reversing this firmware will be much more complex then I had hoped. The RTOS will add a lot of scheduling and random functions to look into. After this initial investigation, it is time to load the firmware into Radare. I used the following command when loading it up:

r2 -a arm -b 16 -m 0x0800c000 firmware.bin

This syntax sets the proper processor (-a) and CPU register size (-b) and starting memory location (-m). Once loaded I run an initial analysis job to see what Radare finds.

[0x0800c000]> aaa
 [x] Analyze all flags starting with sym. and entry0 (aa)
 [x] Analyze function calls (aac)
 [x] find and analyze function preludes (aap)
 [x] Analyze len bytes of instructions for references (aar)
 [x] Check for objc references
 [x] Check for vtables
 [x] Finding xrefs in noncode section with anal.in=io.maps
 [x] Analyze value pointers (aav)
 [x] Value from 0x0800c000 to 0x0808bfff (aav)
 [x] 0x0800c000-0x0808bfff in 0x800c000-0x808bfff (aav)
 [x] Emulate code to find computed references (aae)
 [x] Type matching analysis for all functions (aaft)
 [x] Use -AA or aaaa to perform additional experimental analysis.

[0x0800c000]> afl |wc -l
      844

Radare found 844 functions without any hints or adjustments. In some of the work I have already done, there are even more than 844 functions. Now that I have a copy of the firmware, I've dived in and started analyzing the firmware which as of writing is still a work in progress. As I get further along I will cover some of the techniques I am using to take apart this firmware.

Enabling old TLS / SSL ciphers in OpenSSL

I was reminded of this tip during the CTF at a recent DC207 meetup. This config change is needed on machines with modern versions of OpenSSL that have disabled the older ciphers. The issue is that the old TLS, SSL and associated cipher suites have become insecure and support is subsequently dropped in OpenSSL.

For a workaround to this, you can edit the following lines at the bottom of /etc/ssl/openssl.cnf

[system_default_sect]
 MinProtocol = TLSv1
 CipherString = DEFAULT@SECLEVEL=1

It may be required to comment out similar lines in the config if they already exist.

My OSCP Experience

What is the OSCP

Offensive Security Certified Professional (OSCP) is an entry-level hands-on penetration testing certification. The OSCP is one of a few certifications by Offensive Security. It consists of the self-study Penetration Testing Training with Kali Linux (PwK) class and an online proctored practical exam.

The course costs at minimum $800 USD and includes 30 days of lab access and one OSCP exam attempt. There are packages that include longer lab access and you can extend your lab access if you find you need longer to prepare.

What ISN’T the OSCP

  • Current methods and techniques
  • It won’t make you a l33t hax0r, but you will learn fundamentals

How long did you study?

I started working on it on Sept 2018, then life and the holidays got in the way of dedicated study time. I kept slowly and intermittently practicing until April 2019 when I REALLY started to get serious about completing the OSCP. This started crunch time. I am lucky that my partner was on board with me locking my self away to focus on labbing. I took the exam on May 9th 2019.

How did you do to study?

I started by going through both the Offensive Security’s Penetration Testing with Kali Linux (PwK) workbook and then watching the associated videos. They are both fantastic resources providing a solid base of knowledge you need for the exam. I had the printed out the PwK workbook printed out and bound to save my eyes from staring at a screen. Through all my studies, I took a lot of notes. I used these notes when working on machines in the lab, exam, and other CTF style boxes I worked. Below are copies of the notes I created while studying.

Once I completed the workbook and videos, it was time to sit down and start to work on machines in the Lab. While working on the labs I began to branch out and gather and learn from various sources across the internet. As I worked through the lab and got closer to my date, I started to focus on my weak topics for me that were Windows Exploitation and Windows Privilege Escalation. I have added some of the main links and books I used to study, there are many more links in my notes.

Links

Books

  • Penetration Testing: A Hands-On Introduction to Hacking - Georgia Weidman
  • The Hacker Playbook: Practical Guide To Penetration Testing - Peter Kim
  • The Hacker Playbook 2: Practical Guide To Penetration Testing - Peter Kim
  • Hacking: The Art of Exploitation - Jon Erickson

OMG the Exam…

The OSCP exam is a practical test that is 24 hours of hacking in a mock environment attempting to break into various targets. You will then have another 24 hours to write a report based on your findings from the exam. To obtain your OSCP you must submit a report I'll talk more about the report later. The Exam is proctored, you will run software that will capture your screen and webcam, both of which will also be monitored by one or more proctors. There are limits to the tools you can during the Exam:

Spoofing (IP, ARP, DNS, NBNS, etc)
Commercial tools or services (Metasploit Pro, Burp Pro, etc.)
Automatic exploitation tools (e.g. db_autopwn, browser_autopwn, SQLmap, SQLninja etc.)
Mass vulnerability scanners (e.g. Nessus, NeXpose, OpenVAS, Canvas, Core Impact, SAINT, etc.)
Features in other tools that utilize either forbidden or restricted exam limitations
You are limited to use Metasploit once during the lab

https://support.offensive-security.com/oscp-exam-guide/

These limitations are an example of why it is important to fully read through the exam guide and reporting template to make sure you have all the proofs and meet the reporting requirements. These guides are found at the following links:

Lab and Exam Reporting Info: https://support.offensive-security.com/pwk-reporting/
OSCP Exam Guide: https://support.offensive-security.com/oscp-exam-guide/
Proctoring FAQ: https://support.offensive-security.com/proctoring-faq/

My exam agenda

When planning for my Exam I created a high-level schedule to follow. This is an important and way for me to get organized. My exam started at 9:00 am allowing me to follow a similar routine to what I do normally.

  • Wake up … Breakfast
  • Connect to Proctor and follow preocess - 15 mins before start
  • Receive access details and connect to VPN - 15 mins
  • Read requirements and write down in notes - 30 - 45 mins
  • Initial Enumeration of targets - 1 hour
  • Hack Away!
  • Eat Lunch
  • Hack…
  • Eat Dinner
  • Probably still Hack…..

Exam Tips and Tactics

This is a list of various mostly non-technical tips I have for when taking the Exam. When reading through people's challenges on Reddit, Twitter and Blog posts I saw a lot of people ran into less than technical issues when taking their Exams.

  • I'll repeat this here make sure you read through the exam guide and reporting template to make sure you have all the proofs and meet the reporting requirements!
  • Attempt to limit distractions and find ways to go into flow
  • Manage your Time Management wisely
    • I used Pomodoro to help divide up my day. This method is ~25 minutes working, take a 5-minute break, repeat. I changed targets on each cycle if I was not making progress and was just grinding away on a machine. This method helped me getting stuck on one machine for extended periods of time.
  • Keep a timeline of the day
    • This will help you reference and screenshots or recordings you created later.
  • You are your own worst enemy: Avoid going down a rabbit hole
    • Breath…go for a walk…pet a cat…Have a snack...
  • Enumerate Enumerate Enumerate
    • If you are not finding your way into a system or the way to escalate privilege, enumerate more.
  • Screenshot, Screen record, track everything! This will take the stress off of creating the report the next day.

Reporting

There are two topics when it comes to reporting there is the Lab report and the Exam report. Offensive Security provides a guide for reporting at the following URL: https://support.offensive-security.com/pwk-reporting/. This contains some templates and some recommendations on how to manage data.

One of the first questions people ask is if I did the Lab report. I decided not to do the Lab report, it only worth 5 points, and I did not find that the time to create the report was worth it for me. However, I did write a mock report to practice ahead of the Exam. The made sure that my first Exam reporting experience was not during the Exam when I would be exhausted.

When it comes to my Exam report, I started my report after I had finished my Exam but has not closed out with my proctor and start to create a very very very rough document with the screenshots and other content. I did this to make sure I had satisfied all of the requirements and it would let me go back and recreate or regather any Proofs I may have missed. After I thought I had everything and the adrenalin had started to wear off I went to sleep and got started the next day and finished the document throughout the next day.

In Closing

  • The OSCP was a great experience and very challenging
  • There is a lot to learn
  • Make sure significant people in your life understand the time commitment
  • ABL, Always Be Labbing
  • Have fun, good luck, and #tryharder

Link: Exploring Key Features of Cisco ISE Release 2.6

In July I wrote for the CDW blog about the new version of the Cisco Identity Services Engine (ISE) software.

Exploring Key Features of Cisco ISE Release 2.6

The latest version of this cybersecurity tool offers unique device identification and an IoT protocol.

DIGOO DG-HOSA – Part 1 (Teardown and Hardware)

Banggood page

This project started with the idea of purchasing a cheap security system off one of the Chinese stores. After a little hunting, I found Digoo DG HOSA 433MHz 2G&GSM&WIFI Smart Home Security Alarm System Protective Shell Alert with APP which looked interesting so picked one up to tear apart. I was curious about how various communication methods were implemented.

This is the first part of this adventure the next part will be exploring the firmware of the device. With that let's take a look at the hardware.

Teardown Time

After the device showed up, I quickly got down to taking the device apart. In my haste, I didn't take many good photos of it intact. The front side of the board is straight forward; it contains the screen, button array for all user input, and a lot of useful test points. The front side is pictured below.

Board Front

The most significant information found on the front side of the board is the notation PG-103, which is also found in the firmware (spoiler). After some searching, I found this device is also branded as the PGST PG-103. This kind of rebranding of hardware is not unusual for a lot of Chinese devices.

Now switching to the back of the board, which is the business side of the board with the main chips and modules providing the various communication methods. When opening that device I encountered the intrusion detection button. This button causes the device to go into an alarm mode and require a reset of the device to come back online. For my testing, I bypassed this button bridging both sides of it.

Back of Board
Board Back

Component List

When inspecting the board, I found a few significant components and modules on the board. I was not surprised to see that most of the major communication parts are off the shelf modules. The components listed below are highlighted in the image above and the relevant data sheets where available are linked.

The main processor is a GigaDevice GD32 chip which is a series that is very similar to the of STMicroelectronics STM32 chips. The GD32F105 chip uses an ARM-based instruction set and has the same pinout as the STM32F105 component.

Block Diagram

The high-level block diagram for the device is pretty straight forward. The GD32F105 chip is the primary processing and control of the external communication modules. This allows for a modular architecture all of the peripherals.

 +-----------------------+
 |  Cellular             +-----------+
 |  Quictel M26          |           |
 +-----------------------+           |
 +-----------------------+  +--------+-------+
 |  WIFI                 +--+   CPU          |
 |  HF-LPB120-1          |  |   GD32F105RCT6 |
 +-----------------------+  +--------+-+-----+
 +-----------------------+           | |
 |  433mhz receiver      |           | |
 |  SYN511R              +-----------+ |
 +-----------------------+             |
 +-----------------------+             |
 |  Keypad Controller    +-------------+
 |  Holtek BS83B16A-3    |
 +-----------------------+

Pin Out

When exploring the board there are many test points on the board and tracing them out I was able to trace out most of the pins to where they connect on the controller.

  • SYN515R Pin 10 (DO) -> CPU PB9 (62)
  • Unknown -> CPU PA5
  • Unknown -> CPU PA6
  • Unknown -> CPU PA8
  • U7 SCL -> Unknown
  • U7 SDA -> Unknown
  • DAC_OUT -> CPU PA4 (20)
  • WIFI UART TX -> CPU PA2 (16)
  • WIFI UART RX -> CPU PA3 (17)
  • GSM UART TX -> CPU PA12 (45)
  • GSM UART RX -> CPU PA13 (46)
  • U1 (F117) Pin 6 -> CPU PB 8

Summary?

After investigating the hardware I was able to extract the firmware and start the reversing process. I will cover what I have found in future posts. For now, if you are interested in more higher resolution photos of the board I have posted them on my Flickr account.

BSidesNH 2019 Recap

Badge

Back on May 18th, I attended the inaugural BsidesNH event. It was a fantastic one-day event. The day started pretty early for me driving down from Maine arriving at Southern NH University. I arrived to pick up the fantastic badge made out of an old 3.5" disk. After grabbing some coffee and a snack I settled into the auditorium and for a day of great talks. There were a few that stood out to me from the day that I will talk about.

The second talk of the day was Ghost in the Shell: When AppSec Goes Wrong by Tony Martin. Tony first talked about covered some basics of web application security. He framed these issues around the research he has done into various NAS devices and vulnerabilities he has discovered. Including the ability to create shadow users that have administrative access to devices but are not visible through the administrative interfaces of the device.

After lunch was Chinese and Russian Hacking Communities presented by Winnona DeSombre and Dan Byrnes, Intelligence Analyst from Recorded Future. They covered operations and cultures of Chinese and Russian underground groups. This was a very entertaining presentation and a summary of the information contained in the report: Thieves and Geeks: Russian and Chinese Hacking Communities.

The second to last talk of the day was Hunting for Lateral Movement: Offense, Defense, and Corgis presented by Ryan Nolette. He covered the ways attackers move around and infiltrate further into a network...Corgies. A great quote that stuck with me from his talk was: “If you teach an analyst how to think they will punch above their weight.” I feel this quote not only applies to security analysts but all levels of IT professionals.

BsidesNH was a well run and enjoyable event and a great addition to the Security events in New England. Thanks to all of the organizers and sponsors. I look forward to attending next year!