Using SSL To Improve Internet Security – A Simple Idea

Posted by jerry as Security, technology

I was headed out with my son today to one of the local jump/bounce places for the birthday party of a neighborhood kid. Having been to these places before, I know that they generally offer free wifi access. I packed up my laptop, thinking that I could work on some web site issues I have been trying to fix.

I got to thinking about the risks of someone sniffing my logins to the sites. That reminded me of a post I wrote recently about an idea to conserve IP addresses. Most of my sites are hosted on a shared IP address on my server. I simply don’t have enough IP addresses to cover all of my sites. Without dedicating an IP address for each, using SSL is simply not possible.

The vast majority of web sites do not have SSL capabilities, in the same way that mine do not.  At the same time, the instances of hacking, snooping and data theft are spiraling out of control.  As well, the “Starbucks” culture of camping out in a restaurant to surf the web on a laptop is growing, leading to many more opportunities for the trivial capture of passwords and other sensitive data.

Certainly, financial data such as credit cards and logins to financial institutions are generally well protected by SSL.  The types of information that can be lost at the local coffee shop is more likely to be a facebook username and password, or the username and password to a webmail account.  Useful to the hacker, and damaging to the victim, but not at the same level of severity as a credit card number.

So, in a nutshell, modifying the SSL protocol to allow for the negotiation of the requested domain *before* the SSL tunnel is established has another advantage – allowing sites on shared IP’s to use SSL to protect the private information of the users of a site.

It seems to me that the certificate authorities would jump at supporting this idea – it opens a substantially large new market.

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.

Current crop of php include attempts

Posted by jerry as Hacking, Security

I’m not sure why I’m so fascinated by this crude and ineffective hacking attempt, but I am.  Here are the currently active hosts:

http://www.mta.cl/galeria2/galery2.jpg??
http://www.mta.cl/galeria2/galery.txt?
http://www.freewebtown.com/w8ting/safe.txt??
http://tools.aerofito.com/safeon.txt??
http://64.203.191.222/.check/c.txt?
http://www.ohanlonpaving.com/phpmic.txt.txt?
http://rotation.wooshck.org/image/safe.txt?
http://83.19.144.26/bo.do??
http://www.old2sold.net/newpitbulonspread.txt?
http://coolpc.com.tw/evaluate/safe?
http://www.ena-gmbh.de/download/cikos.txt?
http://www.dip-kostroma.ru/bak_skompa/themes/runcms/menu/images/.asc/www?????????????????????????????
http://www.freewebtown.com/komandan/tool/q3.txt?
http://www.manycontentz.com//ine/img/contr.txt??
http://ninaru.hut2.ru/images/cs.txt?
http://amygirl.land.ru/baby?
http://electro.lydo.org/rfi/id.txt?
http://freewebs.com/chika_manis_banget/cmd.txt???
http://www.martinschaab.de/php/id.txt?
http://www.realtyna.com/about.gif??
http://zamkad.ru/pub/buffer_upload/…/cmd.txt?
http://www.realtyna.com/safe.txt??
http://www.cluelesstravel.com/guestheath/id.txt??
http://bondick.net/flashchat/nick_image/htaccess?
http://kiopmanminsuion.chat.ru/http?
http://phila.wonbuddhism.info/bbs//skin/zero_vote/images/btn_black.gif?
http://193.109.188.20/0/templates/rhuk_solarflare_ii/css/contr.txt??
http://www.martinschaab.de/php/phpSecurePages//phpSecurePages/u.txt?

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.

NSA Encryption backdoor?

Posted by jerry as Security

I am always skeptical of conspiracy in a given situation. The article is basically claiming that the NSA knowingly put a backdoor key in to an algorithm, then forced it into the standard doc. Oh, and it’s apparently ‘obvious’ that secret keys exist, whether known or unknown.

This reminds me a lot of the debate about the sboxes used in DES – the assumption was that the government did it to be able to crack DES, but turned out to be an intentional design element that actually increased the security of DES.

I can think of a few scenarios off hand:

1. The creator knew about the weakness and intentionally chose values that are very difficult to reverse engineer.  The algorithm is substantially secure to be trusted in spite of this.

2. No such set of second numbers are available, and this is a misunderstanding.

3. The creator legitamately did not know about the issue.  People in the NSA are crapping bricks now.

4. There in fact is a secret set of numbers in the algorithm and the NSA has a specific use in government applications for a computationally intensive, and recoverable application. They know that general use is not likely because of those two fact.

I can see some utility in a computationally expensive encryption algorithm. I have to believe that the NSA didn’t ‘sneak’ in an algorithm that is so obviously inferior, expecting the world at large to use it so they can snoop. Despite iraq and 9/11, they really aren’t a dumb organization.

I think the real story here is that we have to be so suspicious of the motives of our government. Given the many spying stories, the telecom amnesty issue, Guantanamo Bay, the TSA, etc, it seems like a plausible story that the NSA really would do such a thing.  In that light, maybe I’m wrong – maybe they did try to pull one over on us. One thing’s for sure – we’ll never get an answer we can trust from the CIA.

Insight into web attacks

Posted by jerry as Hacking, Security

I’ve been fairly attentive to my web server logs lately.  I noticed something strange this morning in the logs for syslog.org:

200.88.114.166 – - [12/Nov/2007:10:21:21 -0500] “POST /forum/index.php?action=quickmod2;topic=249.0 HTTP/1.1″ 200 11257 “http://www.syslog.org/forum/index.php?PHPSESSID=5537d4fd7661fd20c7aa6aa8b3f05a05&topic=249.msg2124” “Opera/9.0 (Windows NT 5.1; U; en)”

Now, all day long, bots and sites are trying to submit stuff and run automated hacking tools.  This entry caught my eye because it had a session ID.  Not sure why it caught my eye, but it did.  So, I grep for the session id and get this other line:

69.46.16.2 – - [12/Nov/2007:10:21:14 -0500] “GET /forum/index.php?PHPSESSID=5537d4fd7661fd20c7aa6aa8b3f05a05&topic=249.msg2124 HTTP/1.1″ 200 22114 “-” “-”

Grepping the log files for both IPs only gives those two lines.  What I find particularly interesting is that they are clearly different sources, but obviously working together to somehow do something.  Then I decided to look at a longer term – 3 months.  There were a total of 801 hits that included that session ID, going all the way back to the start of the logs.  The sources where from hundreds of different IP addresses.  Some of them running through a battery of tests, but most of them only occuring once.

A search of google for the string turns up nothing – though it probably will now that this article is up.  So, what does that tell me?  At some point long ago, someone probably logged into SMF and included the resulting URL into a database that is used by bots to launch attacks from. 

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.

Biometrics are a terrible idea

Posted by jerry as Security

Authentication is something that I’ve given a lot of thought to.  I see the world beginning to embrace biometrics as a mainstream method of authentication and it really scares me.  We seem to think that a fingerprint, retinal scan, or hand geometry is the holy grail of identifying a person.  In fact, the most we can reasonably hope to get out of biometrics is an initial guess at identity. 

Let’s take a finger print.  It’s a password that you cannot change, ever, yet you leave copies of it everywhere you go.  Retinal scans are harder to copy, but hand geometry is likely not hard at all.

The fundamental problem is that someone can easily and economically duplicate nearly any key biometrics that would be used for authentication without the owner or authenticating party knowing.  The ultimate in authentication is and will always be possessing something that is reasonably hard to duplicate, such as a pin generating fob.  You either have it, and no one else can successfully pose as you, or you don’t and you know that someone may be trying to pretend to be you.  Pairing that with a pin that is memorized is an effective combination, but the uniqueness of the device is the most important factor.

Basing authentication on a physical trait, finger prints, retinas, dna, hand geomretry, etc, may have some utility for trivial things like entering Disney World, but for things like legally binding contracts and access to sensitive data or sensitive areas, biometrics are simply too weak.