Followup: Craigslist whole house looting

The Craigslist based looting I mentioned a few posts back resulted in a subpoena of Craigslist records, and the arrest of the couple who had posted the ad - apparently to cover the theft of saddles and other items. The Smoking Gun has mugshots and more details.

Investigators were lucky this time - the couple didn't use an anonymizing proxy or otherwise cover their tracks well enough to avoid being discovered. If this becomes a more common event, we'll likely see better concealment in the future.

FERPA updates: Recommendations for Safeguarding Education Records

On March 24th, the Department of Education released 34 CFR Part 99, "Family Educational Rights and Privacy; Proposed Rule". This is a proposed update to FERPA (the Family Educational Rights and Privacy Act of 1974).

The document lists a number of recent incidents, ranging from grade exposures to SSN and personally identifiable information disclosures, and suggests that a number of steps are available to organizations after exposure. Most organizations should have similar steps in their incident response plan - if you don't, this provides at least a basic overview of the steps you'll want to take.

Remember, FERPA does not have a specific requirement regarding notification of students in the event of unauthorized release or theft of their education records - but organizations are required to maintain a record of each disclosure. This is very different many existing SSN and other PII disclosure laws.

As noted in the document, the Office of the Inspector General does provide a student focused identity theft resource site: http://ed.gov/about/offices/list/oig/misused/idtheft.html as well which includes a list of steps to take for victims: http://ed.gov/about/offices/list/oig/misused/victim.html. The FTC's identity theft guide is still an excellent resource as well: http://www.ftc.gov/bcp/edu/microsites/idtheft/

Taking a toll: Separation of duties...or not.

Security analysts often find themselves turning a blind eye to another organization's security issues in order to have their own needs met. At other times, we just appreciate the irony when we're told about the security process, and how the organization's representative just violated it to get their job done. Here's a recent example:

A co-worker recently signed up for the local toll road's quick pass through system. This is more arduous than it needs to be, and after a number of rounds with them due to process issues such as missing activation IDs, incorrect instructions, documentation that didn't match the process documentation, and missing emails, he found that he needed an activation PIN that should have been sent via email, but wasn't, and called for a third time.

The organization in question is carefully set up so that individuals don't see both your account number and your PIN at the same time. If a support team member prints your PIN and address to be mailed, another department will mail it without knowing your account number.

This sounds pretty reasonable, and should be workable. It even ensures a reasonable amount of safety to the customer - or should. Unless, of course, the PIN is sent by email, and the provider has DNS issues and can't resolve your well known TLD. That makes CSRs get creative.

The service representative did the right customer service thing, and the wrong separation of duty thing: he walked to the other department, got the paper from the printer, and read the PIN over the phone. No controls prevented it, making the separation only meaningful to those who wish to follow the rules.

Not exactly effective compartmentalization - but it worked in the customer's favor this time.

This is a useful case to remind us that our carefully built process requires checks and monitoring. Simply relying on processes without validating them and verifying that they aren't being violated can be worse than knowing that no process exists - you're left with a false sense of security.

The co-worker? He found out that the pass system charges a maintenance fee every month in addition to the tolls and the money kept by the toll system to "charge" his account, and is considering switching to the alternate system available in the area.

Creative Commons image credit billjacobus1

Identity theft: Income tax returns and stolen identities

The University of California's Irvine campus recently made the following announcement:

UC Irvine has received more than 50 reports that Social Security numbers have been stolen and used to file fraudulent tax returns to gain refunds. Victims are identified as current and former UCI graduate students and medical students. In most cases, the students have discovered the issue when they electronically submit their federal income tax returns and the IRS informs them that someone has already filed using their name and Social Security number.

This should be particularly disturbing to people, as it isn't simple credit card fraud - actual tax returns were filed using these Social Security numbers. Not only could this cause real hassles in dealing with the IRS if it becomes a widespread issue, but it means that attackers have discovered how little validation there is in the IRS tax return system and exploited it to their advantage.

This is the first time I've seen a report of relatively large scale tax return fraud with the intent to make money from returns on more than an individual basis, but, if it is successful and doesn't result in a successful investigation, it likely won't be the last.

It will be interesting to see if similar issues occur as other campuses dealing with SSN exposures. The IRS is handling it reasonably well - they're allowing second, valid returns to be filed, and are asking the affected individuals to file police reports. It is worth noting that they are requesting a paper tax return be sent to a specific office: online tax return submission may make this exploit much easier.

UCI now gets to try to find out if they were the source of a data leak - from the FAQ on their announcement page:

Q. Does this appear to be an isolated case?
A. There are more than 50 cases at UCI, but this currently appears to be focused on graduate and medical students.

With that sort of pattern, we may well see a breach announcement in the near future as required by the California Breach Disclosure Act - UCI notes that they are currently investigating.

Flickr Creative Common licensed image credit to Matt Honan.

Listing: the Craigslist attack vector

Most of us don't worry about people looting our homes while we're at work - but a new form of attack can create more than a nuisance. A recent Craigslist hoax resulted in large numbers of people taking possessions from Robert Salisbury's Jacksonville, Oregon home. KGW.com's article on the event is worth a read.

This is somewhat similar to the "SWATters" who fake 911 calls using callerID spoofing, social engineering, and other tactics. In each case, the attack is reasonably easy to conduct anonymously, can cause great damage, and uses third parties to conduct the actual attack. In many ways, this is a physical manifestation of what security professionals are used to seeing from botnets and zombies conducting an attack.

Will we see a new term for Craiglist lootings and other attacks - Listing, perhaps?

Other events, such as the massive out of control party in England after it was announced online and by a radio DJ point to the power of broadcast media. Normal social controls are often ignored when people feel that they were invited to take advantage of a situation - and damages can be hard to calculate.

Have you updated your home inventory recently?

Creative Commons licensed Flickr image credit to user blmurch

Bruce Schneier: Inside the Twisted Mind of a Security Professional

Bruce Schneier's commentary on Wired about how security professionals think is a good read - and a great opportunity. Those of us in the industry often hear statements such as "Wow, I'm glad you're on our side" or "That's pretty evil!" when we make suggestions of how to break a system. Bruce says:

"This kind of thinking is not natural for most people. It's not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail. It involves thinking like an attacker, an adversary or a criminal. You don't have to exploit the vulnerabilities you find, but if you don't see the world that way, you'll never notice most security problems."

Bruce's thoughts on this closely match my own - we are, in some ways, engineers of failure. Where others look to make systems work, we seek to stress and test them to the breaking point. The mindset is often difficult to escape - the switch is always on.

When I'm at my local credit union branch, I'm watching to see how they handle my transaction, and how security is set up inside. I look for flaws everywhere - from simple issues like not locking doors to complex issues with data and programming. I know that I check security automatically, and that I analyze almost any system I'm faced with to find flaws or opportunities for exploit.

Since we're security professionals, and we'd like to make other people more aware, we're faced with the question: can we teach the security mindset? Bruce's contention is that it isn't trivial:

"I've often speculated about how much of this is innate, and how much is teachable. In general, I think it's a particular way of looking at the world, and that it's far easier to teach someone domain expertise -- cryptography or software security or safecracking or document forgery -- than it is to teach someone a security mindset."

So, if it isn't trivial, how do we do it? Can we teach the rudiments of the security mindset in a way that makes it available and open to the layman? I believe we can. Will they be effective security analysts overnight? Of course not - there's a degree of technical knowledge and understanding that we can't instill easily. The analytical mindset is, however, something we can plant the seeds for. Just a little crack in the normal mindset that accepts systems, and that instead looks for issues is all we need!

Here are a few ideas that you can use to prompt people in your organization to adopt the security mindset:

1. Challenge them to think like a bank robber when they next do their banking. Ask if they pay attention to security cameras, how they identify themselves, and if the cashier has money out and visible.
2. Get them interested in how a system they are involved with can break. Web developers often delight in breaking an application if you show them how, and system administrators are tickled to learn how to break into a machine - if it isn't theirs! Find something that the person works with every day, and show them how the system can be broken.
3. Make opportunities to ask questions and to test systems available, and encourage your staff to do so. I've had the opportunity to lecture college classes on physical security and you can help foster the moment when the light comes on through simple means - tell stories, point out issues and fixes, and then ask simple questions. You'll be surprised at how the pace picks up once one person answers.
   

How do you plant the seeds of the security mindset?

Core Impact and Ed Skoudis: Penetration Testing Ninjitsu

Core Security is sponsoring Ed Skoudis's presentations on ethical hacking and penetration testing under the title "Penetration Testing Ninjitsu". Ed and Core will be doing a total of three webcasts - the first was focused on Windows command-line tricks, future webcasts are slated to include social engineering and other techniques. The next webcast will be on May 20th, 2008.

Ed is an excellent speaker, particularly for those who are unfamiliar with the techniques but who have a reasonable level of general technical knowledge. He's well worth listening to if you get a chance.

In the first presentation in the series Ed emphasized one of my favorite characteristics of an information security analyst right up front - the ability to think out of the box, and to use their innate creativity.

In his presentation, Ed talked about some of the basics of penetration testing which are worth repeating:

• You have to know the limitations - things like scope, time, access, methods, and the final truth: you won't find all of the vulnerabilities.
• Penetration testing can help find things that other approaches missed, and that unknown problems can be found. In addition, it often goes deeper than most audits.
• Penetration testing isn't the only approach you should use - reviews of configurations and architecture, automated tools, audits, and interviews with personnel. The key: a comprehensive security program.

You'll find more about how to deal with the risks that you find in a penetration test in my writeup on risk handling methods and denial.

Ed also covered a number of Windows command-line tips - many of these are covered in the GCIH training for Security 504 that SANS offers, as well as in his Windows Command-line Kung-Fu. If you've taken either class, today's presentation was largely review - ping, dns lookups, arp cache checking, SMB enumeration and shares, a huge amount of detail about for loops, and a few other tricks.

The amusing observation that I and others who watched the webcast had was that during a security presentation where users were unable to see each other's names to provide anonimity, questions showed the name of the submitter. If you want to remain a bit more anonymous, you can't ask questions...

Creative Commons licensed image credit Flickr user R'eyes.