Sister CISA CISSP: July, 2009 archives

Sister CISA CISSP:

July, 2009

Jul 31 2009   4:25PM GMT

Things NOT To Do When You’ve Been Hacked, Part I



Posted by: Arian Eigen Heald
Incident Response, Data Breaches, information security policy, information security

The problem with being a “geek” is that we truly love to tinker, to fix, to improve, to test….etc. So when you announce to a bunch of us that a website on the network has been broken into, there’s lots of leaping into action.

Which is exactly what you don’t want to do. At all.

While visiting a client to talk about network architecture, an engineer rushed into our room to announce that one of their websites had been hacked. We all hopped up and went out with him. (My lecture was boring, anyway.) I wanted to see what they were going to do, and if they were going to follow their own Intrusion Detection Policy. Plus, I was, like them, vastly interested.

Turns out it was a fairly generic attack, with the break-in artist simply using the website for cross-site scripting and redirection.

By the time we got there, two engineers had already been working on the web server, analyzing the code in the html, and checking other settings on the server. They took the web server offline, removed the offending code, looked at the event logs and brought it back up. All good, they said.

“Not really,” I said. “You do know that you can never trust this box again?”

“Not to be a party-pooper, but there’s no way of really knowing if a rootkit has been installed, is there? He could come back tomorrow.”

The four geeks looked pained. “What should we do?”

“Well, we can start with reformating the disk and reinstalling the OS.” I knew the minute I said that I was not going to be the most popular girl in the room. That sort of thing is awfully tedious and boring; no fun for geeks.

“But there’s ten other websites on this server!” Oops, this was going to be a LOT of work.

We segued briefly into the advantages of virtual machine backups, and then returned to the discussion of what to do.

I finally asked that deadly question: “What do your Incident Response Procedures say?”

Jul 30 2009   1:44PM GMT

Don’t Go Banking with your iPhone Just Yet



Posted by: Arian Eigen Heald
mobile phone security, information, data security

Articles are being released today about a flaw discovered by security researchers Charlie Miller and Collin Mulliner. They informed Apple a month ago about this flaw, but no fix had been issued. So they decided to go public at the Black Hat conference with a demo of just how easy it is to take over an iPhone. The demo will be done today and I’m sure details of how to do it will be flying. From here, it sounds like a buffer overflow.

Experts are warning that a text message containing a square character means someone is in the process of taking over the phone. They recommend that you shut down the phone immediately and “wait awhile.”

I suppose they think waiting awhile will motivate the hacker to move on to other iPhones. I’d suggest, however, that you turn OFF text messaging until they get this fixed. Shocking to some, I know, but it would be much more shocking to have all your information compromised.

Have a new iPhone with 3G? You can visit a site on YouTube that demonstrates the ease of bypassing both the passcode and the encrypted backup. He has a number of other videos that are equally painful.

Once again, security has taken a backseat to speedy software development. Now Apple is getting a lot (more) bad press.


Jul 24 2009   3:26PM GMT

Adventures in Auditing #3, or “Why Do you Need to See That?”



Posted by: Arian Eigen Heald
Admins and Auditors, Compliance, IT Compliance - Policies, IT Security

It always pains me when I get this question from a client’s IT staff. It usually means that auditing has never penetrated to that level, and people are used to doing pretty much what they please around the network. It usually goes with:

“This is a development shop. Those are not production servers or databases - so why are you asking to see users, patching, inventory, etc????”

These are the kinds of questions that will keep me employed as a successful penetration tester AND a digital forensics analyst. When I’m dead someone will prop me up to keep going.

A development environment is EXACTLY where a penetration tester goes first for exactly this reason. When you don’t know what’s running on your network, you don’t know who is on your network.

If it’s on your network, the company is responsible. Legally responsible. And that question will not hold up in court.

It’s a great version of the “sniff test:” Imagine saying it on the witness stand to a judge.


Jul 22 2009   3:09PM GMT

Adventures in Auditing #2



Posted by: Arian Eigen Heald
Physical Security, Compliance, data security

While doing a PCI exam not long ago, I visited a company that was very proud of it’s security measures, and rightly so. They had done a lot of work to secure their environment.

Sometimes it’s the smallest things that we are so used to seeing that we stop “seeing” them. They become part of the background noise of everyday functions and escape our notice. Social engineers are masters of acquiring those functions and using them for the wrong reasons. For example, the building cleaners. Do they have keys to everything in order to clean your offices? What if they decide to clean out your data?

Corporate espionage agents have been known to offer cleaners $50.00 per bag of trash. Another point of easy cash is backup tapes.

When we walked into the tape storage room, I inquired, “Do you have an inventory of the tapes in this room? How often do you check that the inventory is all accounted for?” Nonplussed, the CIO replied that the door was secured and only he and one other IT person had the key, which was signed out in the Data Center whenever it was used. So they weren’t “bothering” to inventory the tapes in the room.

Looking down, I noticed that the wastebasket was empty, with a fresh plastic bag neatly wrapped around it. I said, “Do your cleaners have a key to this room?” “Why, yes,” the CIO replied blankly. Then comprehension dawned on his face.

Next day, a new policy was posted by the tape storage door: all trash receptacles were to be placed outside the door. The CIO informed me that the lock had been changed to the door, and inventories would be done monthly.

There are some companies that go the extra mile of encrypting tapes or requiring that their cleaning companies be bonded AND employees have an annual background check.

It’s expensive, but so is losing the company’s reputation to a building cleaner……


Jul 15 2009   8:47PM GMT

Hard Disks Never Die - They go to Digital Forensics



Posted by: Arian Eigen Heald
"How Do You Know?", Forensics, Digital Forensics, Hardware & InfoSec, information security

I’m attending an absolutely fascinating course on Digital Forensics provided by SANS. One of the things we will be doing is collecting data from hard drives for various practice exercises.

Imagine my amusement when the handout and appendixes recommend where to get used hard drives to practice on: eBay or Craigslist. Didn’t Simson Garfinkel do this a few years ago? And come up with a whole bunch of juicy information?

How do you dispose of hard drives? There are overwriting programs and businesses that will pick them up and dispose of them securely, providing a certificate (and thus transferring your risk). But how do you know they are performing as agreed?

I’m looking forward to my eBay hard drives and what they will disclose. Hope they’re not yours!


Jul 13 2009   5:27PM GMT

Adventures in Auditing #1



Posted by: Arian Eigen Heald
Compliance, Wireless, Admins and Auditors, Adventures in Auditing

I’m still amazed that folks are going about their business believing that bad things won’t happen. Is it human nature? I thought I’d share with you some of my latest adventures in traveling about and auditing various companies. Just when I think it’s strange, it get stranger.

I was doing an audit and I routinely check for wireless connections. The manager had assured me that their policy was: no wireless. OK, but I check anyway. It’s the nature of my work: controls should be in place and they should be working. Essentially a very simple rule.

Behold, a Linksys wireless router popped up with an obvious default configuration. I followed my trusty wireless signal scanner downstairs through several departments until I came upon it sitting out in the open near a group of desks.

I headed back upstairs and asked the manager about it. His face flushed, and he said, “Where is it?” He followed me downstairs, I pointed out the router, and he reached over and yanked the network cable right out of the wall, looked around, and said, “Who plugged this in?” When no one responded, he took the casing off and stomped on it. A silence ensued.

He was peeved. Glad it wasn’t my router. Not because of the router, mind you, but the person who owned it was obviously going to have a discussion with this manager before long.

Back upstairs, his dignity somewhat restored, the manager asked about my wireless signal scanner, and I promptly demonstrated its virtues (electronics can be soothing). Canary makes a great one that scans for b/g and n networks, giving me the type of encryption AND the SSID so that I don’t have to even open my laptop. It has a visual meter so I can home in on the source of the signal and actually find the access point without my laptop (which is rather obvious).

I was ready to give it to him in hopes of escaping any further compliance corrections, but he seemed calmer at that point and thought getting one of his own was a smashingly good idea. (Sorry, I couldn’t resist).