Crazy php code injections

Posted by jerry as Hacking, Security

 As I’ve written about here several times, the onslaught of unsuccessful php include attacks continues.  Today, I saw a new file referenced - bot.txt.  It looked like this in the apache log file:

Read the rest of this entry »

Have CAPTCHAs been broken? Sort of…

Posted by jerry as Security

I just read this article about the Hannah Montana ticket debacle, and how it points to an apparent weakness is CAPTCHA.  Unfortunately, for CAPTCHA, the problem wasn’t some slick new algorithm designed by a miscreant that can reliably decipher the images, but rather establishing a network that grabs the CAPTCHA from one site, shoots it to a porn or warez we site that presents the same CAPTCHA to someone looking to score some boobies, who must answer the CAPTCHA before getting their prize.

It’s really quite clever, and I anticipate that the CAPTCHA breaking network will continue to mature, as we have seen with other malware.  Someone’s going to make a business case for hosting a service that has an input API that accepts an image, and returns the CAPTCHA text, and a similar API that presents the CAPTCHA much like an online ad, and accepts the CAPTCHA text as an input.  Sites that use the CAPTCHA and returned a “solution” are compensated in the same model as a click through for an online ad - think of it as adsense for bad people.  Except, it would be perfectly acceptable for the site owner to sit there all night and answer CAPTCHAs on his or her site, raking in the money.

On the other side, those looking to break the CAPTCHA would have to pay a small fee for a certain number of CAPTCHA credits.  The money would flow to the site owners, with the service owner keeping a service charge, of course.

 Honestly, that could spell the end for the widespread use of CAPTCHAs.  The only way to stop this is to make the CAPTCHA too difficult to read for a human, and that defeats the whole purpose.

So, in effect, CAPTCHA was broken without really breaking it.

Are domain parking companies complicit in typo-squatting?

Posted by jerry as Uncategorized

From this article 

“The domain name parking companies are providing a service. Whether or not you agree with the domain name owner’s decision to buy a certain domain name, it is not the parking company’s responsibility to police the internet and protect a company’s brand. That remains the responsibility of the brand itself. The brand or trademark owner should go after the domain owner, and not publicly lynch the domain parking companies:”

I would say that’s debatable.  Think about some “real world” parrellels:
Bootleg merchandise.  The retailer did not manfacture fake Nike shoes, he is just selling them.  It’s not his responsibility to police the goods that move through his store - that’s the responsibility of the real manufacturer.

Pirated music.  Napster, grokster, bearshare, guntella, and on and on, all claimed that they just provided a service, and there were legitimate, legal uses for the service, and that it was not their responsibility to police was was going through. 

Picture duplication.  Photo development companies claim that it’s not their responsibility to police what pictures they reproduce.  The copyright holder must do something to prevent unauthorized duplication.

In all those cases, the organization felt strongly in their footing.  But they key is that each one lost in a big way.  Like it or not, if you’re aiding in something that’s illegal, you’re complicit.  The question is where do you draw the line.  Should ISP’s have been held responsible in the music sharing cases?  Probably not.  Should the manufacturer of photo paper be held responsible for copyright infringement?  Probably not.  It’s a grey line, to be sure, but it seems pretty obvious that the domain parking companies are well on one side of the line.  The only thing missing are lawsuits and legislation now.

PHP include attacks rolling on…

Posted by jerry as Hacking, Security

I’ve written about this a bit, and I’ve started a current attack list on networkstike.com, but the intensity seems to be increasing in these attempts.  I decide to google one of the URL’s that’s included, and right off the bat, I found this article from a web site that’s seeing the same thing.  I believe these attacks are being launched from a botnet, trolling for vulnerable sites to use for some kind of illicit business.

What was really interesting to me in my google search for some of the inclusion URLs is the number of log files that are available and indexed via google.  For a long time, I have gotten many hits with the referral set to a spammy site - an obvious attempt to get some clicks and link mojo with Google.   I never really thought a lot about it, but I can see that it’s probably a fairly effective thing, given the number of log files I found via google.

The current list of php inclusion hits for my sites is below:

http://www.s1ko.jazztel.es/safe.gif?
http://gw-gold.net/dragoc/id.txt?
http://musicgirll.chat.ru/wav/mysong?
http://www.mta.cl/galeria2/galery.txt?
http://www.mta.cl/galeria2/galery.jpg?
http://www.madinaedu.gov.sa/safeon.txt??
http://www.modelismo.alternativo.nom.br//poll/polldata/readme.txt??
http://shellbr.com.sapo.pt/safeon.txt??
http://zamkad.ru/pub/buffer_upload/…/cmd.txt?
http://www.volontaridelrotary2040.com/html/modules/xt_conteudo/NewFile.txt?
http://telkomsex.com/ec.txt?
http://193.109.188.20/0/templates/rhuk_solarflare_ii/css/contr.txt??
http://www.dip-kostroma.ru/bak_skompa/themes/runcms/menu/images/.asc/www?????????????????????????????
http://neu.sv-badbentheim.de/hide.txt?
http://www.smartlabphd.com/book/list/skin/zero_vote/images/setup_pages2.gif???
http://www.smartlabphd.com/book/list/skin/zero_vote/images/setup_pages.gif???
http://www.urjb.com/photos/albums/userpics/10001/thumb_blank.gif??
http://www.hgbruce.com/components/com_rsgallery/safeon.txt??
http://tr-igus.com/safe.txt?
http://www.valerieataylor.com/gb/book2.gif??
http://servergazi.com/portal/images/stories/web.gif??
http://hackbsd.net/.xrt/safe.gif?
http://www.freewebtown.com/w8ting/safe.txt??
http://rumusic.chat.ru/rumusic.wav?
http://ninaru.hut2.ru/images/cs.txt?
http://amygirl.land.ru/baby?
http://www.martinschaab.de/php/id.txt?
http://x0.741.com/pb.txt?
http://location-investment.com/Connections/r8.txt?
http://jjisdfiuw834wsdd.chat.ru/js?

I’ve started downloading the files and looking at them.  Many of them are loosly copied off of one another, some are exactly the same.  Some are quite complex, all-in-one shells, that would allow complete server control.  Most of them appear to give some basic information, like directory, available disk space, effetive UID and GID, and the like.

My deer crash pictures are apparently pretty popular

Posted by jerry as Uncategorized

This blog doesn’t get a lot of traffic, but I noticed that nearly all of it is to look at the pictures of my car accident.  Many of them are referrals from google for people searching for images of car and deer accidents.  That’s pretty morbid.  My picture is on the second page of nearly all the search results, which means that there are LOT of people searching for pictures of car crashes with deer.  It’s also apparently going around in an email.  To be honest, it’s not really that impressive, but since it seems to be what people want to see and I’m all about delivering, here you go:

Web Site Security Guide

Posted by jerry as Security, Uncategorized

So, in the aftermath of my little incident, I decided to write an article for NetworkStrike on how to keep your website secure.  I’ve included it below: 

Background

The “cost of entry” to run a website is very low now, and we have seen an explosion of small sites on the Internet. Supporting this trend has been the availability of free and open source applications that allow site owners to do nearly anything they want, from blogs to wikis to forums. 

Unfortunately, nearly all of the software has inherent bugs that can be exploited by bad people. The exploitation of such bugs has matured in a similar fashion to the applications themselves.  Compromised web sites are a foundation to many threats currently on the Internet. Site owners are unknowingly supporting illegal activities such as:

• Hosting warez
• Hosting copyrighted files
• Hosting tools to compromise other sites
• Sending massive amounts of spam
• Host phishing sites to steal money
• Become part of command and control for botnets

Running a web site properly is truly becoming a social responsibility. If you are not part of the solution, you are likely part of the problem. 

This guide outlines some general and basic security measures that you MUST take if you want to make sure your site is not defaced or otherwise compromised.

Key elements needed in a web hosting platform

Try as you might, if another site on the server you share does not follow prudent security measures, then your site it still vulnerable. Suphp executes php scripts as the user-id and group-id of the account – not the userid/group id of the web server.

This will allow more restrictive permissions on your directories and will prevent an attacked from being able to read your php files.

Some hosts will not want to use suphp, as it can cause performance problems.

Build a relationship with provider on dealing with security issues

Firewall outbound connections

 This is not always practical or possible, but firewalling traffic originating from the server – other than what is expected – can prevent backdoor tools from phoning home.

Run suhosin patch for php

Suhosin can stop the exploitation of many different types of coding weaknesses and some vulnerabilities in php itself.

Keeping up with the web software you use

• Subscribe to mailing list for any application software used as part of your site.  Nearly all such applications have an “announcement” list that is low traffic.
• Attempt to participate regularly in the forums or discussion lists for the software you use. You will often get advanced warning of security issues and interim fixes.  You will also know if the software is at risk of being abandoned and not updated.
• Upgrade after a security fix release within 3 days.  Vulnerabilities are often exploited soon after they are discovered.
• If an application you use becomes abandon, plan to migrate your site to a new tool as fast as possible.
• Try not to customize software.  This will slow down your ability to patch or upgrade, because you’ll have to rewrite code, test, etc, and that can be difficult to do when it’s not on your timeline.
• Attempt to remove ‘powered by’ and version number references.  Nearly all open source web applications proudly, but this has turned out to be an extrodinarily efficient way to systematically identify sites running vulnerable software. 
  
• Create a file with a random name in your html directory. Do not reference the file in your site. Grep your web logs daily for the file being accessed. Any hits may indicate that your site has been compromised.
  
• Scan for file differences and notify of differences
  

Your responsibilities as a site owner

• Perform frequent off-site backups.  Even if you have a local backup strategy, such as to another server, it is imperative to maintain an offsite backup.  While it doesn’t happen often, datacenters are broken into and servers are phyically stolen.
• Do not store sensitive data like credit card numbers.  Just don’t do it.
• Change account passwords regularly

Hacked!

Posted by jerry as Hacking, Security

I don’t think a lot of people who run sites like to admit this, but I was just hacked.  It was extrodinarily interesting… I had the advantage of watching it happen. 

 I have a server at a colo running Freebsd and cpanel.  I host a hand full of sites, and keep telling myself “someday, I’m going to get serious about it”, but life keeps getting in the way.  I personally run a bunch of sites on that server, including this one. 

So anyhow, after I wake up, I grab my laptop from the side of my bed and check email, weather and the usual stuff.  As noted in a previous post here, I’ve been trying to increase the number of visitors to one of my sites - syslog.org, so I had a tail -f running on the apache log file.  Nothing out of the ordinary at first.  Then, if I had hair, it would have been standing up - I saw requests to part of the site that clearly had filesystem path’s in them.  Paths for other accounts on my server.

So, sure enough, when I looked more closely, the requests were going to a file called “public_html/forum/avatars/.php”.  The site is running the Simplemachines forum software.  I copied one of the requested urls into my browser, and BAM! a really nice control panel for my server, the main part of which is a filesystem browser.  Yikes! 

I first moved the .php file to a directory outside of the web path then I logged into WHM and suspended all of the accounts and then started looking through logs to see what had been done.  It was clear that the attacker was going through the public_html directories for all of the sites and replacing files with “Hacked by XXX”.   But only a few files.  I was able to find each file that had been replaced by referencing the logs.  A check of date/time stamps and a comparison against a backup verified that. 

I went back to the avatars directory on the syslog.org site, and found a file called erne.txt.  When I open it up, it’s a file used to bypass PHP safe mode.

I want back, changed passwords, replaced files from backup, and whatnot.  I did find a suspicious user account “courier” in /etc/password.  What made it suspicious is was at the bottom of the file.  I deleted the account and searched for any files owned by that account.  I logged into my dev server and found that the same account existed in the same place, so that was a false alarm.  Thankfully.

So, I went back to the monthly web logs and decided to see how long .php has been on the system.  I found that it was first accessed on Oct 20.  I grepped  through the log for the IP that first accessed and saw that it had come to my site via a google search for “powered by SMF”.  Then I remembered (!) that on Oct 20th, I had been looking at my logs as well, and saw that very request, which prompted me to make sure I was up to date with SMF.  Of course I wasn’t - I was runnig 1.1.2 and 1.1.4 has recently been released.  So, I did the upgrade and didn’t look back.

After looking at the logs a little more, it became evident that they were linking from the site http://turk-h.org.  That site is a defacement content tracking site.  The few sites that they were able to register show that the hack was “political”.  The group that is responsible for the attack has a site here: WwW.BilisimSecurity.Com.  Why is the middle “w” always lowercase on hacker sites??? 

So, here are the lessons I’ve learned (so far):

1. ALWAYS ALWAYS ALWAYS keep your software up to date
2. A correllary to #1 above - a consistent approach to verifying that all software is up to date is desperately needed.
3. Open source web apps really really really need to stop adding a “powered by” line at the bottom of websites that use their software.  This makes it incredibly easy and efficient to find sites to hack.
4. Keeping your logs is really important.  They can in really handy today.
5. Using phpsuexec would have drastically limited the impact of the attack.
6. An automated method to determine if something has changed or been added in a directory tree would have provided me with almost 2 weeks of notice to resolve the issue.
7. The hacker tools are quite sophisticated.  I have retained copies of their tools.  I will not be making them available as I don’t want to spread them any more than they already are.
8. A tool that parses the apache logs for filesystem components (outside of the public_html tree) would have provided a notice that something has happened, though it would really have been too late to stop the attack.

Proud moments

Posted by jerry as Uncategorized

I have to take a minute to brag about something.  I’ve run another site - http://www.syslog.org for several years now.  Recently, it’s been cited as a source for several high profile papers, like this one:

http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf

and this one:

http://icsa.cs.up.ac.za/issa/2004/Proceedings/Research/066.pdf

On a humorous note, there is a site that claims to donate money to open source projects, including syslog:

http://www.nayika.com/partners/partners_open.html

You may have guessed that no money has changed hands, and you would be right.