PDA

View Full Version : Linux wiper malware used in S. Korean attacks



leclerc65
March 21st, 2013, 04:30 PM
http://www.itworld.com/data-protection/349133/symantec-finds-linux-wiper-malware-used-s-korean-attacks

Yedrin
March 21st, 2013, 04:38 PM
"Another component, a BASH shell script, attempts to erase partitions Unix systems, including Linux and HP-UX."

Being a new linux user I am curious how and if this could be accomplished without "sudo" access.

Could someone here with more knowledge on the subject go into the specifics and is this something an average user should be concerned about.

Primefalcon
March 21st, 2013, 07:35 PM
no it'd prompt for super user access and ask for your password

SeijiSensei
March 21st, 2013, 07:56 PM
Tucked inside a piece of Windows malware used in the attacks is a component that erases Linux machines, an analysis from Symantec has found. The malware, which it called Jokra, is unusual, Symantec said.

Jokra also checks computers running Windows XP and 7 for a program called mRemote, which is a remote access tool that can used to manage devices on different platforms, Symantec said.

Of course the details are not actually described in much detail. It does sound like I'd have to be running a Windows computer that has mRemote installed, then mRemote would connect to some remote Linux box and, do what exactly? Prompt the Windows user for a login on the Linux box with root privileges? I never run servers that use sudo, so the Windows user would to explicitly log in as root with root's password.

The article doesn't say anything about how these credentials would be obtained. Perhaps it also includes a keylogger? I doubt any of this would work on any network where the Linux administrator had even an inkling of security knowledge. If that's the standard for IT in South Korean banks, the banks deserve whatever problems they may have.

Since the basic malware, "DarkSeoul," has been in the wild for over a year, the fact that it successfully infected banks would be a major worry to me if it were a depositor. Who's in charge of security at these banks?

Yedrin
March 21st, 2013, 07:57 PM
Thanks for the info PrimeFalcon and SeijiSensei (http://ubuntuforums.org/member.php?u=698195). I suspected as much but wanted to make sure.

Primefalcon
March 21st, 2013, 08:03 PM
the fact they said it runs a bash script means if your running a linux system, if your duelbooting it could access the hard drive from windows, and overwrite data at the metal level (below the partition).

but for those running linux solely (it'd ask for the password) or running windows in a vm (it would only affect the vm), not that big of a deal unless you give permission to anything without wondering why its asking for a password

Jonor
March 21st, 2013, 11:54 PM
I'd be highly suspicious if asked for a password out of the blue but if it suggested there were something like updates
and did i want to install them and then if yes to provide the password it would likely fool me if the request looked convincing.

neu5eeCh
March 22nd, 2013, 02:43 PM
Here's somewhat more of an explanation:

http://www.itworld.com/data-protection/349133/symantec-finds-linux-wiper-malware-used-s-korean-attacks

It doesn't sound as though a password was necessary?

DuckHook
March 22nd, 2013, 06:04 PM
It doesn't sound as though a password was necessary?

Password may not have been necessary to infect the Windows machine, but how can the bash script run without a password on the Linux end? It would either have to confine itself to files on the home directory of the unfortunate user (which is bad enough, I suppose), or use social engineering to look convincing enough to fool the user into entering password. That would be some script.

More likely, it's just a piece of classical Windows malware with a quick-and-dirty Linux appendage that attacks new and unwary users. Symantec highlighted the relative novelty of a piece of multi-OS malware but expressed no opinion on its virulence or likelihood of success.

It is possible for Windows malware to do limitless damage though, if the Linux OS resides on a dual boot or is a VM hosted by the infected Windows. But if so, why would the malware even need a Linux component? It could do all its dirty work from Windows.

Note that its point of attack is again another unpatched browser hole.

SeijiSensei
March 22nd, 2013, 06:50 PM
Do we really think some functionary in a South Korean bank is running a dual-boot Windows/Linux machine? I'm sure we can all spin scenarios where some thing bad might happen, but we are talking about large corporations with, presumably, highly-managed networks. Not some guy sitting at home in Seoul playing on a dual-boot machine and being distracted while watching Girls Generation (http://www.youtube.com/watch?v=exa5-P0_uKo).

prodigy_
March 22nd, 2013, 07:43 PM
BASH shell script

it'd prompt for super user access and ask for your password
ROFL. Well, then I can write "malware" too:

sudo bash -c 'for i in /dev/{h,s}d{a..z}; do (echo $i >/dev/null 2>&1 &) done'
(This is, of course, harmless. But anyone can see where it's going.)

Primefalcon
March 22nd, 2013, 07:51 PM
swap that out with the dd command or rm from from root.... and you'd have supposedly destructive malware according to those anti-virus companies

prodigy_
March 22nd, 2013, 07:56 PM
I'd be highly suspicious if asked for a password out of the blue
The problem is, more than enough harm can be done without asking for password. In the context of this thread: imagine a script that recursively overwrites every file in your home directory with random data. It's stupid easy to write one-liner that would do exactly that.

Moral of the story: always have an external backup.

DuckHook
March 22nd, 2013, 08:05 PM
Do we really think some functionary in a South Korean bank is running a dual-boot Windows/Linux machine? ...some guy sitting at home in Seoul playing on a dual-boot machine and being distracted while watching Girls Generation (http://www.youtube.com/watch?v=exa5-P0_uKo).

:lolflag:

Primefalcon
March 22nd, 2013, 08:33 PM
I agree you should always have backups, you also should never enter your password if it jumps up unexpectedly... for example if the update window pops up... and you click install updates, you know it popped up for what you just did... but if it jumped up for no reason..... never enter the password...

odiseo77
March 23rd, 2013, 05:08 AM
I don't know much about networking and even less cracking, but can't a cracker compromise a given system through the net taking advantage of any vulnerability on a remote machine's services? In this case, I guess they wouldn't even need a root password to infect the machine with some kind of malicious program (or they could probably find the password once they compromise the system). Someone please correct me if I'm wrong :)

Mr. Picklesworth
March 23rd, 2013, 08:55 PM
no it'd prompt for super user access and ask for your password

That's how nicely behaved software operates. Powerful malware, as a general rule, does not do that. Malware on Linux is not limited to asking for privilege escalation the nice way. System calls are very useful, here. When a program needs to allocate memory or open a file, that's a privileged operation so it asks the kernel to do it with a system call. Sometimes, a simple looking program might use an innocent, helpful system call like vmsplice, but twist its arm a little to create a buffer overflow in kernel space, which means arbitrary code execution, which means that simple little unprivileged program suddenly has Jedi powers. (The vmsplice vulnerability did happen. See here, if you're interested: http://lwn.net/Articles/268783/). This is why sandboxing in Chrome and newer Firefox, and stuff like Arkose, is a big deal. We already have a lot of functionality to limit a program to a specific section of the filesystem, but a significant part of this new stuff is to limit a program to a set of system calls, which reduces the attack surface for any malware. In the past we've had seccomp as a thin layer to provide that functionality, and seccomp-bpf does the same with a little more control. Chrome uses a broker process with a very strict policy for what system calls its children can run. When a browser process wants to run a fancier system call, it has to go through the broker.

With that said, sounds like this runs on a Windows host, and I'll bet the goal is to slow down antivirus tools that run from Linux environments. I just felt like clearing up a common misconception :)

koenn
March 24th, 2013, 12:30 AM
Here's somewhat more of an explanation:

http://www.itworld.com/data-protection/349133/symantec-finds-linux-wiper-malware-used-s-korean-attacks

It doesn't sound as though a password was necessary?

If you click through on one of the links in the aricle, you get this :
http://www.symantec.com/connect/blogs/remote-linux-wiper-found-south-korean-cyber-attack

if i read that correctly (just skimmed through it), the malware runs on a Windows machine, looks for a program called 'mRemote' ( remote connections manager), and tries to extract hostnames and passwords stored by that program. It then uses these to try and ssh to a remote hosts and (in the case of Linux/Unix machines) runs a script that deletes files.

SeijiSensei
March 24th, 2013, 12:49 AM
if i read that correctly (just skimmed through it), the malware runs on a Windows machine, looks for a program called 'mRemote' ( remote connections manager), and tries to extract hostnames and passwords stored by that program. It then uses these to try and ssh to a remote hosts and (in the case of Linux/Unix machines) runs a script that deletes files.

Assuming that there are any logins on the Windows machines that match privileged logins on the Linux boxes. Again, as I said before, on any well-managed network, ordinary users, particularly ordinary Windows users, should have no such privileges on the remote Linux hosts.

Servers running Samba or NFS that export directories mounted by the Windows clients might be vulnerable to this attack, but only in directories to which the local Windows user has privileges. So it might be possible to log into my server with my username and password and delete my files, except that my Samba passwords bear no resemblance to my Linux passwords.

mehrdad.j
May 12th, 2013, 08:10 AM
Assuming that there are any logins on the Windows machines that match privileged logins on the Linux boxes. Again, as I said before, on any well-managed network, ordinary users, particularly ordinary Windows users, should have no such privileges on the remote Linux hosts.

Servers running Samba or NFS that export directories mounted by the Windows clients might be vulnerable to this attack, but only in directories to which the local Windows user has privileges. So it might be possible to log into my server with my username and password and delete my files, except that my Samba passwords bear no resemblance to my Linux passwords.

I know of some "Lazy Admins" who have full control over their remote servers by their Windows machines. A Windows native malware can possibly sniff credentials sent to "mremote" or other similar RDPs. Then do a false login and you know the rest of the story.