4 ms·

One absolutely diabolical mechanism that was used (at least 5 years ago when this scourge of ransomware started to rear its ugly head) goes something like this:

One absolutely diabolical mechanism that was used (at least 5 years ago when this scourge of ransomware started to rear its ugly head) goes something like this: 1. Gain access to change the code on the front-end web servers (usually PHP) 2. Change the database access layer to transparently encrypt data being written to the database, and decrypt data being read from the database. The key would be loaded into memory by curl'ing an attacker-controlled website at startup. 3. Wait 30 days 4. Notify the company that they're compromised, turn off the attacker-controlled key service, and restart the web front end Now step (3) ensures that most data in the database has been re-written, and if your backups are dumps of the production database, you now have a month of encrypted backups that you can't read... If you're lucky, you may have a month-old backup to restore from; if you're unlucky, you rotate every 30 days.

mgleason_3 7y ago
Exactly. It’s possible they are screwed.
londons_explore 7y ago
Has this actually happened? Implementing zero downtime transparent encryption on any moderately complex codebase above the database layer sounds like a big engineering challenge. Even moreso if you're trying to do it without the sysadmin noticing. Even moreso if there is no persistence for the encryption key so every user request ends up having to fire a request to the attackers server - that'll kill performance. I doubt many attackers would attempt it.
- ipython 7y ago
  If I’ve learned anything in decades of working in infosec, it’s to never underestimate the ingenuity of a determined attacker. Read through any modern multi stage remote exploit. The amount of engineering required to pull these stunts off - reliably no less - is truly staggering, and yet attackers continue to innovate and develop new techniques and even more complex exploits. And you overestimate the competency of the defenders: sysadmin? What small business has a dedicated sysadmin? It’s not like we are talking about running a global hosted chat service like slack here. (Oh wait...) BTW Persistence for the key in memory is trivial: create a shared memory segment and store the key there, with a ttl.
theamk 7y ago
Wait, how does this work? Next time new version will be deployed, the deploy script will override all the files, and people will notice that all the data is coming back damaged. Was it a site in maintenance mode, where no one was working on anymore?
- landryraccoon 7y ago
  Not only that, the company must not have a single front end dev open up dev tools for 30 days (which should happen at least once a month if anybody is debugging or doing any frontend dev whatsoever), and notice that the usual json payload from the server is encrypted and can't show up in devtools, plus there's this weird outgoing request to a domain they don't recognize? And absolutely no devops or logging notices an request to some weird domain (which must be handling tons of requests and have great uptime and scalability, since every single client has to connect to it to decrypt the database). Oh, and there must not be a DBA at the company either, since absolutely nobody ran a SQL or analytics query in an entire month and noticed that some of the rows were full of unreadable garbage.. This story must be about someone's single server, single dev LAMP blog from ten years ago if it ever actually happened.
  - ipython 7y ago
    The encryption would happen on the server, not the client. Besides, what json? The server just returns rendered html as the lord intended :) Yes, we are talking about the long tail of little LAMP servers handling small business needs with some custom code written by a contracting shop. What’s a devops? DBA? Once the site is developed and working, there’s little reason to pay to change it.
    - landryraccoon 7y ago
      If they have full sql read write access on the server, it’s way easier to make a copy of the db, encrypt it, then blow away the original db in one go.
      - 7y ago
landryraccoon 7y ago
If there's an engineer who can pull this off why are they screwing around with ransomware? Have them send me their resume, if they can deploy code to our frontend transparently without customers or devops having to spend time or even noticing it we'll happily pay them more than they're asking for in ransom. Edit : thinking about it, this story doesn’t add up. Doesn’t this mean the client must have a copy of the decryption key, meaning any cached client would render the ransom demand worthless? It’s just also so much easier, if someone has that level of access, to make a copy of the database, encrypt it, then blow away the old one. Doing a silent deploy of client code with no one noticing seems way harder.
- bin0 7y ago
  Honestly, many of them are in nations where they are working for a state-sponsored cybercrime agency and have few other options, if any. North Korea and Iranian gov'ts are major purveyors of ransomware; I've known many clients who were breached by them (FBI guys said it was usually one of them each time). If not, it's probably Russia or China, especially if it's a higher-value target. If it's just a private citizen flinging exploits at ip ranges, it's possibly Brazil too. Honestly, it used to be Eastern Europe, until we started realizing they've got some serious programming talent and contracted some work out. Now it's less bad, though still a bit sketchy. Of course, this doesn't help nation-state attacks.
- wildduck 7y ago
  > if they can deploy code to our frontend transparently without customers or devops having to spend time or even noticing it we'll happily pay them more than they're asking for in ransom. Where should I send the resume?
- ec109685 7y ago
  The client only had the decryption key in memory (the curl part of their story). Where it breaks down is assuming only the web server that is compromised has access to the database.
bin0 7y ago
This is one of those stories that goes around in certain communities. I don't know if it's true or not; it may well be. I've heard of it several times, but only ever second- or third-hand. I've also heart it's happened to more than one company. The thing is, you can't really verify this sort of stuff: if it's true, whoever developed it would throw its full weight behind it and hit as many targets as possible. It would probably be under tight investigation by some three-letter. Companies also probably wouldn't want to disclose this. I don't know if It's not unreasonable to hypothesize N. Korea or Iran put together a kit, though they'd probably relegate it to a certain stack (too much technical debt otherwise). Of course, it's also possible it's not, and I wonder if that's more likely. Every industry has such stories; maybe this is the white whale of forensics.
- rhizome 7y ago
  Back in the day when memes were in the form of urban legends and dispensing with them required various paperback books, these were called FOAF stories: always "a friend of a friend."

mgleason_3 7y ago

Exactly. It’s possible they are screwed.

londons_explore 7y ago

Has this actually happened? Implementing zero downtime transparent encryption on any moderately complex codebase above the database layer sounds like a big engineering challenge. Even moreso if you're trying to do it without the sysadmin noticing. Even moreso if there is no persistence for the encryption key so every user request ends up having to fire a request to the attackers server - that'll kill performance. I doubt many attackers would attempt it.

ipython 7y ago
If I’ve learned anything in decades of working in infosec, it’s to never underestimate the ingenuity of a determined attacker. Read through any modern multi stage remote exploit. The amount of engineering required to pull these stunts off - reliably no less - is truly staggering, and yet attackers continue to innovate and develop new techniques and even more complex exploits. And you overestimate the competency of the defenders: sysadmin? What small business has a dedicated sysadmin? It’s not like we are talking about running a global hosted chat service like slack here. (Oh wait...) BTW Persistence for the key in memory is trivial: create a shared memory segment and store the key there, with a ttl.

theamk 7y ago

Wait, how does this work? Next time new version will be deployed, the deploy script will override all the files, and people will notice that all the data is coming back damaged. Was it a site in maintenance mode, where no one was working on anymore?

landryraccoon 7y ago
Not only that, the company must not have a single front end dev open up dev tools for 30 days (which should happen at least once a month if anybody is debugging or doing any frontend dev whatsoever), and notice that the usual json payload from the server is encrypted and can't show up in devtools, plus there's this weird outgoing request to a domain they don't recognize? And absolutely no devops or logging notices an request to some weird domain (which must be handling tons of requests and have great uptime and scalability, since every single client has to connect to it to decrypt the database). Oh, and there must not be a DBA at the company either, since absolutely nobody ran a SQL or analytics query in an entire month and noticed that some of the rows were full of unreadable garbage.. This story must be about someone's single server, single dev LAMP blog from ten years ago if it ever actually happened.
- ipython 7y ago
  The encryption would happen on the server, not the client. Besides, what json? The server just returns rendered html as the lord intended :) Yes, we are talking about the long tail of little LAMP servers handling small business needs with some custom code written by a contracting shop. What’s a devops? DBA? Once the site is developed and working, there’s little reason to pay to change it.
  - landryraccoon 7y ago
    If they have full sql read write access on the server, it’s way easier to make a copy of the db, encrypt it, then blow away the original db in one go.
    - 7y ago

landryraccoon 7y ago

If there's an engineer who can pull this off why are they screwing around with ransomware? Have them send me their resume, if they can deploy code to our frontend transparently without customers or devops having to spend time or even noticing it we'll happily pay them more than they're asking for in ransom. Edit : thinking about it, this story doesn’t add up. Doesn’t this mean the client must have a copy of the decryption key, meaning any cached client would render the ransom demand worthless? It’s just also so much easier, if someone has that level of access, to make a copy of the database, encrypt it, then blow away the old one. Doing a silent deploy of client code with no one noticing seems way harder.

bin0 7y ago
Honestly, many of them are in nations where they are working for a state-sponsored cybercrime agency and have few other options, if any. North Korea and Iranian gov'ts are major purveyors of ransomware; I've known many clients who were breached by them (FBI guys said it was usually one of them each time). If not, it's probably Russia or China, especially if it's a higher-value target. If it's just a private citizen flinging exploits at ip ranges, it's possibly Brazil too. Honestly, it used to be Eastern Europe, until we started realizing they've got some serious programming talent and contracted some work out. Now it's less bad, though still a bit sketchy. Of course, this doesn't help nation-state attacks.
wildduck 7y ago
> if they can deploy code to our frontend transparently without customers or devops having to spend time or even noticing it we'll happily pay them more than they're asking for in ransom. Where should I send the resume?
ec109685 7y ago
The client only had the decryption key in memory (the curl part of their story). Where it breaks down is assuming only the web server that is compromised has access to the database.

bin0 7y ago

This is one of those stories that goes around in certain communities. I don't know if it's true or not; it may well be. I've heard of it several times, but only ever second- or third-hand. I've also heart it's happened to more than one company. The thing is, you can't really verify this sort of stuff: if it's true, whoever developed it would throw its full weight behind it and hit as many targets as possible. It would probably be under tight investigation by some three-letter. Companies also probably wouldn't want to disclose this. I don't know if It's not unreasonable to hypothesize N. Korea or Iran put together a kit, though they'd probably relegate it to a certain stack (too much technical debt otherwise). Of course, it's also possible it's not, and I wonder if that's more likely. Every industry has such stories; maybe this is the white whale of forensics.

rhizome 7y ago
Back in the day when memes were in the form of urban legends and dispensing with them required various paperback books, these were called FOAF stories: always "a friend of a friend."