One of the fun things about vulnerability research is that there are so many places for bugs to hide. Modern devices have multiple processors, bits of radio hardware, and millions of lines of code. When [Veronica Kovah] of Dark Mentor LLC decided to start vulnerability research on the Bluetooth Low Energy protocol, she opted to target the link layer itself, rather than the code stack running as part of the main OS. What’s interesting is that the link layer has to process data before any authentication is performed, so if a vulnerability is found here, it’s guaranteed to be pre-authentication. Also of interest, many different devices are likely to share the same BLE chipset, meaning these vulnerabilities will show up on many different devices. [Veronica] shares some great info on how to get started, as well as the details on the vulnerabilities she found, in the PDF whitepaper. (Just a quick note, this link isn’t to the raw PDF, but pulls up a GitHub PDF viewer.) There is also a video presentation of the findings, if that’s more your speed.

The first vuln we’ll look at is CVE-2019-15948, which affects a handful of Texas Instruments BT/BLE chips. The problem is in how BLE advertisement packets are handled. An advertisement packet should always contain a data length of at least six bytes, which is reserved for the sending device address. Part of the packet parsing process is to subtract six from the packet length and do a memcpy using that value as the length. A malicious packet can have a length of less than six, and the result is that the copy length integer underflows, becoming a large value, and overwriting the current stack. To actually turn this into an exploit, a pair of data packets are sent repeatedly, to put malicious code in the place where program execution will jump to.

The second vulnerability of note, CVE-2020-15531 targets a Silicon Labs BLE chip, and uses malformed extended advertisement packets to trigger a buffer overflow. Specifically, the sent message is longer than the specification says it should be. Rather than drop this malformed message, the chip’s firmware processes it, which triggers a buffer overflow. Going a step further, this chip has non-volatile firmware, and it’s possible to modify that firmware permanently. [Veronica] points out that even embedded chips like these should have some sort of secure boot implementation, to prevent these sort of persistent attacks.

NEC Phone Systems

This story was sent in directly by [Austin Martinetti], who worked on this research with [Brett Bryant]. They took a look at an interesting platform, NEC phone systems. What did they find? A handful of issues, like a hard coded username/password, and an HTTP endpoint that resets the user passwords to default: PasswordReset.htm?PWD_RESET() What can you do once you have access to the web interface? How about a hidden endpoint that downloads voicemail messages. For the impatient, there’s even a quick-and-dirty script to automate the process of downloading the entire backlog of voicemails. Next up is the really interesting developer level account. Doing just a bit of manipulation of POST data in your web browser allows modifying an account to have a privilege level above administrator.

All this is interesting, but we know better than to ever expose the web interface of an embedded device to the internet. So long as it’s inaccessible to the outside world, we don’t have to worry about these bugs. Right? It seems that when NEC built their voicemail add-on, they built in a slick little hidden feature. On extension 740, an old-school dial-up modem is available. Any valid credentials from the web interface can make the connection and gain access to the system, including some undocumented services.

These vulnerabilities were privately disclosed, and updated firmware is available (PDF). If you happen to have NEC phones sitting on your desk, it might be worth trying to get the firmware updates applied. And for goodness sake, don’t put your phone system’s ports on the internet!

Tor Exit Nodes

Tor is a boon for anonymity on the Internet, but have you ever looked closely at the potential downsides? Tor is a clever mesh network that uses layers of encryption to strongly anonymize traffic by sending it through multiple relays, and finally out to the regular internet through an exit node. That exit node is the weak point of the Tor network, in multiple ways. Because of the sometimes malicious or illegal traffic sent through Tor, exit nodes are often targeted by law enforcement or network operators. These nodes are a weak spot for another reason — the exit node gets to inspect and potentially modify all the traffic that goes through it.

This shouldn’t be a problem, as we have TLS to protect against MitM attacks. There is a clever attack that can get around TLS protection, SSL stripping, notably introduced by [Moxie Marlinspike] in 2009. The idea is simple: when a user tries to access a website using HTTP, and the site returns a redirect to an HTTPS connection. The attacker intercepts this redirect and proxies the HTTPS connection, leaving the user on an unencrypted connection. This attack is of limited usefulness, as web browsers will remember a permanent redirect, which is why it’s considered best practice to use the “301 Moved Permanently” redirect for enforcing HTTPS connections.

That said, how many of the current Tor exit nodes do you think are malicious? According to [nusenu], at one point almost 25% of the Tor exit node connections were using malicious exit nodes. This isn’t an easy problem to solve, as the vast majority of exit nodes are run by volunteers. When these malicious nodes are found, many of them are removed at once, but it’s relatively straightforward to shuffle the names and IPs and get those nodes back into the network. It’s estimated that right now, you have a 10% chance of using a malicious exit node when you use Tor. It’s known problem, and it’s slowly being worked on, but currently the Tor project doesn’t have the resources to really tackle the issue in earnest. If you’re going to use Tor to access outside sites, make sure to specifically check that your connection is a valid HTTPS connection.

A Red Team Story

Some of the best stories in infosec come from the red teams doing penetration tests. This week, [Federico Lago] shares some stories and tips from a recent successful pentest. The single best tip in the write-up is to try scanning ports while specifying the source port as a commonly used port. Apparently many firewalls are misconfigured to allow incoming traffic from these ports, when the intention was to allow outgoing traffic.

The second tip is that the Simple Network Management Protocol (SNMP) can be incredibly powerful for leaking information about a system. It’s not a TCP service, so it’s easy to miss, but it’s worth the effort. There’s a lot of potential information to be gained, including the list of processes and their command line arguments. In this case, a valid username/password combination was found for a Jenkins instance discovered earlier. Jenkins can be configured with a “script console” enabled, and it’s possible to abuse this to get a reverse shell and access to bash.

Part 2 continues the story, detailing how they used a command available to run using sudo in order to get a root shell, and then used the same SNMP trick to access the company’s databases. The whole thing is a good read, so go check it out.

Bits and Bytes

Ars told us about FritzFrog, a new Linux botnet client that spreads through poor SSH password policy. The technical report by Guardicore, has the juicy details and the indicators of compromise. You might want to check your servers for an added ssh authorized key, binaries running from nonexistent locations, and a listening socket on port 1234.

Gmail’s DMARC/SPF protections can be short-circuited by using Gmail’s inbound gateway setting, together with a global mail routing setting in the G Suite’s administrative console. In essence, the inbound gateway turns off the SPF and DMARC check for mail coming from the specified IP address. Forwarding it through Google’s mail service does mean that the messages get signed by Google, so it then passes those checks. While there were some complications, the bug has now been fixed.

Kali Linux, formerly Backtrack, has minted their 2020.3 release. Most notable is the addition of a new set of Bluetooth tools. There is also the new “Win-KeX”, a persistent GUI for running Kali inside the Windows Subsystem for Linux.