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.
Sooo russian Kaspersky is now part of the good guys?
I wonder if the malware that “originated in China” and infecting Chinese computers as well as other countries, may have been planted there in much the same way as Stuxnet?
B^)
I had that thought, and I’m sure the researchers here did, too. What’s missing is a pattern, where high value targets or a certain industry was targeted.
Nobody knows.
(Originally replying to whether Kaspersky is “good”, but honestly it goes just as well for malware attribution.)
Edsger Dijkstra has a famous quote saying that testing can prove the presence of bug, never the absence. In the same way it’s impossible for a company to prove that you’re not spying for a nation state.
Lawyers put it this way:
“Absence of evidence is not evidence of absence.”
I wouldn’t run their antivirus, especially were I a defense contractor. But their research here seems solid.
Okay! That’s it! I’m disconnecting all my computers from The Internet and never coming back!
B^)
This stuff is too complicated for us mere mortals to understand, much less nullify!
Agreed, at one time I had a tentative grasp on this stuff, but now its an alien language, I don’t understand a word of it anymore, Each week I read the articles the further behind I get. where will this all end?.
Yep. Used to be that my C/C++ and java abilities meant I was top of the heap among people I know. Not anymore. There are quite a few things I have read that leave me confused. I wonder how much knowledge I would have had I started earlier in life.
Only a C head would say “top of the heap” 😂
Surely if software A can install itself in the firmware somewhere then software B can also install itself there, thus removal is not actually impossible? Difficult, maybe, but not impossible. Genuinely interested.
Legit firmware supports updates as a feature. Malicious firmware may disable the update function. It’s really hard to re-establish trust, once it’s been so thoroughly broken.
Firmware isn’t always even writable, so it could be shipped to you borked and compromise your systems higher levels and nothing can be done but rip that system with the broken firmware out of the computer, maybe repairable with skill and a clean firmware on a replacement chip, but in general…
And even when firmware is (as it most commonly is) updateable in some fashion, so can in theory be overwritten with good stuff its rarely that simple – the tools you would use to do the rewrite often require that same firmware you are updating to be in a working (and co-operative) state. Though in that case as the chip is rewriteable if there is a programing header or you are good with the fine gauge wire you can use an external programmer – the same way folks would rescue a bricked device from a failed BIOS update etc.
NB the bulk of the poison in this case isn’t in the firmware – it is just providing instruction to go get the really nasty bits.
Software A can disable all software update mechanisms. Then it’s not possible to get rid of it. Also, many computers (esp. microcontrollers) have security lock fuses that prevent software updates when they are blown.
Also the power controllers are often under software control so it is possible to reprogram them to cause damage to the hardware.
So the answer to your question is yes, it is indeed possible to cause permanent irreparable damage to a computer from software.
But surely software can’t change the micro’s own fuses, only an external programmer? Therefore even if there is malicious software on the chip (which disables or corrupts the software update feature) it ought to be possible to use an external programmer. Unless it’s not. I can see a decision being made not to bond out the programming pins, or not put a header on the board, but customers might start demanding it.
I think software running on the chip can blow the fuses, for most devices.
In this case, you’re on the right track with the external programmer. If you can remove the flash chip from the motherboard, and get it in a programmer, you can be pretty confident in the firmware you flash to it. But if you have to rely on the firmware itself for the flash, then you don’t really have a good root of trust.
I’m not sure I’d trust a device that shipped malicious even after hitting it with the programmer – it might seem just fine, even when read by the programmer give back the right response x times or something – but with how small firmware is and how cheap lots of storage and smarts are that chip could well have a bad and a good firmware image and it only needs to run the malicious one after the 100th read time or something equally long that you can’t realistically test for it. Even more so if its got the the RTC and a log to know when the last one was and so detect such attempts to brute force the bad image.
And with how small such logic and firmware data is, and how tiny really smart IC’s are getting can you be sure of every other IC not being able to reload and reflash the bios behind your back.
By the time you are 100% sure both the chip and the rest of the board itself are safe you have probably worn them out…
Now a device that shipped good but got a poisoned update I’d trust again after hitting it with the programmer – as it takes deliberate malicious hardware design to evade such a low level cleanup. Or at least I don’t know of any even thought experiment self restoring ways back from that on a genuine part.
Software can blow fuses, the Nintendo switch does with every software update to prevent downgrading. Sure there are ways to install an update without blowing fuses, but thats not the point.
>The silver lining is that Nuki, the manufacturer of this lock, did a stellar job of handling the vulnerability report.
Yeah. Maybe they handled the reports well, but it would have been MUCH better if they had shipped their stuff with secure software directly… I mean come on, not checking certificates and stuff like this are really noob errors. Maybe they should hire better programmers… Obviously in this case it’s not toooo bad, IoT can be avoided easely at home, but the same problems apply for almost every device/firmware/software/… It’s scary.
Sure, and your sausage vendor could easily ensure that nothing nasty got into the sausage, too. Just, maybe not for the price point you’re willing to pay…
Am I going to have to change my handle again?
B^)
Obviously, you have never been employed by a software engineering company. Blame the management, not the programmers. I am sure that the Nuki had a deadline for the programmers and kept pushing for more features to be completed. “Sir, there is not enough time to implement all the SSL/TLS safeguards” “We have to deliver something to upper management by the end of the week peon…” that sounds about right…