RouterOS release 7.4beta4 introduced containers for MikroTik devices. From the changelog:

container - added support for running Docker (TM) containers on ARM, ARM64 and x86

It turns out that due to a couple of implementation flaws, it's possible to execute code on the host device via the container functionality.

I recently researched a relatively new 5G-capable modem from Quectel: the RG500Q-EA. I identified a security issue with how the OTA download procedure operates which allows an attacker to execute commands on the modem as root.

And habitually review the third party code you're using - even when it's in the standard library.

As I mentioned towards the end of my previous blog post, where I detailed running my blog on the PinePhone's GSM/WWAN/GPS modem, I suspected that the daemon responsible for parsing AT commands on the modem's side is susceptible to OS command injection, as it uses a lot of system() calls. My hunch turned out to be true.

No, really. Despite the timing of this article, this is not an April Fool's joke.

I recently lost the BIOS password for my Xiaomi RedmiBook 16. Luckily, viewing and even resetting the password from inside a Linux session turned out to be incredibly easy.

I recently purchased Xiaomi's RedmiBook 16. For the price, it's an excellent MacBook clone. Being a Ryzen-based laptop, Linux support works great out of the box, with one big caveat: deep sleep does not work. I decided to try and fix this.

You might've noticed I've been using a custom application for demonstrating vulnerabilities I've discovered on IOPSYS (Inteno) devices for the last few posts. This application is iopshell, which aims to provide an easy way of communicating with the backend of these devices.

In my previous post, I described running Arch on an OpenWRT router. Today, I'll be taking it a step further and running Arch and a full LXDE installation natively on an Amazon Kindle, which can be interacted with directly using the touch screen. This is possible thanks to the Kindle's operating system being Linux!

Here's some notes on how to get Arch Linux running on OpenWRT devices. I'm using an Inteno IOPSYS (OpenWRT-based) DG400 for this, which has a Broadcom BCM963138 SoC - reportedly ARMv7 but not really (I'll get to that later).

In Inteno's IOPSYS devices, and very possibly other devices running firewall3 (which is included by default on most OpenWRT-based firmwares), it is possible for an authenticated attacker to abuse firewall includes to remotely execute any binary or script as root. A proof-of-concept exploit can be found at the end of the post. This vulnerability has been assigned the CVE ID: CVE-2018-20487.

Unfortunately, generic IP cameras are notorious for their poor security practices. Most of the time, the manufacturers don't force secure passwords, and more often than not you can sign in with default passwords. Some do, though - one of these manufacturers is Hikvision. Upon logging in for the first time with the password 12345, it forces you to change it. Is this enough to stop attackers from accessing the device? Turns out it isn't.

In this blog post, I describe how multiple safe features and configurations can be used to gain full filesystem read-write access - and a root shell - on devices running Inteno's IOPSYS as an authenticated user. This issue has been assigned the CVE ID: CVE-2018-14533.

I have discovered yet another vulnerability in Inteno's IOPSYS firmware - but I believe this to affect all OpenWRT or LEDE based routers that ship with the printer server p910nd. Any authenticated user can modify the configuration for the printer server in a way which allows them to read and append to any file as root. This leads to information disclosure and remote code execution. This vulnerability has been assigned the CVE ID: CVE-2018-10123.

I've discovered a remote code execution vulnerability in the latest version of Iopsys router software. This affects all Inteno routers and is caused by the dhcp daemon. This vulnerability has been assigned the ID CVE-2017-17867 and a CVSSv3 severity score of 8.8.

A couple of days ago I wrote about CVE-2017-11361, which described abusing misconfigured Access Control Lists to gain root access to Inteno routers. Inteno has recently deployed a quick-fix, removing access to the file:read and all router.dropbear calls. Does this stop people with malicious intent from accessing the router?

Recently, while testing the security of Inteno routers, I found a misconfiguration in the Access Control Lists, which allows any authenticated user to see the contents of any file, write their own files and add an SSH key to the router, allowing for easy log in as root. By default, the consumer is only provided with the user account and the built-in support and admin accounts are not accessible. This vulnerability is dangerous as by default, the password for user is the same as the pre-set Wi-Fi key, or in some cases user, allowing for easy authentication. This vulnerability has been assigned CVE ID: CVE-2017-11361 and a CVSSv3 score of 8.8.

Soon after getting an Inteno DG301 router from my ISP Telia, I poked around the firmware trying to find out more about its internals. It became apparent that the iopsys firmware running on the machine was a customised version of OpenWRT. The modifications by Inteno include making it more fool-proof for consumers, removing any easy access to its internal settings in the process. It's not possible access SSH without proper keys, and Telnet is disabled, even in OpenWRT's failsafe mode. In addition to the provided user account, there are also the support and admin accounts, but the passwords for these are not known. I did manage to dump most of the filesystem by abusing an insecure default option in the router's bundled Samba and found a couple of other exploitable bugs, however, I still didn't have proper shell access or a way to invoke opkg to install my own packages.

I was doing some work with Burp Suite through Chrome (which I don't often do) and very soon I realised that all of my requests were being relayed to a domain edatasales.com. After probing around a bit, I narrowed it down to the Easy Auto Refresh plugin for Chrome, which currently has over half a million downloads. Disabling this plugin also stopped all requests to edatasales.com.

Since Braswell is still widely unsupported in the world of Chromebooks (no public Tianocore/Windows rom released yet), one can expect to run into many issues when developing for these Chromebooks.

One of these issues I encountered was being unable to flash anything internally after flashing a Tianocore rom. This seems to be an issue with coreboot, and until it is fixed upstream, you will get this message trying to probe the chip:

Programmer does not support specified bus
Error: Programmer initialization failed.