How to Disable Credit Card RFID

I have an American Express Blue card which includes an RFID chip (because waving your card is so much easier than swiping it.) Unfortunately, if you have one of these (or a credit card with PayPass) your card is vulnerable.

Fortunately, it’s easy to disable the RFID chip in your credit card. Here’s what I do:

  1. Locate the chip – this is easy with my card since it is transparent and I can see the chip. If your card isn’t transparent, the chip can be located by finding a slight divot in the plastic (usually on the back.)
  2. Stab the chip a few times with a sharp object – I use my trusty Leatherman Super Tool, but any sharp object will do. I stab from the back of the card because there’s less plastic to go through to get to it. As you stab the chip, you’ll feel some crunching or grinding. If you don’t then you probably missed the chip.
  3. Now you can walk around confident your credit card information can’t be read over the air by some nefarious evil doer.

LifeLock Identity Theft Prevention - Save 10%

Fear == money

The 2009 budget for homeland security is $50 billion.
The budget for the National Highway Traffic Safety Administration is about $1 billion.

From the article: “We fund terrorism prevention at about $17,000,000/fatality (i.e., $50 billion/3,000 fatalities) and accident prevention at about $25,000/fatality (i.e., $1 billion/40,000 fatalities)”

This is just one more example that the government’s priorities are way messed up based on where it’s spending money.

original article here

AWS Security Whitepaper

AWS security whitepaperAmazon just posted a security whitepaper which describes the security measures they have in place to protect their customers. It’s a short read (9 pages) and I strongly recommend it if you are using EC2, S3 or SimpleDB for anything. They explain their security measures and make recommendations for further protection their customers can put in place to protect their data.

One major concern I had was addressed by the whitepaper, “The AWS proprietary disk virtualization layer automatically wipes every block of storage used by the customer, and guarantees that one customer’s data is never exposed to another.” I was always curious about those disk devices on EC2 and what data might be lingering on them but never had the time to investigate.

Here’s an interesting snippet regarding their physical security:
“Amazon has many years of experience in designing, constructing, and operating largescale data centers. This experience has been applied to the AWS platform and infrastructure. AWS data centers are housed in nondescript facilities, and critical facilities have extensive setback and military grade perimeter control berms as well as other natural boundary protection. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, state of the art intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication no fewer than three times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.”

Linux(in)security.com

I was just going through all of my items in google reader (which includes linuxsecurity.com) and it looks like someone has managed to hack some spam into their newsfeed. I find it mildly entertaining that a site so focused on security is being used by spammers.
Let me clarify that this abuse is most likely due to a bug in the software they’re using to run on their site and not Linux.
Since they’ll probably clean it all up, I grabbed a quick screenshot to show you what I saw:

New version of AVG anti-virus available

For those of you that run AVG Free (free for personal use) there is a major update available. For those of you that don’t run any antivirus software on your computer – SHAME ON YOU!
This new version includes anti-spyware, so if you have AVG’s anti-spyware (Ewido) installed, you’ll have to uninstall it first (go to Control Panel, then Add/Remove Programs.)
Here are a few bonuses of AVG Anti-Virus Free Edition:

  • available free of charge to home users for the life of the product
  • virus database updates are available for the lifetime of the product
  • doesn’t slow your system down (like other anti-virus systems I’ve seen)
  • integrated spyware protection
  • LinkScanner feature that gives users safety rankings for their Google, Yahoo, and MSN searches.

So, go and download it!
The install only takes a few minutes so don’t put it off, do it now!

Encryption passphrase protected under 5th amendment

This is kinda old news, but interesting anyway. According to this story, “A federal judge in Vermont has ruled that prosecutors can’t force a criminal defendant accused of having illegal images on his hard drive to divulge his PGP (Pretty Good Privacy) passphrase.”

For those of you that don’t remember, this part of the 5th amendment says, “No person…shall be compelled in any criminal case to be a witness against himself…”

I guess I can change my encryption passphrase to something other than “I don’t know.” now.

My interrupt-driven life

SlimeHere I am, peacefully working at my computer when I’m interrupted by a text message on my phone:

** PROBLEM alert – someserver.somewhere.com/SSH is CRITICAL **

That’s not a good thing. Hoping it’s a false alert, I try to ssh in. No luck. I try again. Still no luck. And a third time, Yes! I’m in. Let the troubleshooting begin.

I check to see what processes are running and sure enough, I find a culprit. There are a ton of sshd processes going. I take a look at auth.log and it’s full of “Failed password for root from 218.145.160.100 port 55739 ssh2” messages (about 9,000 of them.) Here’s what’s going on: someone is trying to login to the server most likely by trying a bunch of passwords in a brute force attack. A brute force attack consists of trying every possible password until you find the right one. The attack doesn’t really concern me since I don’t allow password logins on most of the servers I manage. The excessive login attempts are a little annoying.

One command later and all traffic from that IP address drops into oblivion.

iptables -A INPUT -s 218.145.160.100 -j DROP

With that band-aid applied, it’s time to get something better in place for the long term. A while back there was some discussion about preventing or slowing down such attacks on the SLLUG email list and some people posted scripts they use to deal with it. Here is my current version of one of those scripts:

#!/bin/bash
case "$1" in
start)
# Put IP addresses for allowed hosts into this, separated by spaces.
SSH_ALLOWED="123.45.67.89 98.76.54.32"

iptables -A INPUT -p icmp -m state --state NEW,ESTABLISHED --icmp-type echo-request -m limit --limit 2/s -j ACCEPT
iptables -A INPUT -s 127.0.0.1 -j ACCEPT

# Allow TCP/UDP connections out. Keep state so conns out are allowed back in.
iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT

# Allow ICMP out and anything that went out back in.
iptables -A INPUT -p icmp -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED -j ACCEPT

#put any custom rules for you rserver in this section
iptables -A INPUT -s 218.145.160.100 -j DROP
iptables -A INPUT -p tcp -m tcp --dport 111 -j REJECT
iptables -A INPUT -p tcp -m tcp --dport 11211 -j DROP
iptables -A INPUT -p icmp -j DROP
iptables -A INPUT -p udp -j DROP

#now for the ssh stuff
iptables -N SSH_Brute_Force
iptables -F SSH_Brute_Force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_Brute_Force
for IP in $SSH_ALLOWED; do
iptables -A SSH_Brute_Force -s $IP -j RETURN
done
iptables -A SSH_Brute_Force -m recent --name SSH --set --rsource
iptables -A SSH_Brute_Force -m recent ! --rcheck --seconds 60 --hitcount 5 --name SSH --rsource -j RETURN
iptables -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt: "
iptables -A SSH_Brute_Force -j DROP

;;
stop)
iptables -F
iptables -X SSH_Brute_Force
;;

*)
echo "Usage: $0 {start|stop}" >&2
exit 1
;;
esac

This is an init script, so I put it in my /etc/init.d directory and set it up to run when the server boots up. What it does is only allows 5 SSH connection attempts per minute based on the source’s IP address. From there, it blocks and logs any connection attempts. Two words of warning when working with IP tables; be careful. It’s very easy to block yourself from accessing your own server. I’ve done this more times than I care to mention and had to take a drive to the datacenter or call their helpdesk to make things available again.

WordPress comment SQL injection attempt

Red rock layersI have comment moderation turned on for most of the blog sites I manage. As a result, if someone new comes in and posts a comment, I get a nice email letting me know that I need to approve it. Yesterday, I got one that said this:

Author : Bill366758271','258878095billy@msn.com','','171.85.174.159','2008-03-11 22:28:47','2008-03-11 22:28:47','','0','lynx','comment','0','0'),('0', '', '', '', '', '2008-03-12 22:28:47', '2008-03-12 22:28:47', '', 'spam', '', 'comment', '0','0' ) /* (IP: 124.217.231.53 , 124.217.231.53)
E-mail :
URL : http://None
Whois : http://ws.arin.net/cgi-bin/whois.pl?queryinput=124.217.231.53
Comment:
None...

It looks like they were trying to bypass the comment approval process with an SQL injection attack. I’m not sure which versions of WordPress are vulnerable, but I’m sure there are some older ones that are.