Symbiote is a particularly nasty Linux rootkit, and we have the interesting case of two separate analysis releasing this week. Up first is [CyberMasterV] taking apart a very early sample of the malware. The primary purpose of Symbiote seems to be capturing SSH logins, and this version does so by hooking the Pluggable Authentication Modules (PAM) system to capture users logging in to the machine it resides on. It also watches for SSH and SCP binaries, and sniffs the terminal used by those binaries, thereby capturing outgoing credentials.
All this data gets packaged up as DNS queries and shuffled off to the Command and Control server. “Easy”, I hear you say, “just block DNS traffic to everywhere except a trusted DNS provider.” It’s more clever than that. The data is in the form of valid DNS subdomains. In full, it’s a DNS request to PacketNumber.MachineID.Data.px32.nss.atendimento-estilo[.]com, all appropriately encoded to be valid. Every request will be for a unique host name, so every request gets forwarded to the C&C controller, which does double duty as the authoritative DNS resolver for that domain. You might get some mileage out of blocking (or at least logging) very long DNS queries.
Symbiote also replaces the typical files and devices you would look at to find a potential problem. For instance, /proc/net/tcp is where the kernel reports open TCP connections. On an infected machine, a copy of this file is maintained by the malware, conveniently leaving out the connections resulting from the infections. Symbiote has a hook in fopen, so whenever a process tries to read this location, the read is redirected to the cooked version, neatly hiding the rootkit. This stealth feature is apparently also used to hide other malware from the same attackers that may be on the same machine.
Now let’s look at the second analysis, a joint effort from BlackBerry and Intezer. This is from a later sample of Symbiote, and there’s been some interesting evolution. The most notable is that it uses the Berkeley Packet Filter (BPF) to hide it’s traffic from packet captures. Since BPF filters run right in the kernel, this is a very powerful stealth technique. Symbiote even detects a run of ldd, which would list it as a running library. This, too, gets sanitized, making Symbiote very difficult to detect. It should be possible to use the rootkit features of Symbiote against it, for detection. For example, one of the file names that is hidden is apache2start. It should be possible to touch this filename, and then run ls on the directory that should contain it. If the new file is listed, you’re probably fine. If it’s missing, then there’s a good chance you have the rootkit running. We’ve reached out to the researchers for help confirming this simple detection technique, so stay tuned for an eventual update.
“Smart” Locks
Once again, when it comes to IoT, the S stands for security. The fun begins with a classic error, not actually doing SSL verification. So the firmware reaches out to an HTTPS server for operation, but will accept any certificate for that connection. Man-in-the-Middle is a lot easier in that case. And that MitM stance couples well with the next problem researchers from NCC Group found, a buffer overflow in JSON parsing. Put these two together, and sitting on the same network as the lock gets you code running on it.
For most of us, an attacker on the internal, or even IoT dedicated network, is already a disaster. There’s another attack chain that was discovered. The way this lock usually gets installed is with “keyturner” installed in a door, physically inaccessible until the door is unlocked and opened. The second half is the “keypad”, the public-facing piece where the code is punched in. In theory, that keypad shouldn’t be trusted by the keyturner hardware, and should just pass keystrokes over the BLE link. In practice, the keypad can send an unlock request without the code, and unlock the door.
This leads to the final element, accessible JTAG ports on the keypad. JTAG is a debugging interface for embedded devices, extremely useful for flashing firmware to otherwise bricked devices, as well as doing real-time debugging. It’s that last one that gets the job done here. Connect to the keypad’s JTAG port and grab the authentication data from memory. Then use a different device and the auth data to spoof the keypad and send arbitrary commands over the BLE link. Politely ask the keyturner to unlock, and it will. With a dedicated rig and a bit of practice, the whole process could likely be reduced to a few seconds. Oof!
The silver lining is that Nuki, the manufacturer of this lock, did a stellar job of handling the vulnerability report. Patches went out less than two months after the issues were reported. Active customers were sent notices, and then after an appropriate period of time the vulnerabilities were publicly disclosed.
Your Server Is Compromised
You get a call or email from your hosting company, Linode in this case, that your hosted server is participating in a DoS attack. You’re likely Pwned.
What’s next? Researchers from Trunc have some tips. First off, it’s helpful to have something like sysstat running, a system statistic collection daemon. Next up is SSHing to the machine, and running through some tools. last shows the machine’s login history, top lists CPU and memory use ordered by process, df shows free disk space, ps lists running processes, and lsof shows the list of open files. Unless you’re dealing with a really nasty rootkit, like Symbiote discussed above, these tools should turn up something unusual. If sysstat has been running, sar -n DEV gives some data about network usage over time. If this machine is sending out a bunch of traffic, it should show up here, giving you a good idea when things started.
The system in question showed a big traffic spike, and the apache binary was running very high CPU usage. That seemed odd. The logs had a few entries indicating a call to POST //xmlrpc.php HTTP/1.1. While this endpoint can be abused for DDoS reflection, there weren’t enough log entries to suggest that problem. So up next is looking for modified files. There are options for this, like OSSEC, but they need to be run on the machine in a known-good state. So how do you check for tampered files if you don’t have that in place? If you’re running WordPress, you can just download and unpack a fresh copy of the install tarball that matches your installed version. Unzip it, and use diff to find any differences. One of those differences just may be a webshell injected into one of the WordPress PHP files.
REstringer Deobfuscates Javascript
As a hacker, one of the more irritating problems is obfuscated code. Javascript is inherently open, but obfuscation techniques makes the source totally unreadable. [Ben Baryo] is working on a solution, a deobfuscator he calls REstringer. It tries to match what sort of obfuscation is being used, and then loop through safe deobfuscation methods. There’s an important caveat there. It can be very difficult to deobfuscate code without accidentally running portions of that code. It’s still an active work-in-progress, so check out the code, or try the live demo.
UEFI Rootkits
There’s something of a Boogeyman in computer security, the mythical malware that embeds itself in a computer’s firmware, making removal impossible. While it’s theoretically possible that a motherboard’s firmware could be tampered with in this way, surely that’s only a myth, and maybe gets used by state actors for their most important targets.
That theory has taken a hit, as a rootkit that uses exactly this technique has shown up in the wild. Researchers at Kaspersky have dubbed it CosmicStrand, and note that infections were found in China, Vietnam, Iran, and Russia. Some hints in the code suggest a Chinese origin, and a possible connection to other malware also originating from that region.
Technically, using malicious firmware to bootstrap a re-infection is quite a feat. First, keep in mind that this code runs as the machine is initializing, long before the Windows OS begins running. How does the rootkit code manage to perform a sophisticated infection when its own execution ends long before the Windows kernel starts executing?
It implants code in the Windows boot manager, which in turn puts hooks into the Windows OS loader. This loader is part of the Windows boot process, and allows more manipulation to be targeted against the Windows kernel itself. And finally, once the kernel is booted, this payload deploys the actual shellcode. The sophistication of this malware is quite surprising.
0 Commentaires