The talk around Twitter right now is the phishing scam via Direct Message, as reported by many including Read Write Web, Mashable, and Chris Pirillo.  The victims include Twitter accounts for Barack Obama, Fox News, Britney Spears, and Rick Sanchez of CNN.   Getting their Twitter account hacked is a potential public relations nightmare.  The bait was a simple message to direct recipients to a fake Twitter login page, and enters their Twitter passwords.  Unsuspecting users went ahead and entered their information.  A similar trick was done in e-mail for the longest time using pages that looked like E-Bay, PayPal, or a banking site.

I get similar complaints with the websites that I maintain.  What can server administrators do to figure out who’s behind these attacks?   Here are the steps I take:

1. Ask the business or customer when the suspecting hack happened.  Find out the exact date and time, if possible.
2. Comb through the web server logs to find the IP addresses of the hackers using the date and time range reported by user.  For example, in Apache HTTPD, the file is normally called “access_log”.
3. Most hackers try multiple times, in quick successions.   In this case, running through web logs through an analyzer like Webalizer or Awstats will reveal the IP address with the most hits, within a specified time range.
4. Find out who the IP belongs to using tools like dig or nslookup.
5. Report the offending IP address to the Internet Service Provider (ISP) as indicated by the lookup tool.  It can be done via email to postmaster@<isp.name> or abuse@<isp.name>.
6. Depending on the severity, a fax or a phone call to the ISP may be required.  This is usually done when the hacking continues and there’s no indication of the ISP intervention to stop it.
7. Start using the web server IP filtering features to blacklist the offending IPs.  For example, in Apache it can be done via Deny directive for doc-root in httpd.conf or .htaccess file.
8. For known hackers’ IP addresses, make it permanent by blacklisting them in the firewall or router level.

Users do get complacent with their username/password.  They type (or even share!) passwords to others without thinking twice.  With more and more sites requiring a login, it’s easy to forget about checking the legitimacy of the page presented on the web browser.  Proactively, the web applications need to be modified to prevent login hacking such as:

• Using Secure Socket Layer (SSL)   With SSL, most phishing sites will not bother with it because of the cost involved.  If logins are not done securely, users need to be extra careful.
• Using OpenID, the open standards user login.  A site needs to be registered with OpenID to be able to use this service.  This removes the guesswork if the site is legitimate or not.

Hopefully the word is out for both users and web developers, to do whatever is required to secure login passwords.

Image Credit: Ashenzil