My website source code has been stolen. I spent 2 years working on it. A couple days ago some emails started coming in from my mailer, but from a different host. I'm running fedora 7. I don't know how to proceed. I've been unable to detemine the source of the hack: ftp, ssh, apache? Ftp was on the standard port, but ssh was non-standard. I'd like to figure out how they got the code and how to prevent them from getting in. The server is on a separate line. I ftp and ssh in to do things. I'm looking at iptables right now in hopes that I can deny ftp/ssh access to anyone except myself as I'm the only person who needs it. Beyond that, I hope that apache is not the leak... Please advise, thanks.
They were generating new content with my code. I've gone through the secure logs and I don't see any logins into ssh or ftp from other IPs. (numerous failed attempts though) I could really use some advice on how to track this down. I used: cat /var/log/secure | grep "Login s" cat /var/log/secure | grep "Accepted pass" To find all the ssh and ftp logins. I'm now running denyhosts and have shutdown ftp -- using sftp for myself now. I'm also going to set hosts.allow: http: ALL sshd: <my ip> hosts.deny: ALL: ALL I did send them an email and they have taken it down without a response... (for now) So, that leaves me with an apache security flaw? I'm going through this guide: http://www.petefreitag.com/item/505.cfm I really don't know how to verify it's working, nor how to hack apache.
I went through this guide: http://www.howtoforge.org/apache_security_testing_with_nikto Here's the report I got: Code: + Target Port: 80 + Start Time: Mon Mar 24 19:46:17 2008 --------------------------------------------------------------------------- - Scan is dependent on "Server" string which can be faked, use -g to override + Server: Apache - Retrieved X-Powered-By header: PHP/5.2.3 - /robots.txt - retrieved but it does not contain any 'disallow' entries, which is odd. This should be checked manually.(GET) + /?mod=<script>alert(document.cookie)</script>&op=browse - Sage 1.0b3 is vulnerable to Cross Site Scripting (XSS). CA-2000-02. (GET) + / - TRACE option appears to allow XSS or credential theft. See http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details (TRACE) + /a?<script>alert('Vulnerable')</script> - Server is vulnerable to Cross Site Scripting (XSS) in the error message if code is passed in the query-string. This may be a Null HTTPd server. (GET) + /catinfo?<u><b>TESTING - The Interscan Viruswall catinfo script is vulnerable to Cross Site Scripting (XSS). CA-2000-02. (GET) + /index.php?action=storenew&username=<script>alert('Vulnerable')</script> - SunShop is vulnerable to Cross Site Scripting (XSS) in the signup page. CA-200-02. (GET) + /index.php?dir=<script>alert('Vulnerable')</script> - Auto Directory Index 1.2.3 and prior are vulnerable to CSS attacks. (GET) + /index.php?err=3&email=\"><script>alert(document.cookie)</script> - MySQL Eventum is vulnerable to XSS. OSVDB-12606. (GET) + /index.php?file=Liens&op=\"><script>alert('Vulnerable');</script> - Nuked-klan 1.3b is vulnerable to Cross Site Scripting (XSS). CA-2000-02. (GET) + /index.php?option=search&searchword=<script>alert(document.cookie);</script> - Mambo Site Server 4.0 build 10 is vulnerable to Cross Site Scripting (XSS). CA-2000-02. (GET) + /index.php?rep=<script>alert(document.cookie)</script> - GPhotos index.php rep Variable XSS. OSVDB-25497 (GET) + /index.php?vo=\"><script>alert(document.cookie);</script> - Ralusp Sympoll 1.5 is vulnerable to Cross Site Scripting (XSS). CA-2000-02. (GET) + /index.php/\"><script><script>alert(document.cookie)</script>< - eZ publish v3 and prior allow Cross Site Scripting (XSS). CA-2000-02. (GET) + /index.php/content/advancedsearch/?SearchText=<script>alert(document.cookie)</script>&PhraseSearchText=<script>alert(document.cookie)</script>&SearchContentClassID=-1&SearchSectionID=-1&SearchDate=-1&SearchButton=Search - eZ publish v3 and prior allow Cross Site Scripting (XSS). CA-2000-02. (GET) + /index.php/content/search/?SectionID=3&SearchText=<script>alert(document.cookie)</script> - eZ publish v3 and prior allow Cross Site Scripting (XSS). CA-2000-02. (GET) + /phpmyadmin/db_details_importdocsql.php?submit_show=true&do=import&docpath=../../../../../../../etc - Needs Auth: (realm "Restricted Files") + /search/?SectionIDOverride=1&SearchText=<script>alert(document.cookie);</script> - Redirects to, ezPublish 2.27 is vulnerable to Cross Site Scripting (XSS). CA-2000-02. + /styles/ - May be able to view web styles directory. (GET) + /phpmyadmin/ - Needs Auth: (realm "Restricted Files") + 2673 items checked - 16 item(s) found on remote host(s) + End Time: Mon Mar 24 19:47:39 2008 (82 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
I've closed off ftp and I'm only allowing ssh connections from my IP. I've disabled http TRACE and installed mod_security. Putting me down to: Code: + Target Port: 80 + Start Time: Mon Mar 24 20:30:22 2008 --------------------------------------------------------------------------- - Scan is dependent on "Server" string which can be faked, use -g to override + Server: Apache + No CGI Directories found (use '-C all' to force check all possible dirs) + /phpmyadmin/db_details_importdocsql.php?submit_show=true&do=import&docpath=../../../../../../../etc - Needs Auth: (realm "Restricted Files") + /phpmyadmin/ - Needs Auth: (realm "Restricted Files") + 2052 items checked - 0 item(s) found on remote host(s) + End Time: Mon Mar 24 20:30:45 2008 (23 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
well it's not going to help you tracing down how they did hack your server, but it surely will prevent further brute force / dictionary attacks.. There's a package caled Fail2Ban that manipulates your IPtables on failed login attempts ( I set it to 3 ) and bans IP's / service for a predetermined time ( I set it to 1 hour ) ... This makes brute force even with weak passwords almost impossible... Since it works on a port level ip's banned from your ssh port can still access ftp or whatever.... so it's unlikely to use as a DDOS blocking content from users... Since you didn't tell what OS you used there's little I can tell to check... but all access should have been logged somewhere. ( I usually mail copies of my log files to another server, just to prevent possible hackers from deleting them )
Backing up the logs is an interesting idea. You must have to do it pretty frequently. I'm running FedoraCore7. I'm running denyhosts now, which seems much like Fail2Ban. Pretty much everything is closed -- the only way to get in would be via IP spoofing as far as I know... I really couldn't find any trace of the hack, but I'm no guru. I'm assuming ssh/ftp with a log edit at this point. Is it worth setting up php source encryption? That's what I'm looking into now: http://howtoforge.com/linux_apache2_ssl_php5_zendoptimizer_ioncubeloader
well there's also something else you can use to check your setup -pretty sleek if you ask me, just don't run it against someone else's server ( those dudes ? )-, there's a package called Nikto, does all the things Nessus is supposed to protect you from... very nice smart stuff, just untar it and run, ( the latest version from their site ), it's a perl script. If you prefer a GUI check out Webshag which uses Nikto libraries + some other features, it's a python script & gives you nice comments on how to to prevent those things -xss is how they probably did it-, that xss thing has nothing to do with your port security, but exploits server/browser vulnerabilities ( quite complex stuff ) ... But luckily you don't have to be a geek to run & understand the app... Thought my servers where tight... > proxy / firewall / NAT router / iptables ... still that stuff found 8 exploits... go figure ... I ran it -just for fun- against an IIS server ... man ... proggie went berserk ... rofl.... If you're really paranoid just look into honeypots... gives them something to play with & you the time to track them guys... good luck..
K regarding that encryption ... ( I got an account timeout so I just continue on a 2nd reply ) Just think about following, if those guys used an unknown php exploit, encrypting that will just keep the exploit ( albeit encrypted ). Also firewalls ( what's in a name ? ) are just a first defense & ( you can disagree ) are just there to allow exceptions. In other words your computer should be secured already using > strong passwords / iptables / chrooted services You should definitely master the art of chrooting services, this way an exploit can't be used to elevate privileges / take control of other services ... ( every service his own user/group ) I also just thought of another way to secure logs by using very frequent rotating snapshots ( which will look to the outside as normal files ), any attempt in manually editing those will result in abnormal large snapshots which are easy to detect ... ( mmm got too try this out ) and I can still mail them...
Finally, I've found a trace of the hack. In my /var/www/html/ there is a file: -rw-r--r-- 1 apache apache 7.3M 2008-03-02 06:39 html.tar Created by the apache user -- so this implies a web hack, not ftp/ssh as I suspected. Any advice on how I can determine how they did it?
huh ? they "left" a tar of your code ... if you are using php & cookies to administer your site ( as a kind of cms ) which probably is the case then they almost surely used xss credential theft ... how this works is quite easy to explain ( and no real server hack is involved )... So here we go... you login your site to administer stuff via browser > server places cookie in browser > cookie gets stolen by fishy code on other website / colleague whatever > ..... with that cookie they probably have full access...... if that's all you can find in your logs then this is most likely how they did it... little dirty trick.. the weakest part of security isn't the lock but the key.... that nikto etc.. stuff I mentioned. gives you directions on how to prevent this... now if they tar'd ( kind of zip ) the whole site they probably download it via http like > htpp://mysite.com/completewebsite.tar you should find traces in your log of that ( the transmission of the tar ), just do a search through your logs with keyword tar... and you'll know where it went....( as that will not be spoofed > it really went to a real IP ) I use a browser in a virtual machine to log into my stuff, that browser doesn't go anywhere else then there...
More details found in the logs: Code: xxhackeripxx - - [02/Mar/2008:05:34:50 -0800] "GET /test2.php?e=system('tar%20cjf%20~/html.tar.bz2%20html/'); HTTP/1.0" 200 122 "-" "Opera/9.25 (Windows NT 5.1; U; en)" xxhackeripxx - - [02/Mar/2008:05:38:42 -0800] "GET /test2.php?e=system('tar%20cf%20/var/www/html.tar%20/var/www/html/'); HTTP/1.0" 200 122 "-" "Opera/9.25 (Windows NT 5.1; U; en)" xxhackeripxx - - [02/Mar/2008:05:57:07 -0800] "GET /test2.php?e=system('cd%20../%20tar%20cf%20html.tar%20html/'); HTTP/1.0" 200 122 "-" "Opera/9.25 (Windows NT 5.1; U; en)" xxhackeripxx - - [02/Mar/2008:05:57:19 -0800] "GET /test2.php?e=system('cd%20../%20tar%20cf%20html.tar%20html/'); HTTP/1.0" 200 122 "-" "Opera/9.25 (Windows NT 5.1; U; en)" Not sure how they got test2.php on the server.
that Code: xxhackeripxx did you type that there ( isn't there an IP ? ) there should be , just grep your logs for everything with tar
I took out the hacker's ip. Looks like it was quite the team effort: Italy, Germany, Sweden, USA... I have scanned through all my logs now for the offending files -- I still haven't figured out how they wrote that file. How do I prevent this hack? I need to fix the apache's user rights firstly...
well as I said before, they probably didn't hack your server, but your browser & stole a cookie ( if that php you wrote uses cookies for login > do you use a kind of CMS ? )... just test your server with that nikto & webshag stuff, it will tell you a lot of things you probably don't know... all that different ip's you got logged are most likely just zombie pc's, only the ip related to where the tar went is important ( given that that tar contained your work ) also don't look for the complete tar name.. just tar... if you want I can take a look at those log files too ( all of them ).. just pm them to me...
Yeah, if you look at my earlier posts, you'll see I went through and cleaned up Nitko warnings. I need to secure apache/php as the apache user has too many rights apparently. I'm looking for guides to setup this up properly even if it kills files uploading in the meantime.
mmm ok sorry I overlooked that nikto log ( stupid me ... ) you did it before I even mentioned it... K I looked at it , see a LOT of vulnerabilities... lots of xss, will take a look at your logs later ( weekend woohoo )...
Are you using suPHP? Then this is normal, otherwise it would be strange... Do you use some kind of CMS/forum/etc. on your server? Maybe the hackers used a vulnerability in this app.
I'm not using suPHP, but I think I confused the issue. It's think it's being run as apache, but using safe_mode. So some scripts that were included were touched by a different user causing a mismatch. I'm not using any CMS or forum software. I wrote everything myself, that's why they wanted the source I guess. That hack log doesn't reveal anything? They somehow managed to upload a php file (I do have pages that take files) and then passed system commands to it to tar up the source.
You should definitely check the test2.php script. It seems to accept system commands which it then executes.
