Posted: January 26, 2011 in Uncategorized
Image via Wikipedia
The FBI’s IC3 issued a warning this week about ACH fraud targeting businesses across the US. The targets of these attacks are companies that have recently posted on job search sites. So what’s the connection? If you’ve posted a job opening, then it’s only logical that someone at the targeted business is expecting a resume or curriculum vitae (CV). They are, after all, trying to fill a vacant position. This means an email with an attached resume isn’t really “unsolicited email”, making it more likely to be opened by the recipient.
At the core of this “resume” attack is the Zeus aka “Zbot”… a data-theft Trojan that’s responsible for stealing large sums of money from companies across the nation. The IC3 warning highlights one recent case: a US business lost $150,000 when cyber criminals were able to nab the online banking credentials from the person that handles financial transactions. Money was fraudulently sent in three transactions to accounts in the Ukraine and the US. The FBI advises clients to ensure all email is scanned by an anti-virus solution. This is certainly a good start, but technology alone won’t protect your personal or business bank account.
- Anticipate unauthorized access. Just assume your system(s) or PC will be broken-in to. When this happens your financial and personal data will be targeted, so make it harder for data thieves to take it. Based on my experience as an ethical penetration tester, I know it’s all too easy for a hacker to “leapfrog” from one system to another once they’re on the network. This is especially true if PCs are un-patched, easily guessed or blank passwords are used, and sensitive data like bank account numbers and passwords, etc., are saved to the “desktop” (or elsewhere) without encryption. Take inventory of what sensitive information you’ve saved and whether you really need it. If you do, store it on a secure/encrypted thumb drive.
- Buy USB thumb-drive that supports encryption. I personally use a 2GB S200 from IronKey. My IronKey securely stores my credentials (login & password) for every important website I use. I do not keep login names, accounts, and password on my laptop in clear text. When I need to login to these sites, I plug-in my IronKey and use the “secure” Firefox version that comes with it. This adds an additional layer of web browser security. IronKey makes both a personal and enterprise version, so this is a solution that works well for consumers and businesses alike.
- Use a separate system for banking and only for banking. Even with encryption, a patched OS, anti-virus, firewalls, and a secure browser, I still believe that using the same PC to surf the web and manage your money is dangerous. So buy a netbook – it’ll cost you less than $300. Only turn it on when you have bills to pay, money to transfer, etc. Turn it off when you’re done. Keep it in a safe place, away from your spouse, kids, roommate, or whoever might take it for a spin on the information superhighway. Don’t check your email, Facebook page, eBay account, do Internet research, or IM your friends from this system. Have I made this clear? This is no ordinary, casual, web-surfing laptop — this is your banking system — your “banktop” — keep it safe. Use it for banking only.
- Enable alerts on key banking activities. And finally, it wouldn’t hurt to know when an unexpected banking transaction happens. My business bank lets me enable about 16 different alerts that can be sent over SMS or email. I receive an alert for every successful or failed login, deposits, and transactions over a certain dollar amount. I know within seconds if something has happened. So far, so good.
All this protect your hard-earned cash? You bet. Your other choice is to use the drive-up teller or in-person banking. There’s certainly nothing wrong with that. But if you’re going to use Internet banking, please take it seriously — mighty Zeus is only a few clicks away.
Posted: January 15, 2011 in Uncategorized
This week’s news included a story about hackers that breached a server containing the private health information (PHI) of 230,000 cancer patients. While it’s common for insecure systems to be hacked, it’s been a while since I’ve heard of hackers breaking into a server with a clear intention of doing something other than stealing information. And that’s just what these guys did. It seems the hackers were in need of horsepower and bandwidth. What for? To install and play Call of Duty: Black Ops.
“Theft of service” (or servers in this case) isn’t unheard of. It’s just one of the many ways a digital miscreant can wreak havoc on poorly protected systems. In the case of Black Ops gone Hack Ops, it’s not the hack that caught my attention, but what tipped-off the organization that was hacked. It appears that a “loss of bandwidth” caused a network admin to investigate.
At least that was noticed.
But there’s a list of other events that should have been automatically detected, well before the mischievous gamers started annihilating Spetznaz operatives…
- The server was vulnerable. Whether the server was un-patched or had too many ports exposed to the Internet, this should have been flagged as a risk in a nightly vulnerability scan. You can setup this type of automated scanning for free using Nessus or for as little as $20/day using Qualys.
- The actual break-in. Possible methods include a remote exploit or a management interface like RDP with an easily guessed password. If it was a buffer overflow, a “warning flare” should have popped at the host-IPS, network –IPS, malware detection, or operating system layers. If a password was guessed, a series of failed login attempts should have been logged then reviewed — especially if the admin account was targeted. Either way, the logs should have contained enough data to alert an admin of suspicious activity before Call of Duty was installed.
- The game installation. We install software on our personal computers all the time. But the installation of software on business server is not a routine event. In fact, any unscheduled installation of software on a server should be investigated immediately. If it can be logged, an alert can be generated. On the right, you’ll see that my installation of Dragon Naturally Speaking was successful. Imagine an SMS alert/email at 1AM saying “Call of Duty… installation successful.” I think I just felt my chest tighten up.
- Anomalous network connections and traffic. The sudden and unusual surge in connections from the Internet to the compromised medical server can be detected and alerted with Netflow analysis. Even if it’s common for this server to sustain a high number of connections, the client/server sessions for Call of Duty should have stood-out as abnormal. Regardless, network interface monitoring with SNMP and latency checks with ICMP would also tip-off a network admin to the gamers’ activities.
Posted: December 2, 2010 in Uncategorized
I once gained access to the ERP system of a $750 million dollar company by impersonating a panicked sales person. I called the helpdesk and told them who I was. I frantically shared that I could not access my email and download my PowerPoint slides for a very important sales presentation. I obviously couldn’t remember my password, so I asked for reset, which they quickly did for me. Unfortunately, the very helpful helpdesk did not ask me to prove my identity — they just told me what my new password was. From there, I logged-in to Outlook Web Access. I then opened a ticket requesting VPN access. Since this request came from within the corporate mail system, this request was also approved. With a network user ID and password, plus VPN access, I was then able to connect to the network and penetrate their HP-UX system. How I gained administrative privileges (root) on that box is another story.
There were several points along the way that should’ve prompted the help desk to verify who I was. In the absence of a clear process or protocol for handling these requests, personnel will often go with what is convenient or presents the least amount of conflict. This is especially true if the helpdesk is understaffed or the social engineer uses anger or frustration as an intimidation tactic.
Password resets should never be handled over the phone. Here’s a simple process I’ve recommended and used to reduce the risk of password reset social engineering:
- The helpdesk resets the password, but does not share the password with the caller
- The helpdesk calls the internal desk phone of the caller and leaves the password in their voicemail
- The caller retrieves the password from their voicemail. The user is forced to change their password as soon as they login.
- The helpdesk emails the caller’s manager. The manager is responsible for calling their employee before close of business to verbally confirm their password reset.
- The caller’s manager responds to the helpdesk’s email confirming their password reset was legitimate
Password self-service systems make processes like this obsolete. You can see self-service in action if you forget a password for the web applications and social media platforms you use. But on the corporate side, only a small number of my largest customers are beginning to implement password self-service. Until then, the helpdesk must make sure all callers are properly authenticated.
Posted: November 18, 2010 in Uncategorized
It's hard to believe summer is gone, fall is slipping away, and winter is just around the corner. Would it be too hard to believe that I've been too busy to blog? (err…my last post was in July!). To get things rolling again, let me share what I've been up to the past 3 months:
I worked on two security visibility and response projects. Both organizations have several layers of security safeguards, but lack the ability to efficiently and effectively visualize and report on the big picture. If you smell SIM technology, you're on the right track. It's encouraging to see security admins resolve an incident without bouncing through 4 or 5 systems to collect basic information. If you're current SIM solution leaves you with more questions than answers, then please stay tuned for a post on a great solution.
I also led several penetration tests, targeting network, application, web, and client-side layers. While most edge (Internet) systems are free from OS level weaknesses, the OWASP Top-10 bugs are still prevalent. XSS and SQL injection continue to plague not just Internet systems but also internal systems. This should not be a surprise — the edge still gets priority in patching. With the prevalence of client-side attacks, however, I am seeing a definite up-tick for internal patching. Which leads to this point — when Internet hosts are patched and firewall rules are stringent, target the end-user. It's working for cyber criminals and it worked 100% of the time during our summer/fall penetration tests.
There's been a spattering of small 2 or 3 day projects spread in between to fill-in the gaps. Web app assessments, teaching a pen-testing class, and building an incident response plan for a billion dollar organization.
I'm looking forward to winter. I might actually get a chance to wax the snowboard and carve it up. Stay tuned.