Archive for the ‘Uncategorized’ Category

The Seal of the United States Federal Bureau o...

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.

Don’t check email, Facebook, eBay, or IM from this system.  This is no ordinary, casual, web-surfing laptop — this is your banking system — your “loot-top.”
Enhanced by Zemanta

Call of Duty: Hack-ops

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.
Enhanced by Zemanta

Image representing LinkedIn as depicted in Cru...

A Marketing manager on Linkedin posted a question regarding the risk of letting all associates access Facebook.  Specifically, she was interested in the viral implications.  Here’s my response:

“Social Networks are ideal for malware distribution. Applications like Twitter and Facebook amplify the speed with which new malware can spread, as well as the reach of the malware campaign itself. Malware authors know they can piggy-back on the chatty and social behavior of those using the social networking applications. But leveraging ubiquitous applications isn’t a new tactic — email offered the same “courier” service in the earlier days of malware. And it still does today.

Image representing Twitter as depicted in Crun...

You’re not suddenly moving from secure to insecure by allowing Facebook access to all associates. You are, however, increasing the number of opportunities users have to carelessly click. If preventing viral infections, or worse, a full-on data breach, is a key security goal then you want to decrease the number of opportunities a user has to click on something dangerous. How frustrating and ironic would it be to suffer a breach from an application that provides entertainment to associates, but little to no value to the business as whole? With that said, something for management to consider is what are the positive outcomes and results that come from allowing Facebook access to associates?

While I see the value in allowing social networking for specific business units like Sales and Marketing, I can’t see how the social benefits afforded to every associate outweighs the potential loss from a data breach.

Image representing Facebook as depicted in Cru...Image via CrunchBase

You’ll probably be asked to allow FB anyway. Other LinkedIn professional have already posted regarding URL and content filtering, patching, etc. I also agree with these recommendations, as they can certainly filter out the lion’s share of potentially harmful content and reduce the risk of a possible breach. Both Websense and Bluecoat have community based reputation filters that add an extra layer of intelligence to the inspection of URLs. You should also consider blocking “uncategorized” web sites. As an ethical penetration tester, I’ve had great success registering new domains then immediately using them in “mock” phishing campaigns. This tactic is used over and over again by real cyber criminals. In some cases it can take a couple of days for these new domains to be discovered. Until they are found, they’ll have no reputation, and will most likely be allowed by default (depends on how you set it up.) Only blocking sites that are uncategorized (or not yet known to the content filtering service) can prevent users from accessing these new domains. “

Enjoy! — Simon

Related articles
Enhanced by Zemanta

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 phone off hook 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.

–Simon

I delivered a bittersweet message to a CEO last week.  We had completed an external penetration test that included social engineering and phishing.  While the client had made many improvements since our last penetration test, a couple helpful end-users helped us bypass their security enhancements.  The message I shared went something like this —

“The URL filtering solution you deployed last year prevented several of our phishing attacks.  In fact, it successfully prevented your end-users from accessing the malicious websites we created to trick your end-users.  This is a great improvement from a technology perspective.  Unfortunately, two of your end-users replied to the phishing email.  One simply shared their username and password when they couldn’t get to the blocked website. This gave us access to their corporate email account.  The other user downloaded and installed the custom “program” we emailed them to help them trouble-shoot the problem.”

It would be easy at this point to highlight how careless end-users can be.  But this post isn’t about how easy it is to bamboozle employees.  No, this post is about a CEO’s realization that more technology won’t solve the “human element” problem (and that’s refreshing.)  He responded to my summary above by asking what protocols they should create and follow to make certain his corporate staff aren’t tricked by intruders pretending to be the help desk or IT support.  Having worked for the Air Force as a teenager, served in the Navy as an adult, and worked within the walls of the NSA, I know a thing or two about security and communications protocols.  I suggested the following:

  • Instruct end-users that no one within the company will ever call or email them regarding patches or software installations.  This includes the Help Desk and IT. Instead, this protocol will be used:
  • The IT Manager will contact the Chief Operations Officer (COO, equivalent, or designated rep) with the details of the emergency update or software install.  The COO will authenticate the email with a phone call to the IT Manager or face-to-face confirmation. Nophishing
  • Once authenticated, this email will be forwarded by the COO or designated rep to the Department Heads.  The Department Heads will verify that the email thread includes request and approval between the IT manager and the COO (or equivalent).  If this is missing, the email is a fraud and must be reported immediately.
  • The Department Heads will forward authentic emails to their direct reports or staff.  Like the Department Heads above, the end-users will verify that the thread includes IT Manager to COO to Department Head forwards.  If this is missing, end-users must report the email immediately.
  • Only after this protocol is followed can an end-user follow the instructions outlined in the email.

Other organizations I’ve worked with also include a keyword that is changed each month and shared between the executive staff and the Department Heads.  Security related emails that do not include this keyword are deemed fraudulent and reported to the security manager.

Now, before you say, “This protocol is too hard — there’s no way we could do this!”, keep this in mind — under normal circumstances you’ll be using software distribution and patch management tools.  You won’t be emailing or phoning end-users and asking them to install a file or follow a link.  Why? Because contacting users directly via phone or email is what the bad guys do.  Since common sense isn’t a commodity, your users need to know how to tell the difference between the real IT team and a fake one. You can’t do that with technology alone.

Without a security protocol that users can follow, they’re at the mercy of creative social engineering tactics.  If you have a protocol you’d like to share, let me know. I’d be happy re-post it here.

– Simon

Last week, I was helping an enterprise-level security team identify seriously at-risk systems.  My scope included Windows and UNIX hosts, regardless of what applications these systems were hosting.  As a Qualys customer, they already scan close to 800 servers on a weekly basis, so I had fresh vulnerability information that I could analyze.  The team’s current approach to prioritizing patch efforts consist of a Top-25 report, which they customize to include not just the vulnerable system, but also the system admin and their manager.  These reports are discussed at management meetings, so they’re a great way to create traction and accountability.  After all, no one wants to see their name on that report week after week! Bullseye

I like the Top-25 approach, but it only shows systems across the enterprise that have the most weaknesses, regardless of attack vector or the presence of a working exploit.  Knowing which  systems have the most weaknesses is important, but it does not highlight the greatest risks.  For example, which database servers have at least one weakness that could give a remote intruder (or “trusted” user) root access if the hole was exploited?  After all, it only takes one weakness of this sort to cause mayhem of data-breach proportions.  Pinpointing these systems versus systems with the most weakness is critical.

With that in mind, I customized their report templates to search for what I call “Confirmed Remotely Exploitable And Patchable” vulnerabilities, or CREAPs for short.  We all know that creeps are bad, but CREAPs are really bad…they meet all of the following criteria:

  • Exploiting the weakness could lead to unauthorized root or admin access, or, critical files can be read or modified by unauthorized users.
  • An active exploit is published for the vulnerability through public or private sources like Canvas, SAINT, Metasploit, Core IMPACT
  • Local access is not required to exploit the weakness; the hole can be exploited over the network
  • A patch is available to fix the vulnerability

 

Sample of the Metasploit Framework 3.0 Beta ru...

When CREAP analysis is performed, volumes of vulnerability information become more meaningful.  A 200 page vulnerability report can be reduced to a dozen pages, listing just those systems that can be readily exploited using publicly available software.  But these weakness also have a published patch, making them “serious, but fixable.”  Now let’s pause for a moment — I’m certainly not suggesting that only CREAPs matter when it comes to patch management.  What I am suggesting, however, is that CREAPs pose a significant threat to networked servers and databases.  Consider how easy it is for cyber-criminals (and professional pen-testers like me) to gain access to an internal PC with a simple but effective phishing attack, or a “weaponized” Adobe PDF attachment.  Once the bad guys are on a PC or laptop behind the corporate firewall, it’s easy to locate and exploit mission critical systems with REAPs.

Many organization have no idea how many high-risk server or PC-level vulnerabilities there are on the network.  Others know exactly how many there are and a paralyzed by the sheer number of weakness. I once worked with a state agency to deploy a vulnerability management solution.  After one week of analysis, we found over 8,000 high-risk weakness across the enterprise.  With such a massive number, where do you start?  You have to start somewhere — beginning with CREAPs will yield the greatest return for the effort spent.  With limited budget, staff, and time, that’s the kind of return you need.

As always, feedback is welcome.   — Simon

Enhanced by Zemanta

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. 

– Simon

On Day 1 at Black Hat USA 2Idontcare010, I sat-in on the Cloud Security Alliance (CSA) Application Security Findings session.  According to the speaker, "Developers don't care… they're  motivated to simply ship code, not secure code."  

I've worked with numerous developers on application security assessments, penetration tests, and software design projects.  I've never met a developer who doesn't care about security.  Not a high-priority? Perhaps. Discouraged or intimidated by security jargon and FUD? Yes.  But not caring? No way. 

The developers I've met are smart folks.  I've met coders that know the Open Web Application Security Project's (OWASP) Top-10 front to back.  Others are aware, but lack a consistent approach to keeping holes plugged.  They're stuck in a loop of getting burned, scrambling for a fix, and plugging the hole, only to get stung again a few weeks later by a different attack.  Others know all about the risk of data breaches and credit card theft, but don't know the motives or methods behind those that pull it off.  It's a problem, but isn't a high enough priority until something bad happens.

StackobooksCreating secure code begins with education and awareness.  It starts at the top of the organization, the C-level, and goes all the way down to the developers.  Producing "hacker-proof" code certainly calls for new development skills and processes, but it also requires a changed perspective on software threats.  You can send your developers to defensive coding classes, but if a healthy security attitude isn't developed, people will soon return to old habits.

I know several developers across a variety of verticals.  They supplement their coding skills with these principles, to keep them sharp and their awareness high:

Getting out and staying involved. There were only two developers in a room of about 50 people during the Black Hat CSA briefing.  This tells me there aren't enough developers attending conferences where they can see first-hand how the bad guys exploit flaws.  You can create "secure coding evangelists" in your organization by letting one or two developers attend conferences like Black Hat, just to see how expert researchers hunt for bugs and exploit weaknesses.  These are real eye-openers.  For a lower cost alternative, there are security groups that focus on secure development.  Checkout the Open Web Application Application Security Project (OWASP) site to see if there's a local chapter in your city.      

Anticipating threats.  It seems like each time a company "builds a ten foot wall" attackers put-up an 11 foot ladder."  This dynamic reveals an adversary that is motivated and skilled.
Alert Developers that know Cyber-criminals aren't going to quit place a critical eye on every piece of code they write.  They also monitor current or emerging tactics and consider them as they develop.  Armed with the current reality, they look for and incorporate
development techniques that make them defensive coders, versus reactive
ones. 

Making no assumptions.  Hackers don't use code the way a developer intends.  Your functional specification, design document, and web interface mean nothing to them.  Put on their hat.  But first, forget thinking outside of the box; get out of the box and burn it.  I watched a security researcher demonstrate how to bypass authentication in a VMWare product.  While researching the bug, he realized he couldn't exploit the flaw using the software client provided by the vendor.  The solution? He simply wrote his own client and gained unauthorized access to the VMWare environment.  Good developers know they can't hide a vulnerability — they can only delay how long it takes before it's found. 

Cheers! Simon

Yesterday, on Day 1 of Black Hat 2010, I attended an excellent discussion by two forensics experts. Their talk covered four incidents they investigated.  The method the criminals used to break-in ranged from incredibly trivial tPhishing-identity-theft1o very clever.  While the mechanics of the malware were very intriguing, one piece stood out — the malicious software used FTP or SMTP (email)  to send the captured credit card information to the  criminal.  Yes, that's right, the malware used default Internet access to transfer the "goods." 

The speakers even made a point of stating that no one is restricting outbound access.  It's a default privilege for employees and criminals take advantage of this excessive right.  

Techs – This is all about egress filtering, or blocking what is allowed to access the Internet.  I'm not talking about full and total lock down here, but your servers should not be able to access the Internet.  Your PC should not be able to establish SMTP connections to external hosts.  URL Filtering / Proxying is also a critical step for limiting what goes out, but that's a different post.   

Execs – Planned properly, your IT team can significantly restrict outbound (egress) access to the Internet without interrupting business operations.  Making Internet access a convenience for all means it's also convenient for malicious software that will make it onto your network.

Egress filtering won't prevent malware from infecting your systems.  And smart malware will use something like HTTP or HTTPS to communicate with the bad guys.  What egress filtering can do, however, is let you know when something is trying to get out using a method that is not allowed.  This decreases the time it takes for you to investigate, and ultimately limits how much damage the malware does.

Cheers!  Simon

I was talking the other day with a good friend that works in IT at a large public company.  He was excited to hear I was finally getting UberSecure going. 

"I can't wait to read about how to social engineer, break-in to networks, and hack websites and databases!", he said. 

What he didn't know is I'm not planning to post uber-technical material.  In fact, I want to stay away from bits and bytes… if I can help it!  After I explained who my target audience is for UberSecure he was even more excited.

Here's a summary of what I told him…  

"ExecBytecomponentss and techs have their own blogs they like to read.  These blogs are
written in their industry language with a job specific tone or message. 
There are fantastic blog resources for every slice of the business, but successfully managing security pains requires a united business
and technical approach.  I think most people would agree with that, but problems begin when these two groups get together — they talk past, over, or around each other.  There's plenty of words (colorful ones, too), but no communication.  Security progress comes to a stand still.  Execs are now "cheap and stupid" and the tech folks are "geeks that just want more toys."  

It goes without saying that execs and techs don't need to be experts in the other's discipline, i.eAccountant_calculator. the CFO doesn't need to know how to create
firewall rules and the network manager doesn't need to know how to
calculate the company's net income.  What they do need to know is how to communicate with each other — without hype, FUD, jargon, or evasiveness. Part of my goal is to connect  the "doers" and the "deciders" in a way that helps them make better decisions about protecting sensitive data and resources — before their penetration test, annual audit, or even better — before there's a break-in

Just adding more technology without knowing the root cause of security lapses is only a temporary fix.  Plus, there are softer, subtle factors that can undermine the effectiveness of security… things I've seen from assessing scores of companies.  Call it uncommon common sense.  That's what I want to address." 

I'd like to hear from you.  If you've got an "execs and techs" tip or story you want to share, let me know.  You can post a comment any time if you've got something you'd like me to cover in future posts. 

Cheers!  Simon