Google-Hacking Google's Safe Browsing List

I discovered a kind of cool trick the other day with the Google safe browsing service. When doing a client vulnerability assessment or pen-test, if the customer has an assigned AS number, you can quickly check the Google safe browsing list to see all the sites from their network, found to be serving up malware in the past 90 days. For example, if you were doing an assessment for a customer than owned the AS number 11643, you would use the URL in the following format:

http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=AS:11643

As your customer is probably not knowingly going to host malware, identifying these sites proves valuable as it is probably still exploitable. More often than not, I have discovered that these sites have been compromised through weak/ easily guessable FTP or SSH usernames and passwords.

Taking this a couple steps further, I noticed that Google has published an API for this service.
An interesting application of this would be to take all the discovered host names, when enumerating a client's IP space with something like Fierce Domain Scan, and feeding each of those sites into the Google Safe Browsing list.

There are several other applications of this. Say for instance you are a web hosting provider. You can semi-monitor your hosted customers and notify them when they ended up on the "bad list". This can either be done by plugging in your AS number or by enumerating all the sites and plugging those into the API.

Another application for this, could be for a security company to identify potential customers. For example, working for a security vendor here in Thailand, all I would need to do is identify a few Thailand specific AS numbers, and away we go:

AS 7470 , AS 9737 , and AS 9931

Please note, for those who are not familiar with the naming conventions in the .th TLD, go.th is reserved for government sites and mi.th is reserved for military sites. With that knowledge, the results above are sort of shocking, no?

Scam Protection - Open Letter to the bar owners of Thailand

Here in Chiang Mai, as well as various other parts of Thailand, one seemingly popular scam, is collection of music royalties and levying of fines for infringement. These "copyright police" show up with dodgy documents and a uniformed police officer in tow. These uniformed officers, either through sheer ignorance or an agreement for a cut of the profits, allow the "copyright police" to seize computer equipment, confiscate CD's, and even will arrest "violators" and take them down to the jail.

You can read more about this horrible scam here and here.


So, obvious legalities aside, I asked myself, "Why are they making it so easy?" "What would *I* do, if I was running bar in Thailand?" [Something that is actually part of my long-term goals, but that is a story for another day!]

So, Bar Owners of Thailand, here is what I would do:

First off, I would stop storing questionable items on my computer. On my personal computer, you will not find any mp3s, boot-legged movies, pornography, pictures of old girlfriends, etc.. Not saying I don't possess these items, I am just saying they are NOT stored on my personal computer. Now if I was going to have a PC sitting out in a public place of business, I think this rule of thumb should be infinitely more applicable.

So, how can I make this work? Easy! First I would head down to Pantip (or any other computer mall of choice) and buy a nice, cheap, external USB hard-drive. Next I would down the free/ open-source tool, TrueCrypt. I would use this to create one or two large encrypted volumes on the USB device. In these encrypted volumes, I now have a handy, safe, and very portable place to store my all questionable items!

If anyone ever tried to catch me with said questionable materials, hopefully me or my staff might have time to quickly disconnect the USB drive and physically move it out of sight. If not, it does provide me with some measure of plausible deniability.

There are no questionable items to be found on my computer, nor the encrypted device... Go ahead and take a look... I challenge you to show me these items! Most likely they aren't going to be able to.

If for some strange reason, the "inspector" is somewhat intelligent enough to figure out the encrypted USB storage trick, and presses me for the password, no problem! A simple white lie, for instance, "an unknown person accidentally left it behind.. I have no clue what the password is. I, being nothing short of a good Samaritan with the best of intentions, simply plugged it into my computer in hopes that I could determine the proper owner and return it to them."

What can they do? And better yet, what can they prove in a court of law? :)

[Disclaimer, I am NOT a Lawyer. I am NOT advocating unauthorized possession of copy-written materials and/ or the mis-leading of authorities. I have carefully reviewed the prevailing law here, the Thailand Computer Crime Act of 2007, and do not see indication of what I am proposing is in violation of any sections of this law. However, again, I am NOT a lawyer and more importantly I am NOT a Thai lawyer.]

On the off chance this helps someone and you end up saving 50,000 THB, feel free to comp my drinks next time I visit your fine establishment.

A Big F-U to GoDaddy

So its been a very busy month. I took some holiday time at the beach. From there I was in Bangkok for a week of Vendor training. My return home was filled with long days and nights trying to get caught up as well as, prepare for a week long business trip to Singapore next week.

During all this hubbub of activity, I accidentally let my domain expire. Opps! Oh well, there is a grace period, I can just renew it right? Not exactly. Turns out that the grace period is only 12 days. After that GoDaddy penalizes you with on outragous $80 USD "Registry Redemption Fee". Umm, what? Srsly?

"Ok, no problem", I think. I'll just re-register it at another Registrar. NOPE! The domain still shows up as registered to me, but locked by GoDaddy.

So..... Just wait for it to expire and then pounce on it again to re-register? NOPE! Not so easy. Then GoDaddy puts your domain up for Auction for 10 days! Ok, so wait for the auction to finish and hope nobody bids on it? WRONG AGAIN! GoDaddy then puts your domain up on a 5-day Closeout auction /Firesale!

So, in reality when GoDaddy says "Registry Redemption Fee" what they really mean is "We Are Holding Your Domain Hostage Until You Pay an Ungodly Ransom".

Now, because I am in Thailand, lets put that $80 USD into prospective. The average Thai salary here in Chiang Mai is about 10,000 THB/ month. Assuming a 4 week month and 40 hours per week (most work more hours and days than that), that means the average pay here is 62.5 THB/ hour. Exchange rate is approximately 35 THB per $1 USD. That means that GoDaddy's ransom money equates to about 45 hours of work here. MORE than one weeks pay!! Or in other terms, about 93 average lunches (30 THB).

So GoDaddy, as I really have no recourse other than to publize your horrible business practises. Additionally, did a little bit of google searching, and seems I'm not the only one upset with GoDaddy.

I urge everyone to take a look at (nmap) Fyodor's NoDaddy site.

So, again, screw you GoDaddy. Enjoy the extortion money.

Tip of the Day: Keeping Web Directories Clean

Just a simple system admin tip of the day.

One issue that I tend to run into quite frequently, are linux directories that are full of crude from other people and their OS's. A perfect example of this, is a web server, where multiple people have access to the directory to upload new content, etc. Invariably you end up with backup files, systems files from VSS, Windows Thumbs.db files, Apple OSX .DS_Store files, etc.



So to help me clean house, I add 5 or 6 simple rules to the end of my mightly cron jobs:

cd /var/www/html

find . -name "*.bak" -exec rm -rf {} \;
find . -name "vssver.scc" -exec rm -rf {} \;
find . -name "Thumbs.db" -exec rm -rf {} \;
find . -name ".DS_Store" -exec rm -rf {} \;

This will seek out and all these files for me, on a nightly basis.

CentOS patching

In my normal everyday job, I am tasked with managing and maintaining about 30-40 production CentOS servers. Being a security guy, I maintain a pretty rigorous patching routine. However, because these servers are customer production servers, one very important caveat is that I need to do everything I can to minimize customer downtime.

Normally when I patch a server, my routine is:

yum check-update (check what updates are available)

yum -y update (update everything)

And if the list produced by check-update shows the kernel or kernel-headers packages in the list, I promptly reboot the server. This translates into about 5 minutes of downtime for the customer as the server reboots.

So that got me thinking. Is every kernel update critical or can they easily be delayed? So then I stumbled across this excellent plug-in for yum.

yum-changelog-1.1.10-9.el5.centos

Name : yum-changelog
Arch : noarch
Version: 1.1.10
Release: 9.el5.centos
Size : 12 k
Repo : installed
Summary: Yum plugin for viewing package changelogs before/after updating
Description:
This plugin adds a command line option to allow viewing package changelog
deltas before or after updating packages.

Perfect! That will allow me to see exactly what is changing with each new version of the kernel. So I install that with:

yum install yum-changelog

Now we can use yum to show us the change log for certain packages. So, if I want to see the change log for the kernel related package, I could run something like:

yum update kernel kernel-headers --changelog

This will produce output similiar to:

Changes in packages about to be updated:

kernel-headers - 2.6.18-92.1.22.el5.x86_64
* Wed Dec 17 06:00:00 2008 Karanbir Singh [2.6.18-92.1.22.el5.centos]
- Roll in CentOS Branding

* Sat Dec 6 06:00:00 2008 Jiri Pirko [2.6.18-92.1.22.el5]
- [misc] hugepages: ia64 stack overflow and corrupt memory (Larry Woodman ) [474347 472802]
- [misc] allow hugepage allocation to use most of memory (Larry Woodman ) [474760 438889]


Ah, ha. As I suspected. Two memory related bugfixes and CentOS branding. Because we are currently not expirencing any memory related issues, this patch does NOT rate as critical and warrent immediate customer downtime. This can be delayed.

So now I can apply the other patches and exclude the kernel upgrades with:

yum update --exclude=kernel,kernel-headers

Now, I have a script that runs nightly on all my CentOS servers. This script gathers nightly statistics, logs entries, etc from my servers and emails it to me. This is pretty much jsut a CentOS port of my old Gentoo Update Script, with some CentOS speficic changes and additional features. The other thing it does, is generate a list (via yum check-update) of all the updates required. So the question now is, now can I get this interactive command to run via an automated script? The easiest way I could come up with is:

echo n | yum update kernel kernel-headers --changelog

Probably not the cleanest way, but does the job very well.

Bungling Sys Admin Gets It Right

Wanted to point out an excellent post on The Bungling Sys Admin Blog. It's a response to TaoSecurity's Recommendations for Introduction to UNIX post. Bejtlich, who tends to be a bit of a FreeBSD homer, recommends FreeBSD with Ubuntu and/or Debian as alternatives.

Matt, who has about 10 years of corporate linux administration expirence under his belt, makes an excellent counterpoint. His arguement is, if you are going to spend the time to learn, why not learn on a distribution that there is a high probability you will encounter in a real world production environment? He offers up Red Hat Enterprise Linux, CentOS, and Solaris as much more applicable alternatives.

I wholeheartedly agree with both both the choice of OS's and the reasoning behind them. Although I do have specific figures to back up my assertions, I would say that based on my expirences, these 3 OS's compose the lion's share of the *NIX market place and that if you were going to be maintaining a unix/linux based system in a real worl corporate environment, very high likely hood it will be one of these.

Cudo's to Matt for hitting the nail squarely on the head.