Friday, July 5, 2019

security - Got Hacked. Want to understand how



Someone has, for the second time, appended a chunk of javascript to a site I help run. This javascript hijacks Google adsense, inserting their own account number, and sticking ads all over.



The code is always appended, always in one specific directory (one used by a third party ad program), affects a number of files in a number of directories inside this one ad dir (20 or so) and is inserted at roughly the same overnight time. The adsense account belongs to a Chinese website (located in a town not an hour from where I will be in China next month. Maybe I should go bust heads... kidding, sort of), btw... here is the info on the site: http://serversiders.com/fhr.com.cn



So, how could they append text to these files? Is it related to the permissions set on the files (ranging from 755 to 644)? To the webserver user (it's on MediaTemple so it should be secure, yes?)? I mean, if you have a file that has permissions set to 777 I still can't just add code to it at will... how might they be doing this?



Here is a sample of the actual code for your viewing pleasure (and as you can see... not much to it. The real trick is how they got it in there):








Since a number of folks have mentioned it, here is what I have checked (and by checked I mean I looked around the time the files were modified for any weirdness and I grepped the files for POST statements and directory traversals:




  • access_log (nothing around the time except normal (i.e. excessive) msn bot traffic)

  • error_log (nothing but the usual file does not exist errors for innocuous looking files)

  • ssl_log (nothing but the usual)

  • messages_log (no FTP access in here except for me)




*UPDATE:** OK, solved it. Hackers from China had physically placed a file in our site that allows them to do all manner of administrative things (database access, delete and create files and dirs, you name it, they had access). We were lucky they didn't do something more destructive. There was nothing in the normal apache log files but I found a different set of log files in a web server log analyzer and the evidence was in there. They were accessing this file with their own admin username and password and then editing whatever they needed right there on the server. Their file has "apache" set as the user while all other files on our site have a different user name. Now I need to figure out how they physically got this file onto our system. I suspect blame for this will eventually rest with our web host (Media Temple), unless they actually had our FTP login... not sure how I will determine that, however, as this file has probably been there for a while.


Answer



First of all chmod 744 its NOT what you want. The point of chmod is to revoke access to other accounts on the system. Chmod 700 is far more secure than chmod 744. However Apache only needs the execute bit to run your php application.



chmod 500 -R /your/webroot/



chown www-data:www-data -R /your/webroot/




www-data is commonly used as Apache's account which is used to execute the php. You could also run this command to see the user account:



`print system("whoami");
?>`


FTP is horribly insecure and it's very likely that you were hacked from this method. Using FTP you can make files writable, and then infect them again. Make sure you run an anti-virus on all machines with FTP access. There are viruses that sniff the local traffic for FTP user-names and passwords and then login and infect the files. If you care about security you'll use SFTP, which encrypts everything. Sending source code and passwords over the wire in clear text is total madness.



Another possibility is that you are using an old library or application. Visit the software vendor's site and make sure you are running the latest version.



No comments:

Post a Comment

linux - How to SSH to ec2 instance in VPC private subnet via NAT server

I have created a VPC in aws with a public subnet and a private subnet. The private subnet does not have direct access to external network. S...