Tag Archives: Information Security

Mobile Device Ownership Verification

Posted on by

Having recently been a participant in a ridiculously annoying and unfortunate set of easily avoidable circumstances involving my own smart phone, I’m of the mind to put together a little guide for use by those in possession of a lost phone and faced with someone claiming it’s theirs, as well as those seeking to reclaim a phone from the person or business currently in possession of it.

YOU ARE IN POSSESSION OF A DEVICE SOMEONE IS CLAIMING

All of the following ideas assume that you are, in fact, of the mind to return the device. If you’re just going to throw it away, or keep it for yourself, then naturally you can ignore this entire post.

Before any of the following steps are taken, ask that the claimant produce a photo ID, and make note of the name for your own records. You might consider asking for additional contact information, such as an alternate phone number and/or email address.

Prior to showing the claimant the device, ask the claimant to describe the carrier, make, and model of the device. Inspect the device for any tell-tale marks, scratches, or unique behaviors (loose keyboards, connections, buttons, etc.) that the device exhibits. Ask the claimant to describe the device, and listen for any description that matches the unique characteristics you noted. Do not volunteer any information about the device.

In each of the following situations, run through at least one of the verification options. Performing all of them might be overkill, but performing none of them is irresponsible.

The Phone Has Power and the Screen is Locked

  • Make the claimant call the phone from another phone. This will, at the very least, prove knowledge of the phone, if not ownership.
  • Make the claimant unlock the phone prior to leaving with it. This will prove a greater degree of knowledge of the phone and owner, if not ownership.
  • In the case of Androids and Blackberry’s, remove the battery and call the carrier. Give them the IMEI and the name of the claimant to confirm the carrier records match the person claiming ownership. Original iPhones have the serial number and IMEI engraved on the back metal case. For the iPhone 3G, iPhone 3GS, iPhone 4 (GSM model), and iPhone 4S, the SIM tray displays the IMEI number.

The Phone Has Power and is Unlocked

  • Make the claimant call the phone from another phone.
  • Make the claimant verify contents of the phone, such as contact names, pictures, home screen icons, installed applications, or any other unique aspect of the phone contents that prove intimate knowledge of the device. This might appear to be a breach of privacy, but if privacy was a real concern on the part of the owner, it would not be allowed to remain unlocked beyond a very short idle period.
  • In the case of Androids and Blackberry’s, remove the battery and call the carrier. Give them the IMEI and the name of the claimant to confirm the carrier records match the person claiming ownership. Older model iPhones do not provide physical access to this, but do provide this information on the About screen. Original iPhones have the serial number and IMEI engraved on the back metal case. For the iPhone 3G, iPhone 3GS, iPhone 4 (GSM model), and iPhone 4S, the SIM tray displays the IMEI number.

The Phone Does Not Have Power

  • If a charger is available, charge the device until such a time as it will boot, then proceed with one of the following methods:
    • Make the claimant call the phone from another phone.
    • Make the claimant unlock the phone prior to leaving with it.
    • Make the claimant verify contents of the phone, such as contact names, pictures, home screen icons, installed applications, or any other unique aspect of the phone contents that prove intimate knowledge of the device. This might appear to be a breach of privacy, but if privacy was a real concern on the part of the owner, it would not be allowed to boot into an unlocked state.
  • In the case of Androids and Blackberry’s, remove the battery and call the carrier. Give them the IMEI and the name of the claimant to confirm the carrier records match the person claiming ownership. Original iPhones have the serial number and IMEI engraved on the back metal case. For the iPhone 3G, iPhone 3GS, iPhone 4 (GSM model), and iPhone 4S, the SIM tray displays the IMEI number.

YOU ARE TRYING TO CLAIM A DEVICE

If you have lost and are claiming a phone, then you should voluntarily offer the following methods to confirm the device is, in fact, yours, rather than someone else’s. This could save you significant inconvenience and will certainly save the real owner significant inconvenience and concern.

  • In all cases, inspect the physical condition of the phone, looking for any tell-tale marks, scratches, or unique behaviors (loose keyboards, connections, buttons, etc.) that you know your device exhibits.

The Phone Has Power, And the Screen is Locked

  • Unlock it. Additionally, in the very unlikely case that you and another owner of the same make and model phone use the same unlock code or pattern, verify the contents of the phone as belonging to you. If the phone has been tampered with, this will also give you the opportunity to identify any issues that might have arisen while it was out of your possession, and follow up with the individual or business who has had possession of the device.

The Phone Has Power, And is Unlocked

  • Confirm the contents of the phone are yours. You know what’s on it. Make sure it’s what you’re expecting. This will also allow you to respond immediately if the phone has been tampered with.

The Phone Does Not Have Power

  • Either bring a charger, or have the person or business call the carrier to verify the IMEI matches what they have on record for your account.

You Send a Friend to Pick it Up

  • If you absolutely must send a friend to pick it up in your stead, provide them with enough identifying information as their trustworthiness allows, whether it be knowledge of the condition of the device, or knowledge of the unlock code or pattern and the contents of the device, so that they are able to answer any questions arising from the above methods and retrieve the correct device.

The above methods, if followed intelligently, will at least provide reasonable assurance that the right device leaves with the right person. No method is fool proof, and a truly determined thief will have done the research to be able to circumvent some of the methods described. But at least you can say you have done what you can to ensure that the device is in the right hands, rather than just giving the device to the first person who walks through the door saying they left behind a black phone with a screen on it.

Consider this a living guide that I will update with any good suggestions left in the comments.

Update to Malware Protecting Script

Posted on by

In an attempt to be a little more friendly in terms of bandwidth to the strapped folk over at Malware Domains, I’ve retooled the script I wrote about in the post To Be Protecting Against the Malware.

I’ve added some lines to take advantage of remote zipped files (.zip), which will help them by reducing the number of bits we’re pulling from them.

I’ve added some lines to copy the downloaded malware zones file to other servers behind my firewall, which will help them by not making individual connections from each server to pull the files. I just set up a cron job on each internal “slave” server to bounce named every morning timed for after this process is complete.

Here’s the updated code. It is, as is my wont, rather verbose. It is considerably more verbose than other examples out there that take care of this same problem, but as I said, such is my wont.

The URLS array is filled with fake hosts right now b/c the zipped format is still in testing. When the folk at malwaredomains.com think it’s ready for public consumption, I’ll put the real hosts back in.

Also, it’s relatively untested, and I expect to be tweaking it. Use at your own risk.

On the “master” server, I’m using this…

#!/usr/local/bin/bash

# To know where script is running
HOSTNAME=$( hostname )

# To put file where named can see it
BLACKHOLEDIR=/var/named/etc/namedb/blackhole

# To name file so we know what named seeing
TMPZONEFILE=tmp.malwaredomains.zones
ZONEFILE=malwaredomains.zones
ZONEFILEBACKUP=malwaredomains.zones.bak

# To get updated file from remote server
URLGRABBER=/usr/local/bin/curl
USERAGENT="Malware Domain Grabber ( ${HOSTNAME}; unix; BASH )/0.1"

# To keep quiet while am getting file
URLGRABBEROPTS="-s -f"

# To know where file is hosted
URLS=( host1 host2 host3 host4 )
TIMESTAMPFILE=timestamp

# To know how to decompress the file
UNZIPCMD=/usr/local/bin/unzip
UNZIPOPTS="-o -qq"

# To copy files to other servers so that we are only
# pulling the files once, though we have multiple
# DNS servers in house

HOSTS=( host1 host2 host3 host4 )

# MOUNTCMD: The mount command
MOUNTCMD=/sbin/mount
UMOUNTCMD=/sbin/umount

# FSTYPE: The filesystem type of the mounted partition
FSTYPE=nfs

# MOUNTDIR: The directory that the dumps will be written to
MOUNTDIR=/mnt

# To control bind
NAMEDCMD="/usr/sbin/rndc reload"

#==============================================================

# Get start time so we can know how long this thing runs
START=$( date +%s )

# Make our working directory the location of the blackhole files
cd ${BLACKHOLEDIR}

# Copy the current timestamp file to ${TIMESTAMPFILE}.old so we can
# make a comparison between what we have and what's out there now.
if [ -f ${BLACKHOLEDIR}/${TIMESTAMPFILE} ]; then
	cp ${BLACKHOLEDIR}/${TIMESTAMPFILE} ${BLACKHOLEDIR}/${TIMESTAMPFILE}.old
fi

# Attempt to download the timestamp file and zone file from each mirror.
# Break out of the loop at the first successful download of a zone file,
# otherwise, try each one in turn

# Assume there are no updates available
NEW=0

for URL in "${URLS[@]}"; do
	echo "Attempting to download from ${URL}"
	echo " Checking timestamps..."
	${URLGRABBER} ${URLGRABBEROPTS} -A '${USERAGENT}' -o ${BLACKHOLEDIR}/${TIMESTAMPFILE}.zip ${URL}/${TIMESTAMPFILE}.zip

	if [ $? -ne 0 ]; then
	echo "  ... timestamp download from ${URL} failed! Code: $?"
	# Move on to next URL so we keep the timestamp/zonefile pair intact
	continue
	else
	if [ -f ${BLACKHOLEDIR}/${TIMESTAMPFILE} ]; then
		# Unzip the new timestamp file over the old old one
		${UNZIPCMD} ${UNZIPOPTS} ${BLACKHOLEDIR}/${TIMESTAMPFILE}.zip

		# Do a little cleanup
		rm -f ${BLACKHOLEDIR}/${TIMESTAMPFILE}.zip

		OLDTIMESTAMP=$( cat ${BLACKHOLEDIR}/${TIMESTAMPFILE}.old )
		NEWTIMESTAMP=$( cat ${BLACKHOLEDIR}/${TIMESTAMPFILE} )

		if [ ${OLDTIMESTAMP} -ge ${NEWTIMESTAMP} ]; then
			echo " ... no new updates."
			# No new updates on this server... but how well are the various mirrors
			# kept in sync?  Let's try the others. This is a tiny transfer, and it's
			# only once a day, so it's pretty cheap.
			continue
		fi
	else
		# Timestamp file does not exist. Create it.
		${UNZIPCMD} ${UNZIPOPTS} ${BLACKHOLEDIR}/${TIMESTAMPFILE}.zip
		rm ${BLACKHOLEDIR}/${TIMESTAMPFILE}.zip
	fi
	fi

	# Backup and copy file to final location for named to find
	# (via "include" directory in named.conf)
	echo "Backing up zone file"
	cp ${BLACKHOLEDIR}/${ZONEFILE} ${BLACKHOLEDIR}/${ZONEFILEBACKUP}

	echo "Retrieving new zone file from ${URL}..."
	${URLGRABBER} ${URLGRABBEROPTS} -o ${BLACKHOLEDIR}/${ZONEFILE}.zip ${URL}/${ZONEFILE}.zip

	if [ $? -ne 0 ]; then
		echo "  ... zonefile download from ${URL} failed!  Code: $?"
		# Oops.  Try the next server.  If this is the last, then ${NEW} is still
		# set to 0, and we'll be done. Better luck tomorrow...
		continue
	else
		# We have a new timestamp, and were able to download the zone file from
		# the same server we downloaded the timestamp from.  Set ${NEW} to 1 and
		# get out of the loop. No need to check further.

		echo "Unzipping new zone file..."
		if [ -f ${ZONEFILE}.zip ]; then
			${UNZIPCMD} ${UNZIPOPTS} ${BLACKHOLEDIR}/${ZONEFILE}.zip
			rm ${ZONEFILE}.zip
			# Rename the zone file temporarily to allow sed to work on it later, and
			# and in that process, rename it back to the name that named knows.
			mv ${ZONEFILE} ${TMPZONEFILE}
		else
			echo "No new zone file..."
			exit
		fi

		NEW=1
		break
	fi
done

# If ${NEW} hasn't been set, then we either error'd out of all servers, or there are no
# new files. Either way, we're done.
if [ ${NEW} == 0 ]; then
	exit 1
else
	# Disable name checking for only those domains with underscores,
	# so we don't have to turn off name checking globally.

	SEARCH='_'
	FIND='blockeddomain.hosts";};'
	REPLACE='blockeddomain.hosts"; check-names ignore;};'

	# Get a count of the zones from the last update
	OLDZONECOUNT=$( cat ${BLACKHOLEDIR}/${ZONEFILEBACKUP}|grep "^zone"|wc -l )

	echo "Disabling checking on domains with underscores"
	sed "/${SEARCH}/ s/${FIND}/${REPLACE}/g" ${BLACKHOLEDIR}/${TMPZONEFILE} > ${BLACKHOLEDIR}/${ZONEFILE}
	rm -f ${BLACKHOLEDIR}/${TMPZONEFILE}

	# Get a count of the zones from the current update
	NEWZONECOUNT=$( cat ${BLACKHOLEDIR}/${ZONEFILE}|grep "^zone"|wc -l )
	echo "${OLDZONECOUNT} Previous Zones"
	echo "${NEWZONECOUNT} Current Zones"

	echo "Reloading named"
	${NAMEDCMD}

	if [ $? -ne 0 ]; then
		echo "  ... failed! Restoring zone file"
		cp ${BLACKHOLEDIR}/${ZONEFILEBACKUP} ${BLACKHOLEDIR}/${ZONEFILE}

		echo "Reloading old zones in named"
		${NAMEDCMD}

		if [ $? -ne 0 ]; then
			echo "  ... failed again!! You'll want to see to that."
		fi
	fi

	echo "Copying files to other internal network servers..."

	for HOST in "${HOSTS[@]}"; do
	DUMPDEVICE=${HOST}:${BLACKHOLEDIR}
	MOUNTRESULTS=$( ${MOUNTCMD} | grep "${DUMPDEVICE} on ${MOUNTDIR}" )

	if [ "${MOUNTRESULTS}" == "" ]; then
		echo ""
		echo "Mounting ${DUMPDEVICE} on ${MOUNTDIR}"
		${MOUNTCMD} -t ${FSTYPE} ${DUMPDEVICE} ${MOUNTDIR}
		if [ $? = 1 ]; then
			echo " ... failed. Files will not be copied."
			continue
		else
			echo " ... succeeded"
		fi
	else
		echo "${HOSTNAME}:${DUMPDEVICE} already mounted on ${MOUNTDIR}"
	fi

	# Copy the files to ${MOUNTDIR} as a temporary file. On the remote server,
	# we'll manage bouncing named if necessary.
	echo ""
	echo "Copying ${BLACKHOLEDIR}/${ZONEFILE} to ${TMPZONEFILE}"
	cp ${BLACKHOLEDIR}/${ZONEFILE} ${MOUNTDIR}/${TMPZONEFILE}
	if [ $? = 1 ]; then
		echo "... Failed to copy ${ZONEFILE}! You might want to see to that."
	fi
	# Umount the backup filesystem
	echo ""
	echo "Unmounting ${MOUNTDIR}"
	${UMOUNTCMD} ${MOUNTDIR}
	if [ $? = 1 ]; then
		echo " ... failed. You might want to see to that."
	else
		echo " ... succeeded"
	fi
	done

	END=$( date +%s )
	RUNTIME=$(( ${END} - ${START} ))
	H=$(( ${RUNTIME}/3600 ))
	M=$(( ( ${RUNTIME}/60 ) % 60 ))
	S=$(( ${RUNTIME} % 60 ))

	echo "Malware zonefile download on ${HOSTNAME} complete in"
	echo "${H} hrs, ${M} mins and ${S} secs (${RUNTIME} secs)"

	exit
fi

On the “slave” servers, I’m using this…

#!/usr/local/bin/bash

# To put file where named can see it
BLACKHOLEDIR=/var/named/etc/namedb/blackhole
ZONEFILE=malwaredomains.zones
TMPZONEFILE=tmp.malwaredomains.zones

# To control bind
NAMEDCMD="/usr/sbin/rndc reload"

if [ -f ${BLACKHOLEDIR}/${TMPZONEFILE} ]; then
	echo "New zone file exists..."
	# Rename the zone file to back it up
	echo "Backing up current zone file."
	mv ${BLACKHOLEDIR}/${ZONEFILE} ${BLACKHOLEDIR}/${ZONEFILEBACKUP}
	# Rename the tmp file to the name the daemon can find
	echo "Replacing it with the new zone file and removing the temp file."
	mv ${BLACKHOLEDIR}/${TMPZONEFILE} ${BLACKHOLEDIR}/${ZONEFILE}

	# Reload named.
	${NAMEDCMD}

	if [ $? -ne 0 ]; then
		echo "    ... failed! Restoring zone file"
		cp ${BLACKHOLEDIR}/${ZONEFILEBACKUP} ${BLACKHOLEDIR}/${ZONEFILE}

		echo "Reloading old zones in named"
		${NAMEDCMD}

		if [ $? -ne 0 ]; then
				echo "    ... failed again!! You'll want to see to that."
		fi
	fi
else
	echo "No update.  Quitting..."
fi

DiscoverCard.com & Password Length Restrictions

Posted on by

With all the major breaches in the news lately (RSA, Gawker, PSN, Lastpass, MySQL, Texas Comptroller, etc. – hit the googles with you!), I finally got angry enough to ask a question of DiscoverCard that has been sitting on the back burner for too long. It’s about what I consider to be absurd password length restrictions on their site, and what that might say about how they’re storing those passwords on the back end.

Let’s clear one thing up: On principle, I believe I should be able to use whatever password I want. If I want to use “abc123″, or “puppy1″, or “;a3Wfzu0J|rqVHj%l]x6PZdQHqhpK39vx5?|fSb9NmFdq”, I should be able to. I should have the right to be as smart, stupid, paranoid or legitimately cautious as I want (here’s the thing) so long as my choice doesn’t affect others using the same system. I’m not the only one to think along those lines.

Principles aside, I don’t have a practical problem with complexity enforcement. I understand that repositories of critical and/or sensitive data and services have a need to shore things up a bit with more complex passwords. That doesn’t stop me from thinking there are design issues at hand if my weak web password can compromise someone else’s data. I also can’t help but think the whole mess is, at least in part, driven by a disgusting, ludicrously naive and juvenile expectation that “everything will always be ok, and I’m entitled to it. It’s my right! So there!” and all the litigation that goes along with that childish attitude.

That all said, it’s one thing to require password complexity, it’s another entirely to not allow it past X characters. It raises some questions…

So I asked DiscoverCard about it: (May 05, 02011 09:41 AM)

Can you please explain to me the exact method by which discovercard.com website logon passwords are stored? The length limit greatly concerns me. With the major breaches of late (PSN, Sony, Lastpass, MySQL, Gawker, etc.) it is critical that passwords be stored securely, with adequate encryption, or at the very least, salted hashing. Thank you.

Admittedly not the best in terms of wording and stated concerns. But there you have it. I can’t help but believe DiscoverCard, of all places, is using top-notch methods for storing passwords, but you just never know, do you?

DiscoverCard’s first reply: (May 05, 02011 10:46 AM)

Thank you for your recent message. I understand your concern about online security, and I will be happy to assist you today!

Our emphasis on privacy provisions and improved Internet security has made using our website safer than ever. We use the Secure Socket Layer (SSL) protocol for encrypting communications with our Cardmembers. SSL uses public-key cryptography to scramble the information sent between senders and receivers. In the unlikely event that third parties try to eavesdrop or intercept this message, SSL encryption prevents them from viewing its contents.

We also have Superior Fraud Protection, which means that when you use your Discover Card to shop anywhere on the Internet, you will not be liable for any unauthorized transactions. For more information about our security, please see the following page:

http://www.discovercard.com/customer-service/safety/site-security.html

I appreciate your business and the opportunity to be of service. Thank you for choosing to use Discover Card.
[signature and legalese removed]

Awesome, but no, that’s not what I asked. So, I completed a survey indicating as much and replied… (May 05, 2011 11:06 AM)

Thank you for the prompt reply. I appreciate the information on SSL, however, that doesn’t answer the question I asked. I asked about password storage (at-rest), not information on the wire (in-transit). My question is restated here for your convenience…

“Can you please explain to me the exact method by which discovercard.com website logon passwords are stored? The length limit greatly concerns me. With the major breaches of late (PSN, Sony, Lastpass, MySQL, Gawker, etc.), it is critical that passwords be stored securely, with adequate encryption, or at the very least, salted hashing. Thank you.”

To which they replied… (05/05/2011 12:06 PM)

Thank you for your recent inquiry. In an effort to provide you the best service possible, I have escalated this issue to the appropriate parties in our company for further assistance. We will respond as soon as we have any additional information concerning this matter. Thank you for your patience.

I appreciate your business and the opportunity to be of service. Thank you for choosing to use Discover Card.
[signature and legalese removed]

I don’t expect another reply anytime soon… but I’ll let you know if I do get one, either in the comments, or as a new post depending on the reply.

To Be Protecting Against The Malware

Posted on by

Last night, my wife called me into the office with an alarming “It says it’s infected with malware!” Needless to say (and yet I’m going to say it anyway) I hurried into the room to see what the hullabaloo was all about.

Sure enough, there was a window exclaiming the existence of not one or two, but quite a few malware infections.

It fooled her, and damn if that stupid pop-up didn’t nearly fool me too! Truth be told, it did, if only for a second. Those malware serving fake malware pop-up warnings are clever.

It got me to thinking.

Then Osama bin Laden was shot in the head, and malware peddlers started leveraging our insatiable appetite for news about it (the sick bastards).

That got me thinking more.

It reminded me of the malware peddlers that took advantage of the quake in Japan recently. Now those are some seriously sick bastards.

Those events all in quick succession and all that thinking led me to this.

A little ditty that downloads the bind formatted zone file from MalwareDomains.com, moves it to where Named can see it, and reloads Named zone files if the download is complete. I’d verify the file if they provided an md5 of the zones file. But they don’t. Not that I could find, anyway.

I don’t even begin to hope to eliminate the risk of malware infected sites, but I think this is a positive step towards cutting off malware source domains which might, in turn, help against sites on legitimate domains that happen to be infected. As of today, May 3rd, 2011, there are nearly 10,000 domains in the latest file. That has to be nearly all of them.

Right?

I’ll try it out for a while and see what happens.

BTW, this only works if you’re running your own DNS. If not, you’re at the mercy of your ISP or whatever DNS you choose to use. There are plenty of options out there, and they’re not all horrible.

First, the script, which pulls down the latest malware domains zones file from malwaredomains.com, fixes some problems with underscores in the subdomains, copies the fixed zones file to the named chroot, and reloads the named configs.

#!/usr/local/bin/bash

# To know where script is running
HOSTNAME=$( hostname )

# To put file where named can see it
NAMEDDIR=/var/named/etc/namedb

# To name file so we know what named seeing
ZONEFILE=malwaredomains.zones

# To have a file for sed to work on
TMPZONEFILE=tmp.malwaredomains.zones

# To get updated file from remote server
URLGRABBER=/usr/local/bin/curl

# To keep quiet while am getting file
URLGRABBEROPTS="-s -S"

# To know where file is hosted
#URL=http://www.malwaredomains.com/files/spywaredomains.zones
URL=http://mirror1.malwaredomains.com/files/malwaredomains.zones

# To control bind
NAMEDCMD="/usr/sbin/rndc reload"

#==============================================================

# Get start time so we can know how long
START=$( date +%s )

# Get directory we're running from
SCRIPTDIR=$( dirname $0 )

cd ${SCRIPTDIR}
if [ $? -ne 0 ]; then
    echo "ERROR: Unable to cd to ${SCRIPTDIR}! AbOrTinG!!"
    exit 1
fi

# If we were executed like "./whatever.sh" - set SCRIPTDIR to the pwd
if [ "${SCRIPTDIR}" == "." ]; then
    SCRIPTDIR=$( pwd )
fi

echo "Script is running from ${SCRIPTDIR}"

# Download the zones file in bind format to a temporary location.
# We don't want to overwrite what we already have until we're sure
# the download worked

echo "Downloading file from ${URL}"
${URLGRABBER} ${URLGRABBEROPTS} -o ${SCRIPTDIR}/${ZONEFILE} ${URL}

# Check for errors.  If the file downloaded, then move on, but if not
# we don't want to reload named without the previously updated
# malware domain list

if [ $? -ne 0 ]; then
    echo "    ... download failed! Error: $?"
    exit 1
else
    # Disable name checking for only those domains with underscores,
    # so we don't have to turn off name checking globally.
    SEARCH='_'
    FIND=';};'
    REPLACE='; check-names ignore;};'

    echo "Disabling checking on domains with underscores"
    sed "/${SEARCH}/ s/${FIND}/${REPLACE}/g" ${SCRIPTDIR}/${TMPZONEFILE} > ${SCRIPTDIR}/${ZONEFILE}

    # Get a count of the zones from the last update
    OLDZONECOUNT=$( cat ${NAMEDDIR}/${ZONEFILE}|grep "^zone"|wc -l )

    # Copy file to final location for named to find
    #(via "include" directory in named.conf)
    echo "Copying file from ${SCRIPTDIR} to ${NAMEDDIR}"
    cp ${SCRIPTDIR}/${ZONEFILE} ${NAMEDDIR}

    if [ $? -ne 0 ]; then
        echo "    ... failed! AbOrTinG!!"
        exit 1
    fi

    echo "Reloading zones in named"
    ${NAMEDCMD}

    if [$? -ne 0]; then
        echo "    ... failed! You'll want to see to that."
    fi

    # Get a count of the zones from the current update
    NEWZONECOUNT=$( cat ${NAMEDDIR}/${ZONEFILE}|grep "^zone"|wc -l )
    echo "${OLDZONECOUNT} Previous Zones"
    echo "${NEWZONECOUNT} Current Zones"
fi

END=$( date +%s )
RUNTIME=$(( ${END} - ${START} ))
H=$(( ${RUNTIME}/3600 ))
M=$(( ( ${RUNTIME}/60 ) % 60 ))
S=$(( ${RUNTIME} % 60 ))

echo "Malware zonefile download on ${HOSTNAME} complete in"
echo "${H} hrs, ${M} mins and ${S} secs (${RUNTIME} secs)"
exit 0

Then, the cron job to update the list on a daily basis:

35 0 * * * /root/bin/malwaredomains/malwaredomains.sh 2>&1 | mail -E -s "Malware Domain Named Update" me@here.com

Then, the blackhole host file that all those zones in the malwaredomains.com download refer to. Careful with this one, and you’ll want to replace the domains with something a little more relevant:

$TTL    86400           ;one day
@ IN SOA ns0.example.net. hostmaster.example.net. (
        2011050100  ; serial number YYYYMMDDNN
        28800       ; refresh 8 hours
        7200        ; retry 2 hours
        864000      ; expire 10 days
        86400       ; min ttl 1 day
)
        NS      ns0.example.net.
        NS      ns1.example.net.
        A       127.0.0.1
*   IN  A    127.0.0.1

Finally, the line in the named.conf file (in my case, in the internal view) to call on the recently downloaded zones file:

include /etc/namedb/malwaredomains.zone

That should do it!

This is what I receive in my inbox after every update (daily for me):

Script is running from /root/bin/malwaredomains
Downloading file from http://mirror1.malwaredomains.com/files/malwaredomains.zones
Disabling checking on domains with underscores
Copying file from /root/bin/malwaredomains to /var/named/etc/namedb
Reloading zones in named server
reload successful
   10116 Previous Zones
   10116 Current Zones
Malware zonefile download on [hostname] complete in
0 hrs, 0 mins and 2 secs (2 secs)

Mental Password Algorithms

Posted on by

Interesting…

Security rule #1 regarding passwords is to not write them down. But we all have too many passwords to possibly remember. Here is a way to safely write down passwords.

All that’s needed is a way to make the password you write down NOT be your real password, but be the input to a simple algorithm or mapping you can do in your head.

For example, your personal algorithm could be “remove all vowels and tack on the last 4 digits of my parent’s phone number”. When you sign up for a new account on some web site, you would create a password like “Rnbws8004″ but what you write down is “Rainbows”. Or your algorithm could be, “interleave the digits 4 2 0 3 between the consonants, eliminate the vowels, and put x’s on the front and back”, in which case you would set up the real password to be “xR4ain2b0ow3sx”, but (as before) you would write down Rainbows.

You can’t memorize 100 passwords, but you can remember one algorithm. If you never write down the algorithm, it is safe to write down the “seed” for the algorithm as if it is the password.

The key to doing this securely is to have an algorithm that’s complex / odd enough no one can guess it or discover it by random testing. E.g. if your algorithm is “put 123 on the end”, it’s not safe.

Time to change your hotmail/gmail/yahoo password

Posted on by

Microsoft has confirmed that thousands of Windows Live accounts have been compromised with their passwords posted online. Mainstream media such as the BBC are also carrying the story. Some information is posted here.

Some password tips for your safety goodness:

  • Change your passwords on a regular basis (every few months at the latest, every couple of months is better)
  • Whenever possible, use long complex passphrases rather than passwords. They’re easy to type, easy to remember, and difficult to crack.
  • If ever you notice anything suspicious with your accounts, change all your passwords immediately… especially those guarding sensitive information such as financial sites, online e’mail, online storage, etc.
  • Learn how to combat identity theft.
  • Use a firewall.
  • Use two firewalls, a software firewall, and a hardware port-forwarding firewall if possible.
  • Never click links in emails. Ever.
  • Try not to use the same password at multiple sites. If you must, then at least use passphrases. Not that you ever must.
  • Never share your password with anyone. Ever.
  • Always ensure that anytime you sign in to a website where sensitive information is stored, that you’re signing into the correct and legitimate website, and that the connection is secure. If you don’t see a closed padlock somewhere indicating that the connection is secure, or an “https” in the URL, then DO NOT LOG IN.

Be careful out there…

Never ascribe to malice that which can adequately be explained by incompetence

Posted on by

Last night, I checked the mail and had three Netflix movies waiting for me! Excellent! Except for one small thing… I don’t have a Netflix account.

Huh. Immediately suspicious, I decided to dig in and see what I could find out. My first step, having opened the movies to see what they were (nothing worth watching, and no… no pr0n), I sat down at the laptop and brought up netflix.com. I’m not a member… well… I’m not a knowing member, so I had no idea what my username would be, much less my password. Normally, you can have instructions sent to the e’mail address on file, but I was confident that in my case, my own e’mail address wouldn’t be on file. However, they have a method of logging in if you don’t remember, or have access to the e’mail address you signed up with. It asks for the first name, last name and card number used to sign up with. Using my real first and last name, I started going through my credit cards to see which one had fallen into the wrong hands. I didn’t have far to go… I got a hit on the first try.

I started digging into the account, and while the name and address were mine, the phone number and e’mail address were not. I called the number, on the off chance that I’d find the person responsible, but instead reached a nice couple who (if they can be trusted) don’t have a Netflix account either. We talked for a while, and they’ll be monitoring their credit closely. I then called the credit card company and had the card canceled and a new one reissued. Finally, I called Netflix themselves and appraised them of the situation. They canceled the account and forwarded it to their fraud department, telling me someone would contact me in the next 1 to 3 days. Some scissors to the card and I’m all done.

I can’t help but wonder what kind of completely incompetent idiot steals credit card information to purchase goods online, only to have the goods sent to the rightful owner of the card! The mind, it boggles. It really worked out for me, b/c the proof of fraud was hand delivered to my mailbox, so I’m not complaining… but it begs a few questions… How did they get the card information? When did they get it? Could it be a diversion? Were they drawing my attention away from the real fraud? Or were they truly, just that stupid? There were no charges to any of my cards that I can’t account for, so if they’d planned other acts of theft, they hadn’t gotten to them yet. Still, I’ll be watching very closely.

This morning, I returned the movies I’d been sent in their very handy self addressed no-postage-necessary envelopes. Though it wasn’t necessarily the ideal of first experiences, my experience with Netflix was actually very very good. I might even consider signing up for an account.

In a final bit of humor, I did some searches for quotes about incompetence for the title, and one of the sites had a pop up ad for… you guessed it… Netflix!

I Bid Thee, Texas, Adieu

Posted on by

Today is my last day here in TX. I fly out tonight, and will spend the evening with a friend and a bottle of wine to relax and decompress after a busy and stressful, though not at all unpleasant trip to the Lone Star State.

I can, without reservation, say that the people here are some of the friendliest I’ve ever had the pleasure of meeting. In spite of the fact that my job (information security) tends to put people on edge, especially when I’m performing audits of processes and personnel, they were, to the last, cooperative, eager to please, and open to any and all suggestions. They even agreed to install a jacuzzi behind the main branch for my next visit next year. Isn’t that something?

Tomorrow looks to be another relatively busy day. I finally get to pick up the Dew Drop at Midwest Cyclery! I cannot wait! It’s going to be so nice to have a completely working bicycle to ride again. The poor Torelli needs a couple of new parts to be 100%, and so I’ve opted to let her rest for the time being. The Fire Mountain is… well, it’s a frame on a nail.

After that, I pick up my brother and his wife at the airport, and then while she’s having dinner with family, we’ll head up to the pool hall and I’ll show him the what’s what on the table.

Until…

[Tag] Page 123, 6-8 and then Five

Posted on by

I knew, once I started reading that I’d be tagged.

So… it makes sense that the closest book is the one I’m currently reading. No, it’s not Lord of the Rings. That’s at home, though having one of my half a dozen or so copies here at work isn’t a bad idea…

From Beyond Fear by Bruce Schneier…

A French army officer asked him what he had learned from Napoleon. His reply was that he faced two problems during the war. One was the rifled musket behind earthworks, and the other was moving huge amounts of men and materiel [sic] by rail, and that Napoleon had nothing to say on either of them.

Bruce Schneier is, in my opinion, one of the most reasonable and grounded security minds today. Grounded by uncommon sense, he rarely fails to enlighten. The above passage Ulysses S. Grant’s reply to the French army officer during a visit to France following the US Civil War. It helps illustrate Schneier’s point that dynamic security systems, those which can adapt mid-attack, are more effective than static security systems, those that respond in a specific way every time. Security card readers are static. They deny you or allow you based on the presence of an access card. The armed guard is dynamic. He/she adapts to changing conditions. Seems obvious, doesn’t it? It was the difference between United Flight 93 and the rest of the plans that didn’t make it on 9/11.

Moving on… tag outs to you…

Matt. I think we could count the New York Times. Who knows? I’m new to this. Can a newspaper count? Sure. Why not.
Paul and Amy. The manual for Gears of War would definitely count, and Squanto says “hi!” to Roe.
Tim. Do you still play pool at all? You were really shaping up there…
Lydia. 9. I really like all my friends and wish them all the best, and 10. Why won’t someone tag me with one of those viral tag things? I’m here in my new office, sniffling, and no one tags. What gives?
M. Get the camera phone, already.

The rules:

  1. Pick up the nearest book.
  2. Open it to page 123.
  3. Find the fifth sentence.
  4. Post in your blog the following three sentences.
  5. Tag five or more people, and acknowledge the person who tagged you.

A Year Ago Today…

Posted on by

One year ago today, I was fired from a job as the Information Security Analyst at a local third party health plan administrator. This is my story…

I was working at a bank that had recently gone through a merger. In that merger, many of my friends and co-workers lost their jobs. It was a trying situation, but all of them eventually landed on their feet. One of them found work at a third party health plan administrator, and was in dire need of help. He set about recruiting me, and for many reasons, I took the bait.

When I arrived, I quickly realized how desperately in need of help he was. The situation was dire. The network was a mess. The hosts on the network were in horrific shape. End of life operating systems were still in production, some hidden away in closets. Win 95 (yes… 95) was hanging about. Likewise NT 4.0, of which some were original installs that had never been patched, even when those patches were readily available. Anti-virus installations were spotty at best, and of those installed, many were without up-to-date signatures. The firewalls had any-any-allow rules both for both ingress and egress traffic. The built in anti-malware modules were disabled, and logging was almost useful. While most users had actually been reduced to power user level, all users of the Citrix farm had local administrator accounts on the member servers. There were lot more issues, but that’s enough for the story, and to list them all would be tedious, to say the least…

On March 12th, all the NT 4.0 servers, and a few unpatched Win 2000 servers were infected with a backdoor trojan. My best guess and research pointed to W32/Rbot-AKU, though I was never able to confirm md5 hashes or find adequate documentation. The only real clues were the presence of %SYSTEM%\system32\qtask.exe, %SYSTEM%\system32\drivers\Oreans.sys, and %SYSTEM%\system32\irdvxc.exe).

How the infection penetrated the network is still unknown. I suspect a home user logged into the Citrix farm as a local administrator brought it in, but I can’t be sure. The behavior of the trojan indicates that it could have simply been a remote infection by random scanning. The firewalls would have certainly allowed it.

This infection caused 3 days of network outage during my second week when my primary technical contact/mentor was out of town. I was on my own trying to figure out firewalls I’d never worked on, a network about which I knew next to nothing and business processes I’ve not been trained on. There was, of course, no documentation. There was nothing in the way of traffic analysis software installed, and the firewalls had horrible logging and terrible connection management. I didn’t know what normal traffic was, or even if there was an issue with traffic. Several third party VPN connections were the source of the vast majority of management tension, so that’s where I focused my efforts for the first two days.

Finally, on the third day of complete outage, I realized that it was a virus. Not knowing the environment, I’d been troubleshooting the wrong thing. I finally found it, cleaned the infected servers I could clean, and powered off those I couldn’t, and the network came alive like magic. Though it wasn’t by design, the trojan on the infected servers was performing a DDoS attack on the firewalls. Their connection queue was constantly full, and they were dropping all traffic. They were simply unable to keep up with the huge volume of traffic being generated.

Years and years of never upgrading, never updating, never patching and pulling computers together from eBay and garage sales equaled infection by virus many and legion. Infection equaled downtime. Three days of downtime equaled hundreds of thousands of dollars lost and a major strike to the company reputation.

I bolstered the firewalls as best I can by tightening down the rule set, enabling the built in IDS and IPS, and prioritizing VPN traffic. I set up scans to monitor the %SYSTEM% folder on all the Win32 devices that I could, but there were 6 domains with incomplete and misconfigured trust, and I was unable to see all of them.

Over the next few weeks, the IT team and I worked diligently and hard to bring the anti-virus installations up to date and protect every machine on the network. We went in over the weekend and hit every machine by hand to make absolutely sure they were covered. Microsoft security patches were applied through this period as well, with some machines needing literally hundreds of patches. This had been done in large part prior to my arrival, but there was work yet to be done.

The trojan hits again on April 12th, but only for about an hour this time. One of the servers I was unable to physically get to for cleaning, having been shut down in March, was brought back online unbeknownst to me for a software install. Only an hour and a half, but it’s enough to enrage the CEO who informed us that anyone who touches a production server without approval will be fired on the spot. The good news is our efforts to protect the network appeared to have worked. This was the only server with an infection that was affecting the network.

Tuesday, April 17th, I noticed another NT 4.0 server was infected. Alarmed, I was relieved that no downtime, as of yet, had occurred. The changes I’d made to the firewalls and the work we’d done to protect the machines on the network were still working. This, however, was an original install NT server, and patches simply did not exist to protect it. As far as I, or anyone else on site knew, the trojan DoS symptoms could kick in at any time. I wrote my manager and the business owner of the server and informed them of the situation. I informed them that if I didn’t clean the server, I could not guarantee it wouldn’t bring the network down again. It had been infected for a few days so far with no affect, but given the lack of documentation, I couldn’t determine or predict how the trojan would behave. I concluded that we might be safe, but we might not be, and left the decision in their hands.

The business owner and IT Applications Manager gave me the go-ahead via e’mail to clean the server. I was in and out in 15 minutes. Following the cleaning, I scanned the network deeply with all the tools at my disposal to finally determine that the trojan was, once and for all, gone.

Wednesday, April 18th, my boss, the IT Infrastructure Manager was fired by the CEO on direction from the Board for lack of confidence. The downtime was too much for them to tolerate… never mind the lack of patching, lack of updating, lack of anti-virus and end of life operating systems that he’d inherited from his predecessors. He was given a no-win situation, did the best he could, and was fired for his efforts. It’s ironic that just three months prior, he was lauded as a hero in the company for the progress he’d made and given a very healthy bonus.

Thursday, April 19th comes and we were all still reeling from the loss of my boss, our friend. In an IT wide meeting, we were assured that it was a one time thing, and that no one is on the warpath.

Friday, April 20th, the CEO and HR arrive at my office door at 8:30am and informed me that my employment had been terminated. The IT Applications Manager apparently told him he had to talk me down from shutting off a production server. I’m too shocked to realize what he’s talking about and simply take what’s mine and leave. Only later do I begin to process what happened and come to realize what had been done to me. The IT App Manager sold me out, and misinformed the CEO regarding what happened with that last infected server. He neglected to mention the permission he gave me, and misrepresented our conversations to make it appear as if I was on a rampage and in a panic.

It is clear to me now that not cleaning that server could have easily resulted in further corporate wide network downtime, and that downtime would have gotten me fired. On the other hand, taking offline with permission for 15 minutes a single NT 4.0 server that is used by 3 or 4 people 3 or 4 times a day in order to guarantee no corporate wide network downtime did get me fired.

I was in a classic catch 22.

In short, I believe both my boss and I were terminated for political reasons. We tried to affect real and positive technical and security improvements in an organization that had, for the past 20+ years, grossly under funded IT, and given zero thought to information security. For the leaders of a company in the third party health plan administration industry to behave in this manner is disturbing. I believe the mindset was such that we simply did not fit, and excuses were found for the both of us to be fired.

Never have I regretted a job-related decision as much as my choice to leave a safe and comfortable job for that one. For that matter, there are very few decisions in any area of my life I’ve regretted more. Compound that by what I’ve learned recently… had I stayed, not only would I be making considerably more money, but I would have a decent chance of moving to Orlando, FL. Fah! *spit*

From what I’ve heard from friends who still work there, the situation isn’t much better. On the technology side, there have been improvements, and many of the safeguards I helped put in place remain and are maintained. On the political side, however, there is still plenty of uncertainty, upheaval and fear. All in all, though being fired had severe consequences in my personal life, a year later I can say without reservation that I am definitely better off.