7 ms·

This is fairly straightforward ratware. Is there anything in particular you wish to know about how it operates? browser.php is an amusing one for reversing ob

by patio11 13y ago

This is fairly straightforward ratware. Is there anything in particular you wish to know about how it operates? browser.php is an amusing one for reversing obfuscation tricks, if anyone wants practice. You should treat the server as compromised and rebuild from metal, by the way. I know that is annoying as heck but they clearly got code execution and you can therefore assume they had root if they wanted it and that any attempts to detect whether they did are useless because their rootkit makes the box lie to you about its current state.

jfoster 13y ago
There's also no point in rebuilding until he thinks the attack vector has been closed. However they got in last time, they can probably do it again.
- mike-cardwell 13y ago
  He was running an old version of Drupal. If you run old versions of Drupal, Wordpress, Joomla etc, you will get hacked.
  - dspillett 13y ago
    Running old versions of anything (unless you backport security updates of course, as the Debian project do to keep Stable and OldStable secure without potentially introducing breaking changes with a full package upgrade), particularly popular apps/libs, has this risk. As soon as a project releases a security update there is a good chance that someone out there starts looking for a way to exploit what has been fixed so that they can try use it to abuse sites that have not updated yet.
    - VLM 13y ago
      "unless you backport security updates of course, as the Debian project do to keep Stable and OldStable secure without potentially introducing breaking changes with a full package upgrade" And that is why you need to run production systems on large well supported stable distributions, like Debian, and not DudeOS or FunkyNameOS created 18 months ago by two dudes and never updated since.
      - jfoster 13y ago
        I agree, although it is worth noting that running something obscure will make you less susceptible to automated, untargeted attacks. Potentially quite a lot more vulnerable to anything targeted, though.
      - dspillett 13y ago
        Definitely. And why if you roll your own packages for any reason (i.e. you need something in a more more up-to-date form than your chosen stable well-supported distribution includes) you simply must keep a close eye on the relevant projects to make sure that you don't miss an important hole filling fix. FYI: I run Debian/Stable where I have a choice and stick with the provided versions of everything as a general rule, though I currently have nodejs, npm, and some related modules compiled from other sources.
    - mseebach 13y ago
      There's a difference in severity between "will get hacked" and "has this risk". The popular web apps are targeted, and very shortly after any exploits are found, automated drive-by attacks are live across the web. The Googles are great for quickly compiling target lists as these web apps are typically pretty easy to identify - exact phrasing on the login screens etc.
      - walshemj 13y ago
        Yep I last year had a locked down aws instance running just a single purpose node.js sever and I saw loads of attempts to access common web based admin pages eg phpmyadmin WordPress. Naturally these where from Chinese or Russian ip address ranges
  - danepowell 13y ago
    I've been building Drupal sites for 6 years, and I've never had a single one get hacked, even after I stopped updating them. It's far more likely that FTP with a weak password was the attack vector.
    - spoiler 13y ago
      Not sure about Drupal, but Joomla gets targeted all the time. I don't think FTP is the attack vector. Yes, it's possible the password leaked, but it's more likely a bug in Drupal was exploited. Disclaimer: I work at a hosting company, and this is my personal experience with hacked websites.
      - jauer 13y ago
        On Joomla I've seen exploits via the site search feature and the admin login (I too work at a company that does hosting). I haven't seen Drupal sites get taken out.
    - cholmon 13y ago
      It's also likely that the vector was a vulnerable module he had installed.
woutersf 13y ago
Yes I will advise my client to change hosting to a proper hosting company. I am interested in how it operates. Is it as simple as : "It runs the remote php file and adds whatever html?" or is there more to it? I find similar functions in all the files (error_404/http_request_custom/getUseragent/getReferer/convertIpToString/getIp)
- patio11 13y ago
  There is substantially more functionality, most rendered moot by code which allows the attacker to run arbitrary instructions on the server. Typically after observing that (called a "shell" in hacker parlance) one doesn't really spend much time looking at the rest of the code.
porker 13y ago
> You should treat the server as compromised and rebuild from metal, by the way. I know that is annoying as heck but they clearly got code execution and you can therefore assume they had root if they wanted it and that any attempts to detect whether they did are useless because their rootkit makes the box lie to you about its current state. Is privilege escalation that easy/common? Thinking esp of the number of shared hosting providers out there, if a user account is compromised they don't assume the entire server is compromised. Now ok, www-data isn't any old user account, but the same principle applies?
- eli 13y ago
  In theory you might be right, but in practice patio11 definitely is. Either way, the big hassle is going to be reinstalling your site, pulling a copy of the database from backup (you have that right?). Might as well go all the way and install everything fresh.
  - dennisgorelik 13y ago
    Why reinstall database from old backup? Can trojan be hiding in the database?
    - eli 13y ago
      Yes, definitely! Drupal (like Wordpress and others) stores all the "content" of your site in a database so there could be all manner of nastiness hidden in your pages. And then, obviously, the attacker could have added an admin user account or, less obviously, altered settings stored in the database to make the site insecure. My advice would be to restore completely from backup, if possible.
      - dennisgorelik 13y ago
        The price of restoring from old backup could be steep: some data loss. Or at least time consuming manual data merge with data from more recent, but compromised database. It might be easier to check database for common vulnerabilities (admin accounts, suspicious content for web pages).
Kinnard 13y ago
What exactly do you mean when you say rebuild from metal?
- TallGuyShort 13y ago
  Anything short of formatting all the drives and reinstalling the OS will not result in a trustable machine. As they said, the attackers most likely have root access and rootkits make the machine lie about it's state. So even if you remove all your website code and replace it, they probably have a backdoor to get in and compromise it again. And you can't find that backdoor, because they modify utilities like 'ls', etc.. so that you can't detect files that were installed or modified by the rootkit.
  - MiguelHudnandez 13y ago
    To be truly sure you're back to normal, you would want to re-flash firmwares, as well. Which is truly a pain. Your NIC has firmware, your Motherboard has firmware, even SATA disks have firmware... Here's a gentleman who put malicious firmware on a hard disk to bypass linux security by serving a neutered /etc/passwd file. http://spritesmods.com/?art=hddhack http://spritesmods.com/?art=hddhack Generally, you have to choose the level of rebuild that you can live with given your likely attacker. Usually, flashing firmware is dangerous and likely to alert the operator to the infection, so most attackers interested in spam/phishing wouldn't try that approach. That is probably some three-letter-organization level stuff.
    - jacquesm 13y ago
      That's quite the hack.
    - fyrabanks 13y ago
      Yeah, like you hint at--this gets near Dragos levels of paranoia. Firmware based hacks are highly non-trivial; particularly considering the sophistication of the scripted attacks that target Wordpress, Drupal, et al. installations en-masse. Unless it's a very high-value target, most people are not going to go through the trouble of coming up with a custom attack for every bit of hardware they encounter (not to mention the amount of functionality you can squeeze into flash while still maintaining its usefulness as operating firmware). In the amount of time it'd take to do that, you could manually seize tons of other insecure installations. Also, if you happen to know of any Linux utilities that can flash a live OS's HDD firmware without the system going to shit, I'd be curious to learn more.

by patio11 13y ago

jfoster 13y ago

There's also no point in rebuilding until he thinks the attack vector has been closed. However they got in last time, they can probably do it again.

mike-cardwell 13y ago
He was running an old version of Drupal. If you run old versions of Drupal, Wordpress, Joomla etc, you will get hacked.
- dspillett 13y ago
  Running old versions of anything (unless you backport security updates of course, as the Debian project do to keep Stable and OldStable secure without potentially introducing breaking changes with a full package upgrade), particularly popular apps/libs, has this risk. As soon as a project releases a security update there is a good chance that someone out there starts looking for a way to exploit what has been fixed so that they can try use it to abuse sites that have not updated yet.
  - VLM 13y ago
    "unless you backport security updates of course, as the Debian project do to keep Stable and OldStable secure without potentially introducing breaking changes with a full package upgrade" And that is why you need to run production systems on large well supported stable distributions, like Debian, and not DudeOS or FunkyNameOS created 18 months ago by two dudes and never updated since.
    - jfoster 13y ago
      I agree, although it is worth noting that running something obscure will make you less susceptible to automated, untargeted attacks. Potentially quite a lot more vulnerable to anything targeted, though.
    - dspillett 13y ago
      Definitely. And why if you roll your own packages for any reason (i.e. you need something in a more more up-to-date form than your chosen stable well-supported distribution includes) you simply must keep a close eye on the relevant projects to make sure that you don't miss an important hole filling fix. FYI: I run Debian/Stable where I have a choice and stick with the provided versions of everything as a general rule, though I currently have nodejs, npm, and some related modules compiled from other sources.
  - mseebach 13y ago
    There's a difference in severity between "will get hacked" and "has this risk". The popular web apps are targeted, and very shortly after any exploits are found, automated drive-by attacks are live across the web. The Googles are great for quickly compiling target lists as these web apps are typically pretty easy to identify - exact phrasing on the login screens etc.
    - walshemj 13y ago
      Yep I last year had a locked down aws instance running just a single purpose node.js sever and I saw loads of attempts to access common web based admin pages eg phpmyadmin WordPress. Naturally these where from Chinese or Russian ip address ranges
- danepowell 13y ago
  I've been building Drupal sites for 6 years, and I've never had a single one get hacked, even after I stopped updating them. It's far more likely that FTP with a weak password was the attack vector.
  - spoiler 13y ago
    Not sure about Drupal, but Joomla gets targeted all the time. I don't think FTP is the attack vector. Yes, it's possible the password leaked, but it's more likely a bug in Drupal was exploited. Disclaimer: I work at a hosting company, and this is my personal experience with hacked websites.
    - jauer 13y ago
      On Joomla I've seen exploits via the site search feature and the admin login (I too work at a company that does hosting). I haven't seen Drupal sites get taken out.
  - cholmon 13y ago
    It's also likely that the vector was a vulnerable module he had installed.

woutersf 13y ago

Yes I will advise my client to change hosting to a proper hosting company. I am interested in how it operates. Is it as simple as : "It runs the remote php file and adds whatever html?" or is there more to it? I find similar functions in all the files (error_404/http_request_custom/getUseragent/getReferer/convertIpToString/getIp)

patio11 13y ago
There is substantially more functionality, most rendered moot by code which allows the attacker to run arbitrary instructions on the server. Typically after observing that (called a "shell" in hacker parlance) one doesn't really spend much time looking at the rest of the code.

porker 13y ago

> You should treat the server as compromised and rebuild from metal, by the way. I know that is annoying as heck but they clearly got code execution and you can therefore assume they had root if they wanted it and that any attempts to detect whether they did are useless because their rootkit makes the box lie to you about its current state. Is privilege escalation that easy/common? Thinking esp of the number of shared hosting providers out there, if a user account is compromised they don't assume the entire server is compromised. Now ok, www-data isn't any old user account, but the same principle applies?

eli 13y ago
In theory you might be right, but in practice patio11 definitely is. Either way, the big hassle is going to be reinstalling your site, pulling a copy of the database from backup (you have that right?). Might as well go all the way and install everything fresh.
- dennisgorelik 13y ago
  Why reinstall database from old backup? Can trojan be hiding in the database?
  - eli 13y ago
    Yes, definitely! Drupal (like Wordpress and others) stores all the "content" of your site in a database so there could be all manner of nastiness hidden in your pages. And then, obviously, the attacker could have added an admin user account or, less obviously, altered settings stored in the database to make the site insecure. My advice would be to restore completely from backup, if possible.
    - dennisgorelik 13y ago
      The price of restoring from old backup could be steep: some data loss. Or at least time consuming manual data merge with data from more recent, but compromised database. It might be easier to check database for common vulnerabilities (admin accounts, suspicious content for web pages).

Kinnard 13y ago

What exactly do you mean when you say rebuild from metal?

TallGuyShort 13y ago
Anything short of formatting all the drives and reinstalling the OS will not result in a trustable machine. As they said, the attackers most likely have root access and rootkits make the machine lie about it's state. So even if you remove all your website code and replace it, they probably have a backdoor to get in and compromise it again. And you can't find that backdoor, because they modify utilities like 'ls', etc.. so that you can't detect files that were installed or modified by the rootkit.
- MiguelHudnandez 13y ago
  To be truly sure you're back to normal, you would want to re-flash firmwares, as well. Which is truly a pain. Your NIC has firmware, your Motherboard has firmware, even SATA disks have firmware... Here's a gentleman who put malicious firmware on a hard disk to bypass linux security by serving a neutered /etc/passwd file. http://spritesmods.com/?art=hddhack http://spritesmods.com/?art=hddhack Generally, you have to choose the level of rebuild that you can live with given your likely attacker. Usually, flashing firmware is dangerous and likely to alert the operator to the infection, so most attackers interested in spam/phishing wouldn't try that approach. That is probably some three-letter-organization level stuff.
  - jacquesm 13y ago
    That's quite the hack.
  - fyrabanks 13y ago
    Yeah, like you hint at--this gets near Dragos levels of paranoia. Firmware based hacks are highly non-trivial; particularly considering the sophistication of the scripted attacks that target Wordpress, Drupal, et al. installations en-masse. Unless it's a very high-value target, most people are not going to go through the trouble of coming up with a custom attack for every bit of hardware they encounter (not to mention the amount of functionality you can squeeze into flash while still maintaining its usefulness as operating firmware). In the amount of time it'd take to do that, you could manually seize tons of other insecure installations. Also, if you happen to know of any Linux utilities that can flash a live OS's HDD firmware without the system going to shit, I'd be curious to learn more.