Phoebetria for Mac v.1.4.0

Many such devices on the market today are based on HiSilicon (a Huawei brand) hi3520d ARM SoC running a special Linux distribution called HiLinux, with a set of user-space utilities and a custom web application on top. Security research on HiSilicon devices has been done in the past. Here are some existing publications. Download Recon Engage for iOS to relive your activities, share them, and supercharge your Recon deviceLIVE TRACKINGShare your current location with friends and see where they are.

Phoebetria lets you take control of your BitFenix Recon fan controller on more operating systems than the official software.

• Category: Miscellaneous Utilities
• Developer: Christopher Ferris, Craig Robbins - Download - Free

• bitfenix recon controller - fan controller - control cooler - controller - fan

Phoebetria for Linux v.1.4.0

Phoebetria lets you take control of your BitFenix Recon fan controller on more operating systems than the official software.

• Category: Miscellaneous Utilities
• Developer: Christopher Ferris, Craig Robbins - Download - Free

• bitfenix recon controller - fan controller - control cooler - controller - fan

Advertisement

Phoebetria v.1.4.0

Phoebetria lets you take control of your BitFenix Recon fan controller on more operating systems than the official software.

• Category: Miscellaneous Utilities
• Developer: Christopher Ferris, Craig Robbins - Download - Free

• bitfenix recon controller - fan controller - control cooler - controller - fan

Recon HQ v.1 3

Recon HQ is a free application for your PC or Mac that allows you to organize your achievements and statistics from the mountain or backcountry straight to your computer.

• Category: Personal and Home
• Developer: Recon Instruments Inc. - Download - Free

• recon instruments - mod live - gps goggles - shop - recon

Disk Recon v.4.5

Disk Recon allows you to investigate folder sizes, find duplicate files, examine your disk usage, monitor files and directories and more. New features include batch file renaming, batch attribute changing and file or image preview.

• Category: File and Disk
• Developer: Blacksun Software - Download - Buy: $35.00

Recon Instruments Port Devices Driver Download For Windows Xp

• diskspace - foldersizes - duplicate files - file search - rename

Local Recon v.1.0

Find locations and people easily. Local Recon help you locate places and people with GPS-like technology.

• Category: Other Comms Tools
• Developer: earthcomber.com - Download - Free

Tank Recon 3D v.2.14.0.0

Piloting your new advanced tank, code named Alpha, you will be shooting it out with various units such as tanks, planes, helicopters, AT guns and more. Fire your main cannon and watch as the enemy explodes into pieces.

• Category: Adventure
• Developer: Lone Dwarf Games Inc - Download - Price: $1.99

FlashTray

Multifunctional system tray utility. It includes a multilevel Launchbar, Programmable Macro Hotkeys, Screen Highlighter, Color Picker, Screen Magnifier, Character map. These utilities can make your daily work a lot easier.

• Category: System Management
• Developer: Blacksun Software - Download - Free

• font - fonts - font manager - font viewer - freeware

Tom Clancy's H.A.W.X v.1. 2. 2002

Tom Clancy's H.A.W.X is a flight simulator based on the Tom Clancy sci-fi world. These days, every game with the words Tom Clancy sells a lot, and easily. In this case, the game has little to nothing to do with the Tom Clancy world.

• Category: Games
• Developer: Ubisoft Entertainment - Download - Buy: $49.99

• tom clancy - ubisoft - air combat - airplane - flying

FEAR Extraction Point v.1.0.4510

F.E.A.R. Extraction Point is an expansion of the popular F.E.A.R video game. Extraction Point has been published by Vivendi Universal and developed by TimeGate Studios (instead of Monolith Productions developers of the original F.E.A.R.).

Recon Instruments Port Devices Driver Download For Windows 10

• Category: Games
• Developer: Vivendi Universal Games, Inc. - Download - Buy: $29.99

• houston game developer - sugar land game developer - texas game developer - section 8 - f e a r extraction point

UFO Extraterrestrials v.1.0

Planet Esperanza - colonized by spaceship Magaleansh in 2020. Many years have passed since the first colonists arrived Esperanza. Through hard work and determination, they gradually setup base on their adopted planet.

• Category: Games
• Developer: Tri Synergy - Download - Buy: $26.00

NZip Sales Package v.9.0.470

NZip 9.0 Sales Package is Dynamic Inventory, Sales, Purchase & Accounting App; Includes Front-Sales Panel and Back-Office Panel in Single App bundle, which is ideal for Medium and Small Business Sales like Apparel, Boutique, FMCG, Stores, Shops etc.

• Category: Inventory & Barcoding
• Developer: Nandvarik Systems - Download - Price: $50.00

• nandvarik - systems - softwares - solutions - services

15 Sep 2020

This article discloses critical vulnerabilities in IPTV/H.264/H.265 video encoders based on HiSilicon hi3520d hardware. The vulnerabilities exist in vendor application software running on these devices. All vulnerabilities are exploitable remotely and can lead to sensitive information exposure, denial of service, and remote code execution resulting in full takeover of the device. With multiple vendors affected, and no complete fixes at the time of the publication, these encoders should only be used on fully trusted networks behind firewalls. I hope that my detailed write-up serves as a guide for more security research in the IoT world.

• Network recon
• Firmware analysis
• Local recon
• Reverse engineering
• Vulnerabilities and exploits
• Disclosure

Summary

The following vulnerabilities were identified:

• Critical
  • Full admin interface access via backdoor password (CVE-2020-24215)
  • root access via telnet (CVE-2020-24218)
  • Arbitrary file disclosure via path traversal (CVE-2020-24219)
  • Unauthenticated file upload (CVE-2020-24217)
    • Arbitrary code execution via malicious firmware upload
    • Arbitrary code execution via command injection
• High
  • Denial of service via buffer overflow (CVE-2020-24214)
• Medium
  • Unauthorized RTSP video stream access (CVE-2020-24216)

See CERT/CC vulnerability note VU#896979

During my research I had physical access to several devices from the following vendors: URayTech, J-Tech Digital, and Pro Video Instruments. I performed my research initially on URayTech, then confirmed vulnerabilities in the other two vendors.

There is at least a dozen of different vendors that manufacture and sell very similar devices. By analyzing product documentation and firmware update packages, I’ve got a high level of confidence those devices were also affected by most, if not all, vulnerabilities listed here. Here is an [incomplete] list of these additional vendors: Network Technologies Incorporated (NTI), Oupree, MINE Technology, Blankom, ISEEVY, Orivision, WorldKast/procoder, Digicast

It is my understanding that most of these devices are intended to be used behind NAT/firewall. However, I was able to utilize shodan.io to identify several hundred devices on the public internet, all likely to be exploitable by an anonymous remote attacker.

Background

Hardware video encoders are used for video streaming over IP networks. They convert raw video signals (such as analog, SDI, HDMI) to H.264 or H.265 streams and send them to a video distribution network (YouTube, Twitch, Facebook,…) or let the users watch the video directly via RTSP, HLS, etc. Normally, these encoders have a web interface to allow the administrator to configure networking, encoding parameters, streaming options, and so on. Many such devices on the market today are based on HiSilicon (a Huawei brand) hi3520d ARM SoC running a special Linux distribution called HiLinux, with a set of user-space utilities and a custom web application on top.

Security research on HiSilicon devices has been done in the past. Here are some existing publications:

• Root shell in IP cameras (in Russian) by Vladislav Yarmak, 2013. The research uncovered the root password allowing root shell access over telnet.
• HiSilicon DVR hack by Istvan Toth, 2017. This research targeted DVR/NVR devices, and uncovered a root shell access with elevated privileges, a backdoor password, a file disclosure via path traversal, and an exploitable buffer overflow.
• Full disclosure: 0day vulnerability (backdoor) in firmware for Xiaongmai-based DVRs, NVRs and IP cameras by Vladislav Yarmak. This research uncovered a very interesting “port knocking” backdoor allowing a remote attacker to start the telnet, and then log in with one of the several known passwords.

While the streaming video encoders may share the same hardware architecture and the underlying Linux system with the above devices, my research targets the admin web application specific to the video encoders and does not overlap with the prior work.

Hardware

Here is a few pictures of one of the devices I had an opportunity to test.Physical portsTop cover off. The right side, from top to bottom: LAN, HDMI out, reset, HDMI in, LEDs, audio inLet’s plug this thing in, connect to network, and start exploring!

Network recon

A simple nmap scan reports the following open ports:

23 - telnet

Telnet displays the login prompt, but the password is unknown at this point:

80, 8086 - web application

Both ports serve the main admin web interface. The default credentials are admin/admin

The login prompt suggests basic HTTP authentication, but this is actually digest authentication. The following header is returned by the application:

and the browser authenticates with:

(as I will demonstrate below, digest is not the only authentication method supported by the application)

After logging in, the user sees a simple web interface.

Note that vendors customize the interface, and your device can display something completely different, such as:However, the underlying functionality (the web API calls) are all the same regardless of the UI.

There are several sections where the administrator can perform various tasks such as setting up the network, adjusting encoder parameters, uploading images to overlay the video, upgrading the firmware, and so on.

554, 8554 - RTSP

RTSP stands for Real Time Streaming Protocol. If it’s enabled, one can watch the video stream directly from the encoder.

1935 - RTMP

Recon Instruments Port Devices Driver Download For Windows

Real Time Messaging Protocol, another way to deliver video

5150 - serial to TCP

Mysterious service. netcat connects but the server does not seem to react to any input

This initially puzzled me, but when playing with devices from other vendors I noticed that some firmwares allowed control over this port:

9588 - another web server

This one is nginx, but not exactly clear what it is for.

Firmware analysis

Clicking around the web interface, I noticed the backup feature:I immediately went ahead and backed up (i.e. downloaded) both the firmware and the configuration.

Content

The firmware backup is a RAR archive that can be easily unpacked:

Here is the directory structure:

• disk: empty
• ko: kernel modules (device drivers)
• lib: empty
• nginx: nginx executables and configuration
• web: static content (html, js, css…)

The most important things are in the root of the archive:

In addition to some general utilities ( hostapd, png2bmp, remserial, wpa_cli, wpa_supplicant) it contains the custom web application box.v400_hdmi which is a compiled binary:

This executable is the primary target of my research, and all the vulnerabilities were found in it.

Password file and telnet access

The firmware includes passwd file which is a standard Linux password file:

My initial thought was to crack the password by conventional means, but after thinking about it I had a better idea. The password file is copied to the system by the run script, right before the main application is launched:

To my understanding this run script executes upon device boot, so all I need to do is following:

1. Generate my own passwd
2. Repackage the firmware
3. Upload the firmware to the device
4. Reboot
5. Try telnet with my own password

Generating a password hash is easy with openssl passwd command. Let’s set the password to “root”:

My new passwd looks like this:

I use WinRAR on a Windows VM to repackage the firmware, to be consistent with the original firmware that reported a downlevel archive version 4 and Win32 platform. I specify RAR 4 in WinRAR’s parameters:

I upload the “new” firmware to the device via the web interface, reboot, and voila:

Local recon

Now that I have full root access to the device, I can dump all sorts of stuff.

The base system

HiSilicon (a Huawei brand) is a Chinese manufacturer of specialized video hardware for IP cameras, NVRs, video over IP, and other devices. Their hi3520d is a popular SoC for different kinds of such devices. They run a specialized Linux distro called HiLinux.

Processes

Looking at this list, one can sort of reconstruct the loading sequence for the main web application:rcS → load → run → box.v400_hdmi

Indeed:

By manipulating these scripts, I could alter the boot flow, which was quite handy during reverse engineering and debugging later on. I modified /box/load to set a static IP address on my subnet, and commented out the execution of run script. This way I could have a clean shell after reboot where I could start the executable(s) I wanted the way I wanted.

Ports

Here is the answer on who listens on port 5150 - it’s remserial. Process info one more time:

remserial bridges a local serial port and a network port, allowing entities on the network to communicate with the serial port is if they were local on the machine. Hm… this doesn’t sound cool. I looked in dmesg again and found this:

I have to admit I’m not a hardware expert but I understand /dev/ttyAMA? are interfaces for the device’s UART. I searched for the UART specs for this board and found this PDF that I think may be helpful but I didn’t have much time to pursue this so I still don’t know whether this port exposure can be exploited and how. If someone wants to hack this, please do! (let me know what you find)

Dumping the file system

When sftp and rsync are not available, I like to use netcat to pull files from a remote systems. Luckily, nc is present on the device.

First, I start a tar archive process and pipe its output to nc listener on port 1337:

Now, pull the archive to my machine:

Reverse engineering

As I mentioned above, the main application is the executable named box.v400_hdmi on this particular device. Other devices may use other names. This app is a real workhorse - it listens on multiple ports, serves the web UI, and performs a bunch of low level tasks behind the scenes.

First, let’s see what threads it runs:

One thread that immediately looks suspicious is tty_read. Is this the one that handles ttyAMA1 via remserial? Let’s see which processes use the tty devices:

Argh… No, this thread seems to handle ttyAMA2 which is not exposed via remserial… OK, let’s move on.

Modifying the boot

I don’t necessarily want the target application to start automatically when the device boots while debugging. We can change that by disabling autostart through modifying the /box/load script:

Reboot, telnet, and behold a clean HiLinux. Now, let’s run the web app manually:

The application prints a lot of information to the console. I’m sure this will be very handy during reverse engineering and debugging!

The run script does some prep work before launching box.v400_hdmi. Let’s see if we can just run the application alone. Reboot again and do this:

It works! I guess it won’t stream any video but that’s OK for now. All I’m interested in at this point is connecting a debugger and exploring the program.

Remote debugging

When reverse engineering binaries, I want to understand what’s exactly happening at runtime. In other words, I need to be able to run the target program in a debugger.

To debug the program on ARM, I need to get gdbserver for ARM with the corresponding gdb for my Linux workstation. The best way to do it is to download and compile Buildroot toolchain. I’ve downloaded the latest, unpacked, and ran make menuconfig. I needed to change the following options from their defaults:

• Target options
  • Target architecture
    • ARM (little endian) … [obvious]
• Build options
  • libraries
    • static only … [so gdbserver doesn’t depend on any shared libraries]
• Toolchain
  • Enable WCHAR support … [for gdb]
  • Thread library debugging … [for gdb]
  • Enable C++ support … [for gdb]
  • Build cross gdb for the host … [yes!]
    • Python support … [for GEF - will explain later]
• Target packages
  • Debugging, profiling and benchmark
    • gdb
      • gdbserver … [need this for the target rather than the full debugger]

Save the config and run make. If everything goes well (i.e. you had all the prerequisites before compiling), your toolchain will be available in 10-15 minutes. Of course, we are not interested in the full toolchain, we just need the debugger stuff.

Telnet to the encoder and start netcat listener for file transfer:

On my workstation:

Now back to the encoder:

and back to workstation:

Good. However, vanilla GDB is not very useful for reverse engineering. Luckily, there are some add-ons that make a hacker’s life much easier. One of them is GEF. I’ve never used it before so I decided to give it a try. Unfortunately, GEF is based on Python3 but the buildroot debugger for ARM EABI only supports Python2. Fortunately, pytnon2-based GEF-legacy is available, and that’s what I’m going to use.

As you can see, the debugger’s output looks quite different! A lot of useful info out there! GEF automatically analyzes registers, follows pointers, displays strings, etc. Excellent!

Decompiling

Finally, I need to look at the code itself. I can just disassemble the binary with objdump but the result would be extremely difficult to comprehend. A better tool is needed. Ever since Ghidra came out back in 2019, I wanted to give it a try, and here is a great opportunity!

Download. Unpack. Run.

After creating a new project, I imported box.v400_hdmi into it, and Ghidra immediately began analyzing and decompiling it. It took a few minutes, but produced something I could actually work with:

Vulnerabilities and exploits

The juicy stuff. This section is the reason you are still reading this article :)

Backdoor password (CVE-2020-24215)

The first thing I looked at was the authentication function. Since I knew the default credentials (admin/admin), I used Ghidra to search for string 'admin' in the binary, and found a single occurrence of it.It is referenced twice in box_Authenticate()

To clarify: the name box_Authenticate did not come from Ghidra. Originally, this function was named something like FUN_00070114. Ghidra allows you to refactor the decompiled code by renaming things, so after confirming this was indeed the authentication function, I renamed it to box_Authenticate. All other box_ functions in this write-up were named in a similar way.

Here is the entire decompiled authentication function:

While looking at the 'admin' string in the program’s data section, I noticed a strange string right next to it:

It is referenced in box_Authenticate():

Here is what’s going on:

1. line 12: the user-provided username is compared against 'admin'
2. line 13: the user-provided password is compared against 'neworange88888888' if matched, return 1 (authentication succeeded)
3. line 16: the user-provided username is compared against 'admin' (again)
4. lines 20-24: the user-provided password is compared against the value from settings

This smells like a backdoor. Let’s try it!

But first, let’s divert a bit…

Recon Instruments Port Devices Driver Download For Windows 7

As I mentioned earlier, although the web UI uses digest authentication, it is not the only authentication method supported by the application. The following two methods are also supported:

• Basic HTTP authentication
• user/pass HTTP query parameters

I got these ideas from analyzing the function that calls box_Authenticate(). It is a pretty long function but it makes a few key decisions on what to allow and what to reject. I named this function box_ProcessRequest().

Here is an interesting excerpt from that function:

<rant> I wish Ghidra supported code folding so I could hide the irrelevant branch but it is still a feature request with no progress </rant>

Anyway… on line 257 it calls another function to check whether the authorization header contains 'Basic'. If so, the execution continues on line 280, where the header is first parsed and decoded, and then our familiar box_Authenticate() is called.

Here is the code in the same function that processes query parameters, user and pass:

To summarize, basic authentication and user/pass parameter pair are supported by the backend, and that’s what we are going to use to test the backdoor password:

Wrong password - no access (good)

request

response

Correct password - full access (good)

request

response

Backdoor password - full access (BAD)

request

response

root access via telnet (CVE-2020-24218)

The telnet daemon is running on the device by default, and there is no way to disable it via the official admin web interface. It appears that on some devices the above backdoor password is also set as the Linux root password, and remote login via telnet is possible. Furthermore, the password file format (crypt) only supports strings up to 8 characters, so instead of neworange88888888, one can just use neworang:

Some versions of URayTech firmware had the following password hash which corresponded to newsheen:

J-Tech firmware had this which corresponded to neworangetech:

Many thanks to Vladislav Yarmak who cracked these hashes!

In conclusion, these video encoders may be accessible via telnet with one of the following passwords:

Arbitrary file disclosure via path traversal (CVE-2020-24219)

Continuing through box_ProcessRequest(), I noticed an interesting conditional statement:If the condition is true, the control is passed to the file read and HTTP response routines. This looks like a way to identify static files so they could be served without authentication. Nothing wrong with that but note the find() method used - it will succeed if the substring is found anywhere in the resource name.

Another issue is that the resource name is not sanitized and is simply appended to the web root directory path. If the request contains ../ a file outside of the web root will be served to the user.

This means that if there is a directory with one of the above substrings anywhere in its name, I will be able to combine these two flaws and read any file from the file system.

On the devices from at least one vendor, URayTech, one such directory does exist:

Traversing from this directory, I can access any file on the file system using a path like this:/sys/devices/media/13070000.jpgd/../../../../<path-to-any-file>

To exploit these flaws, I can just use curl to read any file from the encoder, for example:

I can read the encoder’s configuration file /box/box.ini to retrieve the actual admin password, and get full admin access to the device:

Unauthenticated file upload (CVE-2020-24217)

Let’s continue looking through box_ProcessRequest(). Here is another interesting part:

The two compare calls compare against 'multipart/form-data'. This is not obvious from the decompiled code but I can see it in the corresponding assembly:

The most interesting part here is that these requests completely skip authentication. box_ProcessRequest() immediately passes control to box_MultipartFormData() without checking any authentication parameters!

Looking at the traffic in Burp Suite, I noticed POST requests with multipart/form-data used by two functions:

1. Firmware upgrade

2. Logo upload

The parameter name is upgrade in both cases, which suggests both requests are handled by the same code. Also, the URL itself does not really matter. It can be /SystemE.html, /SetNet.html, or simply /, and it will still get processed.

Arbitrary code execution by uploading malicious firmware

Unauthenticated firmware upload means an anonymous attacker can upload and run arbitrary code. I can just pack and upload my own up.rar, but then I’ll have to wait until the device is rebooted, or utilize the backdoor password to call the reboot endpoint. Can this be exploited at will, without relying on external factors or another vulnerability? The answer is yes.

Apparently, up.rar is not the only firmware upgrade type. The procedure that parses a file upload HTTP request checks for several “supported” file names:

load just updates the /box/load script, box.ini updates the settings file, and so on…

I am not sure what uk.rar is (maybe kernel/system upgrade?), but note the way it is processed by the application:

In other words, an attacker would just need to upload a RAR archive with a single shell script in it, and that script will get executed right away.

Here is such uk.rar:

This embedded script uk.txt contains a single command:

This command will open a netcat listener with a shell on port 1337, allowing an attacker to connect to the device as root and execute arbitrary commands in the shell.

Recon Instruments Port Devices Driver Download For Windows 8

1. Create uk.rar as follows:
2. Use curl command to upload the file to the device:

   Note that the command above does not include any user credentials, i.e. this is an unauthenticated upload.

3. Use nc (netcat) command to connect to the device on port 1337 and execute any commands as root. For example, you can retrieve the actual admin password stored in /box/box.ini:

The device will reboot when you disconnect the netcat session. This is working as designed - see the call to box_Reboot().

Arbitrary code execution via command injection

As I mentioned earlier, the admin can upload a logo image to be overlaid over the video stream. The supported formats are BMP and PNG. When the user uploads a PNG file, the server application invokes png2bmp utility to convert the image:

The command string is built using the user-supplied file name without any sanitization, so an attacker can use the semicolon to inject arbitrary commands to execute. Let’s try it in Burp first:

This worked - a remote shell was opened!

Alternatively, one can just use curl command to inject the command nc -lp 1337 -e sh

After the request is processed, use netcat to connect to the device on port 1337 and execute any command on the encoder as root. For example, you can retrieve the actual admin password stored in /box/box.ini:

Buffer overflow: definite DoS and potential RCE (CVE-2020-24214)

In my previous life as a C/C++ developer, I have seen many buffer overflows. I have even programmed some of them myself. Unintentionally, of course :) With a low level language like C/C++, with a lot of control over data processing and a large set of old-fashioned insecure functions, it is very easy to shoot oneself in the foot.

A classic way to cause a buffer overflow is to use a printf()-like function with formatting string and arguments, but not properly ensuring that the result will fit in the destination buffer. I searched for all occurrences of printf()-like functions in the decompiled code, and found several interesting ones like this:

box_rtspParseParam() parses the CSeq parameter string, and the pointer to the value is then passed to the sprintf() call. The result is put in acStack2064 buffer on the stack. Since the size of the buffer is fixed, this looks like a good candidate for a stack-based buffer overflow.

RTSP is a text-based protocol, and prior to this research I was not familiar with it at all. To understand RTSP, I ran VLC Media Player, pointed it to the RTSP URL of my device, and captured the traffic with Wireshark:

Now I have an idea of how to write an exploit, and it’s trivially simple. First, create a text file, let’s call it teardown-bof:

Notes:

1. Repeat the 0s about 3000 times.
2. The two blank lines at the bottom are mandatory.

Send this file to the RTSP server:

and observe the application crash on the device:

When I run it under GDB/GEF:

Multiple registers, including the program counter pc, are overwritten with the user supplied payload (0x30 or '0').

This allows an unauthenticated attacker to crash the application, effectively causing denial of service. The sole purpose of the device is reliable video streaming, so denial of service is a significant issue. The watchdog process will reboot the device in approximately 1 minute, but an attacker can launch the exploit once a minute, making the device completely useless.

The big question is whether code execution is possible. It appears that ASLR is enabled on all devices I was testing. Brute forcing stack base address is not feasible, as the application is very unstable after the overflow occurs, causing an automatic device reboot. The only thing that seems to be possible is combining this vulnerability with the Arbitrary file disclosure via path traversal (CVE-2020-24219). An attacker can read the process memory mapping information from /proc/<pid>/maps to get the stack address information and redirect the program flow to the supplied shellcode. On the other hand, with the arbitrary file read one can simply retrieve the admin password and get full access to the device, so stack overflow exploitation is moot at that point.

Unauthorized video stream access via RTSP (CVE-2020-24216)

While playing with the RTSP processing code, I noticed that the RTSP URL had no effect. In other words, I could set it to a secret string:

… but it would still be available via rtsp://encoder/0. Moreover, it would be available via any URL.

Here is the secret URL I set via the UI, and it works as expected:

However, the original /0 still works:

Moreover, for some strange reason, an arbitrary URL works just as well:

See the URL in VLC Player’s title bar:

Disclosure

I completed my research in mid-July 2020. The next step would be to notify the affected vendors so they could fix the issues.

Affected vendors

During my research, I had physical access to the following devices, and confirmed them to be vulnerable:

• Several models from URayTech (all vulnerabilities)
• IPTV encoder from J-Tech Digital (not vulnerable to telnet backdoor and path traversal)
• VeCASTER PRO from Pro Video Instruments (not vulnerable to telnet backdoor and path traversal)

However, similar hardware video encoders are manufactured/whitelabeled/sold all over the world by a multitude of vendors. After browsing through online stores, looking at product pages, reading documentation, downloading and analyzing firmware updates, I was able to identify several other vendors I believe are also affected:

Coordinated disclosure

I reported my findings to CERT Coordination Center (CERT/CC) who initiated the coordinated disclosure process. Together, we made several attempts to contact affected vendors, with very little success. Only one company, Pro Video Instruments (PVI), reacted promptly and took the report seriously. I would like to thank PVI for their cooperation.

Many thanks to Vijay Sarvepalli from CERT/CC for managing and coordinating the disclosure process!

Reaction

Shortly after the initial publication of this article and VU#896979, Huawei published a security notice explaining the sources of the software components in the encoders. They basically stated they were not responsible for the buggy application which was developed by a downstream vendor.

This downstream vendor happens to be a company called New Orange (site 1, site 2) which explains why the backdoor password is what it is. New Orange did not plan to issue a public statement, but their largest vendor Oupree did publish a security advisory. They claimed all the security issues have been fixed. I have not yet obtained a fixed firmware to validate the fixes.

Remediation

At the time of this publication, most vendors have not issued firmware updates to address the reported vulnerabilities. If you own one of these encoders, contact your vendor and ask for a fix. If a firmware update is available, ask the vendor to confirm whether all vulnerabilities have been fixed. If the fix is unavailable, or is partial, make sure the device is on a trusted network, no ports are exposed externally, and firewall rules block untrusted users from accessing the device.

Exploits

Although exploitations are trivial, I wrote and posted scripts on GitHub for:

• full admin access via backdoor password (CVE-2020-24215)
• arbitrary file disclosure via path traversal (CVE-2020-24219)
• RCE via upload of malicious firmware (CVE-2020-24217)
• RCE via command injection (CVE-2020-24217)
• RTSP buffer overflow DoS (CVE-2020-24214)

Conclusion

This research demonstrates a number of application vulnerabilities in devices from multiple vendors. These devices are based on the same hardware platform and share the same software API. While most vulnerabilities seem unintentional (i.e. coding mistakes), one of them stands out. The hardcoded password is an intentional backdoor, and cannot be explained by sloppy coding or lack of security expertise.

When we hear the term application security, we don’t necessarily think of a little device with some specialized hardware-based functionality. Likewise, the term internet of things does not usually make us think about application security. However, there is a huge overlap between AppSec and IoT. Virtually every device runs some kind of an operating system and some kind of custom code. Many of them listen on ports. Many allow administrative access. And unfortunately, the engineering teams behind these devices do not pay enough attention to security considerations around the software. As a result, flaws creep in, making the device owners vulnerable to many kinds of attacks. Complex supply chains and inadequate support make these vulnerabilities difficult to address. We will continue to see these bugs in all kinds of connected devices for the foreseeable future, but more published research will hopefully increase awareness and make the vendors take application security more seriously.

Links

• CVE ids

Updates

• 2020-09-16: cracked one of firmware’s password
• 2020-09-17: Huawei’s public statement
• 2020-09-20: posted exploit scripts on GitHub
• 2020-10-16: added Reaction section; more links; another cracked password

Credits: the bug image by Edward Boatman from Noun Project