Could cryptlocker virus potentially affect banks data bases?

martin57

hi folks,

With all the talk about cryptlocker virus (and there couldn't really be enough to warm people) the thought went through my mind would it be even possible that future versions of it could affect banks data bases so in effect the banks wouldn't know what money was in each of its customers accounts?

it would be a nightmare situation for anyone with savings, don't know how many backups the banks really have but it seems that it attacks and encrypts the whole network once it gains a hold.

Could a nightmare situation like this really happen?

Martin57

danthemoneysavingman

the virus would have to be cross-platform compatible with all the various different systems banks have. Plus there are off-site back-ups and multiple copies of data all over the place so it is unlikely this could ever happen. Most bank systems are very locked down anyway.

I wouldn't worry yourself ;-)

paddyrg

Unlikely, banks tend to be using a hodge-podge of mainframes and other secondary systems which are often air-gapped and invulnerable to domestic viruses

bod1467

Die Hard 4.0?

Weird_Nev

Yep. From what I understand it's very much a windows native virus.

Banking systems tend to use UNIX in some form (Lots of AIX about, Solaris, Redhat - even open source unix like systems) by the time you get to the nitty gritty of account information. The nature of those operating systems is that a cryptolocker style virus could not exceed it's authority and begin encrypting whole databases - it would in effect need super user authority, which no program in UNIX like environments has.

A malicious person with the right system access couls have a go, but you can 'rubber hose' a password out of a person. Cryptolocker is fully autonomous.

Because PC's and in particular Windows PC's are 'single user' it's easy to forget how true multi user systems work. Programs have memory space, are atributed to a user with a specific authority level, and cannot act on memory space or files that do not 'belong' to that user. UNIX and it's clones were designed from the ground up as multi-user systems, which is why viruses simply don't work on those operating systems.

In windows, we log in as a 'super user' every time. We can alter or delete any and every file on the computer if we wish. The 'User Account Control' pop ups are an attempt to re-introduce the concept of user authority to the windows environement, but it's very half arsed.

Compare this with a unix like operating system: Even if you ARE the only user, and have full administration rights over the machine, best practice dictates that you log in with your 'user' log in, NOT your 'admin' log in, unless you are doing system maintenence. That way, you can download and attempt to run the most horrible virus going, which wants to delete system files and install key stroke loggers, and then encrypt your hard drive: NOpe. Computer says no. USer does not ahve authority to access/modify those files. It MIGHT get some stuff from your user partition, but all other files, and critically the system itself, will be safe.

Banks also have multiple levels of back up, redundancy and error checking so that if a server started t omisbehave, it would simply be taken offline and another put in it's place. Banks actually deal with hardware failures on a daily basis without any trauma. The systems are designed to be robust and compensate against software or hardware failure on a fairly masssive scale. Apparently it's common for systems supplied to banks to have 64 level redundancy!

With windows you get the keys to the house. With UNIX and true multiuser computer systems, you get the keys to a room.

Cryptolocker exploits the 'any user can have admin powers' nature of windows, and the weak nature of many business or home networks to do it's damage. If it runs as 'you', it can do whatever you can - which is everything! If your receptionist or tea lady can access the businesses file server, then they can double click the cryptolocker virus and inflict a world of hurt on the company.

forgotmyname

Seen several cashpoint machines that have crashed, Windows based

Weird_Nev

forgotmyname wrote: »

Seen several cashpoint machines that have crashed, Windows based

Yep, but they're simply a front end. If you look inside the bank, you'll see that they're often connected by a simple phone line... I bet there's fun to be had there, if you know what you're doing.

Mondez

Weird_Nev wrote: »

Cryptolocker exploits the 'any user can have admin powers' nature of windows, and the weak nature of many business or home networks to do it's damage. If it runs as 'you', it can do whatever you can - which is everything! If your receptionist or tea lady can access the businesses file server, then they can double click the cryptolocker virus and inflict a world of hurt on the company.

I was under the impression that this wasn't true of Cryptolocker and that it can run under a normal user account. It has nothing to do with the old "every user is admin" paradigm on windows. It works based on the fact that the files that are important to a user are writeable by the user and so can be encrypted by their account regardless of what level of access they have to the system files. On a work system this could affect a file server where the share gives anyone the permission to write, but this is not the same as the user having an admin account. It could not for example encrypt other users folders if the user infected did not have write access even if they could read them. Cryptolocker would also be just as feasible on any other platform and could do pretty much the same damage unless you have a habit of making files read only after they are created. The reason it won't affect banks is because the database won't be sat on a file share that anyone can read, it will be on a dedicated database server that database client software connects to to manipulate, not a file browser.

securityguy

Mondez wrote: »

I was under the impression that this wasn't true of Cryptolocker and that it can run under a normal user account. It has nothing to do with the old "every user is admin" paradigm on windows. It works based on the fact that the files that are important to a user are writeable by the user and so can be encrypted by their account regardless of what level of access they have to the system files.

Indeed. Speaking as a more than thirty year Unix bigot whose use of the One True Operating system dates back to Sixth Edition on a pdp11/34, the "but on Unix we aren't administrators, so it's more secure" argument is today pretty much bull excrement.

It was a reasonable claim thirty years ago, when the main place you'd find Unix would be on a shared VAX 11/750 in a university computer science department with thirty people using it via serial lines and (later) Spider boxes. Because users are users but root is root, the undergraduates can screw their own files up but they can't screw up each other (modulo all the hideous security holes that Unix of that era in practice had) and they can't crash the system. This is the right security model for the purpose: any individual user's work is their problem, and there are backups, but the critical thing is that one user can't bring down the shared machine.

But today? The typical machine is single user, and the files on it that matter are the user's files. The OS image is trivially re-installable from media (I have, for various reasons, installed OSX 10.9.1 onto a machine three times in the last 24 hours, while playing with a home-brew Fusion Drive; it took about 20 minutes each time) while the user files are more important, often less well backed up and present in sufficient volume to make getting them off backups slow even if you've got them (I can tell you that pulling 850GB off an external disk drive onto said Fusion Drive took about 18 hours).

So as Mondez says, that CryptoLocker can't screw up system files doesn't matter. They're trivially re-installabl, there aren't many of them and (in the most common case) their damage only stops one person working. It's the loss of user files that is much more serious.

However...

On a work system this could affect a file server where the share gives anyone the permission to write

That's a bad model and people who work like that are treading on thin ice anyway. You should only have write access to your own files, and shared writeable data should be mediated by something other than file sharing, simply because even in the absence of malware the lack of locking will get you in the end. This is what Sharepoint and the like are for. Of course, you could write a CryptoLocker-style piece of malware to pull data from Sharepoint and write it back encrypted, but the versioning within the server should make that trivial to recover from.

Cryptolocker would also be just as feasible on any other platform and could do pretty much the same damage unless you have a habit of making files read only after they are created. The reason it won't affect banks is because the database won't be sat on a file share that anyone can read, it will be on a dedicated database server that database client software connects to to manipulate, not a file browser.

If you can run arbitrary SQL against a database, you can probably encrypt the tables. Hopefully in production environments the Right Thing has been done with GRANT such that you can't run arbitrary SQL. However, the CryptoLocker model (basically, "screw up all the data that I have permission to write") is very, very difficult to defend against in general. Best not let production systems run unsigned software...