Comments

QnJ1Y2U • November 19, 2013 7:24 AM

In addition, the malware made use of the Blowfish encryption algorithm to encrypt uploads of stolen data or other communications with a command-and-control network.

The Fokirtor authors stole well…

Peter A. • November 19, 2013 8:03 AM

The articles are unclear as to what is the mechanism exactly. It “inserts” the code into sshd (by some shared library). That’s clear. It “monitors traffic” – what and how? Does it monitor SSH connections only (after decryption) or all traffic (think tcpdump)? The article mentions that attackers can embed control sequences in “other protocols” so it looks like it’s monitoring everything. The results of the control sequences are “sent back”. I can imagine how it works for control sequences embedded in SSH command (shell) channel – extract the sequence from the input and inject result into the output path of the channel – but what about control sequences embedded in “other protocols” – where to put the result? What if the “other protocol” uses security layer (SSL/TLS etc.)?

It also assumes that attackers must keep an SSH connection to the attacked system from outside. It is suspicious by itself – unless the targeted system is a shell account hosting, or the whole thing is insider job.

stvs • November 19, 2013 9:18 AM

It also assumes that attackers must keep an SSH connection

No. You can send whatever you want in a SYN packet. Try this:

$ sudo tcpdump -n -e -ttt -X -i lo0 ‘port 22’ &
$ sudo nping -c 1 –tcp -p 22 –data-string “foo” localhost

listening on lo0, link-type NULL (BSD loopback), capture size 65535 bytes
00:00:00.000000 AF IPv4 (2), length 47: 127.0.0.1.34438 > 127.0.0.1.22: Flags [S], seq 3364671945:3364671948, win 1480, length 3
0x0000: 4500 002b 2686 0000 4006 0000 7f00 0001 E..+&…@…….
0x0010: 7f00 0001 8686 0016 c88c d1c9 0000 0000 …………….
0x0020: 5002 05c8 b5b2 0000 666f 6f P…….foo

The victims sshd was reprogrammed to look for not “foo”, but colon, exclamation mark, semi-colon, period (“:!;.”), then parse the encrypted payload that followed.

Secure firewall rules would detect the nasty C&C and block it in evil.hosts before too many packets could be sent.

Peter A. • November 19, 2013 9:53 AM

@sts: they could do a ‘blind execute’ this way, but how to exfilter data? Also, as you say, this should be blocked and is suspicious as well. It is less evident than an established SSH connection, indeed.

Brian M. • November 19, 2013 10:10 AM

This sort of thing has actually been going on for a number of years. When I first heard about it, I did a search, and got a lot of hits stretching quite a ways into the past.

It appears that the systems in question were compromised through other methods, and the attackers uploaded the trojan and then went their evil, merry way. The admin weren’t duped into installing it.

jackson • November 19, 2013 11:15 AM

The TrueCrypt audit project has been in contact with the development team. The developers apparently welcome the audit but, as they have emphasized all along, PLEASE READ THE MODEL. Please read the list (ie disclaimer) of what TrueCrypt DOES NOT claim to do.

Probably, the audit will serve to clean up the build and may, perhaps, uncover some implementation weaknesses, but not find any backdoors from the NSA or anything like that. If it did… well, I will leave what would happen up to your imagination.

For users, forget the audit. Pay attention to what TrueCrypt says in the disclaimer. Because this is true for ANY encryption application. It’s like saying “there won’t be any errors, as long as you don’t make any mistakes.” Like the Linux fanboys who like to compare the kernel to a WinTel machine running a bunch of applications while connected to the Internet. Yeah, don’t connect to anything, don’t use a browser, don’t install or run any applications, don’t use a keyboard or a mouse… and everything will be alright.

e790c6a8f4557f31c27d3833123a88f38c9cc06d7e95c586743bd46c15751f07 • November 19, 2013 2:43 PM

It would be great if we knew how the malware was installed in the first place as well as who the affected hosting provider was.

Wael • November 19, 2013 4:30 PM

@David Falkner

Gee, I wonder who could have designed something like this?

If it were called “Falknator”, I would guess it’s You 😉 — then again, maybe it’s you anyway!

Anura • November 19, 2013 4:37 PM

@David Falkner

This one isn’t that sophisticated to really suspect any specific major players. It injects code into OpenSSH – injecting code into binaries is what coined term “virus” in the first place. There is nothing mentioned about vulnerabilities, so it’s possible that it gets introduced through social engineering or an insider. Really, any decent malware designer could have done it.

Brian M. • November 19, 2013 4:40 PM

@David Falkner:
Gee, I wonder who could have designed something like this?

Anybody competent. I mean, actually competent with C programming and protocol knowledge, which actually includes a lot of people. It wouldn’t take the NSA to do something like this. Many moons ago I wrote a utility in assembly to allow complete BIOS interaction between two machines.

I imagine that systems which weren’t updated to the very latest and greatest were targeted. That happened at one company where I worked, where the sysadmin had opened up SSH on his machine so he could work at home. As it happened, he was running an older version of SSH with known holes and exploits for them. So a hacker with a German IP address came in and mucked around with his system. He found out the next morning because his certificates were hosed, so when he came in he found out all of the things that had been done. The intruder was clever enough to cover some of his tracks, but forgot about the history file.

syncedlogic • November 19, 2013 8:33 PM

do we have info on where the C&C server is hosted? this smells like classic NSA/CIA….think STUX..

Wael • November 19, 2013 9:05 PM

@ e790c6a8f4557f31c27d3833123a88f38c9cc06d7e95c586743bd46c15751f07

Would be intresting to find out whoes Cryptogaphic (SHA2)’s Sockpuppet you are 😉

Mike the goat • November 19, 2013 9:13 PM

e790: yeah, that’s the thing. This isn’t that impressive and isn’t really a traditional Trojan if they didn’t fool someone with root privs into executing it. My bet is they hacked into the boxes via traditional means (vulnerabilities, bad account policies) and just used this as a more covert alternative to a bindshell.

lisa • November 19, 2013 9:18 PM

No platform is safe from malware, including Linux. But Linux (and of course *BSD) is still a lot safer than Windows and Mac-OSX, if only because it is a smaller target, has had a lot more independent people reviewing its source and binaries, and its users are typically more security aware.

Although this is off topic, unfortunately TrueCrypt does not work with Full Disk Encryption on any new PC, since these are now all UEFI based. They should have delayed the TrueCrypt audit until after it works on current systems. Especially when you consider that BIOS based systems are being depreciated. It is like doing an audit on outdated C64 software. Sure TrueCrypt container support is great, but without full disk encryption, the TrueCrypt keys for these containers can be found stored on the drive, in swap and hibernation.

Any recommendations for alternatives Full Disk Encryption software for UEFI systems? Preferable open source or at least based in a safer country outside of North America, Britian, China, etc.?

Wael • November 19, 2013 11:08 PM

@ lisa

but without full disk encryption, the TrueCrypt keys for these containers can be found stored on the drive, in swap and hibernation.

Check their documentation under “Hibernation File” for workarounds and special setup instructions, including disabling hibernation.

Gweihir • November 19, 2013 11:59 PM

Actually, this looks like a rather primitive data exfiltration technique, to be used in the presence of a firewall that allows ssh-outbound.

Primitive, because it uses a static, plain-text marker that is easy to detect once known. If they had done this right, they would have used a marker that was encrypted, e.g. a block that when decrypted with the right key yields a specific pattern. Such a pattern could be something like the first half and the second one added together give a specific number or the like. There would be no way to detect that easily in the network traffic, and if it was done with public-key methods, it would basically be impossible to detect.

In addition, the firewall-setting strikes me as insecure too. If you want to prevent data exfiltration, you do not allow outbound ssh or force it to go through an application-level proxy, both which would prevent this method from working.

My take is that this is not very sophisticated, but rather something that a reasonable Linux programmer can write in a week or so. What is interesting is how it got in there. My bet would be a non-secured update mechanism (i.e. some distro not using or using insecure or compromised package signatures) and a connection-misdirection or MiM attack. Again, nothing sophisticated, just something that needs expensive resources.

Mike the goat • November 20, 2013 12:32 AM

Wael: I guess you could write a little script to pull the last I dunno 100 pages from the site and then grep out the commenter names and run them through sha256 to see if you get a match. 🙂

Kevin Lyda • November 20, 2013 1:14 AM

Re: the weird truecrypt thread that’s in here for some reason: Surely step one in securing a system is disabling UEFI since no secure OS supports it in a reasonable way?

65535 • November 20, 2013 1:29 AM

Hum, this thing has a low number of targets:

[Symantec]

• Number of Infections: 0 – 49
• Number of Sites: 0 – 2

I wonder who and how it was introduced.

[The Register]

“May of this year, sophisticated attackers breached a large Internet hosting provider and gained access to internal administrative systems. The attackers…[got] record information such as usernames, emails, and passwords. While these internal administrative systems had access to customer records, discovery of the attack and certain security implementations mitigated the scope of the breach. Customer passwords were accessible, but these passwords were hashed and salted making mass password cracking difficult. Customer financial information was also accessible, but encrypted. Unfortunately, access to the encryption key cannot be ruled out…”

“After seeing this pattern [ :!;. Base64 string], the back door would parse the rest of the traffic and then extract commands which had been encrypted with Blowfish and Base64 encoded.”

There is not enough information to tell if the vector of infection was outside of the perimeter firewall or an inside job (infected usb stick, a pwnd hosted sites or the like).

Next, I a saw The Register’s article “Antivirus bods” where Bruce signed an open letter to AV makers which asks them to say whether they helped the NSA.

It’s interesting that no NSA key loggers such as Magic Lantern or CIPAV have been discovered (or at least named).

“The keystroke-logging Trojan, dubbed Magic Lantern, reportedly enabled investigators to break PGP-encoded messages sent by suspects under investigation by using malware to capture a suspect’s passphrase. Magic Lantern samples were never captured – or at a least never identified as such.”

http://www.theregister.co.uk/2013/11/05/av_response_state_snooping_challenge/

lisa notes: “Sure TrueCrypt container support is great, but without full disk encryption, the TrueCrypt keys for these containers can be found stored on the drive, in swap and hibernation.”

Wael links a work-around for the hibernation file. But, what about the swap file? Should you dump it at shut down?

I agree with lisa that UEFI is a serious problem as is iAMT. UEFI boards are being forced on customers. Is this more NSA weakening of security or back-doors?

Kexec • November 20, 2013 2:16 AM

@65535 “But, what about the swap file? Should you dump it at shut down?”

My proposal: Divide the disk in two partitions.

Encrypt the first partition with Truecrypt, then setup LVM that hosts all partitions of a Linux installation.

Install in the second, small, partition, a swap-less Linux that is booted by UEFI, that asks for the Truecrypt key, then uses kexec to boot the first partition.

Mike the goat • November 20, 2013 4:20 AM

Keith: re the Truecrypt tangent that this thread has taken – yeah it is amusing to think that UEFI was billed as being a boon to security and many including Microsloth said it would be the end of bootkits thanks to “secure boot”. Unfortunately UEFI has been an unmitigated disaster and has only increased the attack surface area. Not only that but secure boot potentially stifles innovation and could result in much the same as what we’ve seen on ARM with their locked bootloaders where PC vendors will sell boxes locked to only boot Windows. I know MS has offered to sign a shim loader, blah blah blah but this kind of defeats the point of having it in the first place.

A much simpler solution would be – at OS install – the installer calls an interrupt that tells the BIOS that it wishes to reset the hash, and the machine then reboots and the BIOS displays a screen telling the user that the boot loader is about to be changed and not to agree to the dialog unless they know what they’re doing. If they agree a hash is calculated on the bootloader and the OS is booted as normal. All subsequent bootings will check that the hash matches before executing the boot code. The boot loader would be responsible for ensuring the integrity of any second stages or the kernel itself (most likely through code signing).

A solution like this gives the same benefits of secure boot but without the vendor lock-in consequences. Another critical change would be to disallow flashing the BIOS from the OS. Include a flashing utility in the BIOS setup and force users to use it and only it. Obviously if a PW is set it must be entered to get into the setup or update the b/loader hash. Seems like a simple plan.

It is such a shame that a perfect opportunity to modernize and improve the security of the platform was destroyed, again by committee logic. Too many cooks in the kitchen, too many architects so to speak.

Re true crypt: I don’t trust TC for social reasons more than technical. Nobody has put their names (and thus their reputation) to the code, nor do we know who is behind the shadowy TC foundation. Seems awfully fishy to me. Then again you could counter-argue that nobody signs their name to protect users against coercion of the developers. This doesn’t really fly as it would be trivial for the govt to ask the SEC as to who is behind their front. Even after this audit is completed I won’t trust it. A strategic bit of code can be very difficult to spot and the auditors are only human.

name.withheld.for.obvious.reasons • November 20, 2013 6:44 AM

@ Mike the Goat
AMI BIOS versions up in to the mid 90’s performed as you suggest. At boot if the boot signature had changed a message was issued indicating that a changed had occured and gave the option of confirming the modification. IBM, in early 2001, released an “Engineering” version of their ThinkPAD that came with a dedicated cryptographic engine that handled the BIOS.
The behavior, only a secured access to the device, that managed the onboard firm(wet)ware image and any submitted BIOS sources. I didn’t get a chance to fully flush it out and I don’t believe it went into production. Also worked on IBM’s PPC platform (9 scalar processor units on a daughter board prior to release) that provided a useful and trace-able CPU/MMU/FPU/DMA/BEU architecture (their Power PC). Not that I’m a shill for IBM…
SGI has produced some impressive platforms–their boards are the most beautiful I’ve had the pleasure of evaluating. Their work with Irix and their O2 and MIPS implementations are something to see (R4000). Irix and their firm(wet)ware were tightly coupled–masterful work. And, I am not a shill for SGI.

Bryan • November 20, 2013 8:26 AM

This isn’t that impressive and isn’t really a traditional Trojan if they didn’t fool someone with root privs into executing it. My bet is they hacked into the boxes via traditional means (vulnerabilities, bad account policies) and just used this as a more covert alternative to a bindshell.

Why? Forgetting about 0 day privilege enhancements? Yeah, many privilege enhancement exploits have been fixed, but I’m betting there are still a number to be found.

Found a program called flashrom when trolling through synaptic package manager. Ir reads and writes various FLASH BIOS chips. The urjtag program also looks interesting.

Brian M. • November 20, 2013 2:04 PM

Well, I don’t know about how Fokirtor was installed, but there is this: New backdoor worm found attacking websites running Apache Tomcat from Ars Technica.

I know that earlier this year Amazon forbade anyone from running Java client within the browser due to all of the security holes. Every time somebody comes up with a new fill-in-the-blank to solve security problems now and forever, it just winds up being an illusion. At least this one requires bad passwords to propagate.

only human • November 20, 2013 11:03 PM

“Re true crypt: I don’t trust TC for social reasons more than technical. Nobody has put their names (and thus their reputation) to the code, nor do we know who is behind the shadowy TC foundation. Seems awfully fishy to me. Then again you could counter-argue that nobody signs their name to protect users against coercion of the developers. This doesn’t really fly as it would be trivial for the govt to ask the SEC as to who is behind their front. Even after this audit is completed I won’t trust it. A strategic bit of code can be very difficult to spot and the auditors are only human.”

The same could be said for TAILS.

Their new users mailing list feels secretive and is not archived. Ask about Tor which is central to the TAILS project, they tell you to go to Tor’s tor-talk mailing list. Bring up TAILS on tor-talk because they won’t answer you correctly on the secretive TAILS mailing list (or they just ignore you) and they tell you to go to the TAILS mailing list.

Scott Ferguson • November 20, 2013 11:33 PM

@only human

Ask about Tor which is central to the TAILS project, they tell you to go to Tor’s tor-talk mailing list. Bring up TAILS on tor-talk because they won’t answer you correctly on the secretive TAILS mailing list (or they just ignore you) and they tell you to go to the TAILS mailing list.

Ask the guy who makes fruit pies about apples – he’ll refer you upstream to the apple grower. Ask the apple grower about fruit pies and he’ll tell you to ask the pie maker.
By your damaged logic the pie maker and the apple grower are part of some conspiracy. The analogy doesn’t provide source code – TAILs and TOR do. That you can’t read it doesn’t oblige anyone to read it for you – or give your assertions any credibility.

TOR ain’t “central” to TAILs no matter how you wave your hands.

That programmers don’t give their names (or use pseudonyms) is a strawman.

It’s the code – not the coders.

As for “the mailing list feels secretive”. Security is not intuitive. And “gut instincts” are almost always wrong when tested.

Wael • November 20, 2013 11:35 PM

@Mike the goat

I guess you could write a little script to pull the last I dunno 100

I did it the manual way, did not think of writing a script (maybe because I no longer have MY laptop). Tried the usual suspects to no avail. I even tried to analyze the writting style, but there wasn’t enough words…

Wael • November 21, 2013 9:58 AM

@c5236b05327b551ffc4c08c0a2361477db81d0a6602471aefacb40e62b4bb60a
It’s no fun to use trial and error o find what you hashed. In fact, trial and error is not accurate. It’s guessing, with small clues you’re giving me. And I haven’t the slightest clue…

Mike the goat • November 21, 2013 8:31 PM

Wael: if I had a prize, you’d get one! I guess another problem is you don’t know if they are hashing the string or the string followed by a LF, or the string followed by a CRLF, etc. As for the OP’s hashed identity – no idea. I’ve run the usual suspects to no avail.

j2112 • December 30, 2013 12:55 PM

So who/what is vulnerable to this? Specific / older versions of SSH server? Local access to the servers?
What about forcing key auth?

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.