0

The Hunt for Red October: Privileged Accounts Persist as Common Attack Vector

Posted on January 22, 2013 by John Worrall

Last week, another significant and advanced cyber-attack has caught the security headlines for all of the right—and wrong—reasons. The attack was first uncovered by researchers at Kaspersky Lab who identified what they described as a “high-level cyber-espionage campaign” that has infiltrated networks at diplomatic, governmental and scientific research organizations over the past five years. While the target of the attack, dubbed Red October, may be reminiscent of other noteworthy breaches, including Stuxnet and Flame, the campaign is, in essence, a malware-based external breach and espionage platform that siphons data from mobile devices, PCs, and network hardware. Once inside the enterprise, the attackers could scan across the network and exploit vulnerabilities, including those accessible with administrative credentials and/or default passwords.

While the attack is primarily gaining publicity due to its apparently sophisticated and deliberate cyber espionage initiative against government and diplomatic organizations, the virus is another example of the industry’s fascination with custom malware that can be used to bypass the enterprise perimeter and steal sensitive data. In the case of Red October, the attack penetrates the perimeter and gathers intelligence from both traditional attack targets (workstations), as well as other network-connected devices including smartphones, network equipment configuration software and removable disk drives.

What the media—and the industry—continues to overlook, however, is the common pathway between these external attacks and the stolen data. While cyber espionage, malware attacks and proactive perimeter security measures may gain more intrigue, the real issue is that once inside, attackers immediately target privileged accounts to gain widespread access to the rest of the network.

Examining Red October further, it’s clear that this attack is no different than others—including Stuxnet and Flame—that targeted and leveraged privileged accounts. In this case, once inside the networks of their government targets, the Red October perpetrators were able to move around the network as if they were a privileged employee and uncover additional vulnerabilities to exploit by accessing admin credentials retrieved from malware-infected databases and systems. Once these credentials are stolen, attackers can take things to the next level by reusing them in later attacks by guessing similar passwords and network credentials in other locations. This should come as no surprise—although they serve as the gateway to an organization’s most sensitive data, privileged accounts are often protected by weak passwords, which are seldom replaced.

So while news will continue to detail the ramifications of Red October, it is important to note that we have been here before. Saudi Aramco. Subway Restaurants. Global Payments. US Chamber of Commerce. The list goes on, and will continue to go, if organizations continue to fail to recognize the importance of locking down and securing these privileged access points. Ultimately, it is a new approach to security – starting on the inside and working out, but it is an imperative. Rather than focusing on firewalls or perimeter security, organizations need to prioritize the identification, monitoring and management of privileged accounts.

It may be bad news for headline writers, but this approach will block hackers from gaining the true spoils they desire—sensitive corporate and government data accessible only through privileged accounts.

0

Protecting Privileged Accounts can be the Difference Between “Managing” and “Securing” File Transfers

Posted on January 10, 2013 by Oded Valin

In the digital world in which we live, securing file transfers is critically important to personal and corporate security. Every day we send and receive sensitive information with the expectation that the services we use help us keep it secure.

But, as we re-learn constantly, vendors calling themselves ‘secure’ doesn’t always make it so. The latest egregious example is found in a high profile vulnerability discovered in a managed file transfer service used internally by Facebook employees:
http://yro.slashdot.org/story/13/01/08/1949210/serious-password-reset-hole-in-accellion-secure-ftp

In short, the vulnerability allowed an attacker to create a new user account, log in with that new account and change the password of another user, even if that other user had full administrative privileges. After that, a would-be attacker has a clear shot at any of the data in the file transfer application. Ouch!

Unfortunately, that’s what can happen when security is added as an afterthought and is not a core design principal built into the product from the ground up.

Given that Cyber-Ark’s business is all about privileged accounts and securing critical data from advanced attacks, we do know something about this. If you are looking at a truly secure file transfer service that won’t put your critical data at grave risk, here are some things you need to look for.

  1. The process used to create new users should not rely on public, generic URLs, but have a full set of security controls and optional secure workflows in place.
  2. The entire password resent process should work in a secure way:
    • It shouldn’t rely only on a HTTP POST request without asking for the user’s current password or using a unique link.
    • It shouldn’t transfer confidential parameters in a POST request without encrypting it with something stronger than BASE64.
    • The reset function should use a unique link with an expiration period, not a public, generic and insecure link.
    • It should offer the option of adding personal security question challenges to the process.
  3. Session management should be done in a secure way using a unique session ID and unique tokens. It cannot be part of the URL.
  4. Executable code should be obfuscated
  5.  The file repository should be fully encrypted and separated from the web application server in case the web portal is attacked.
  6. Follow the National Institute of Standards and Technology (NIST) guidance and “require your vendor to demonstrate that their software development processes employ state-of-the-practice software and security engineering methods, quality control processes and validation techniques”.

This sounds basic – but it’s part of the due diligence that every business should do to truly understand the level of security that has been built into the product. Just because a vendor claims to offer “secure” file transfer or cloud sharing, doesn’t make it so.

If security really matters to you, (and it should,) your best bet would be to start with a company with a “security first” approach, and the credentials to back it up.

0

Was your car stolen? Blame an unprotected privileged account

Posted on January 8, 2013 by John Worrall

We’ve often referred to privileged accounts as the “Keys to the Kingdom” given the wide ranging access they provide.  But are privileged accounts the “Key” to your car as well?  Maybe, if you drive a BMW.    Nick Barron posted an article in SC Magazine UK this week demonstrating why this may be the case:  BMWs: Gone in 60 keystrokes – SC Magazine UK.

For BMWs new “keyless” cars, there is an administrative function that allows mechanics to service and repair the car.  It also provides them access to the information needed to initialize a new key.  Seems odd, but so far, it’s not a real problem.  Unless, of course, that same function is available to anyone, and not just to your trusted garage mechanic.  To make matters worse, the car alarm couldn’t detect the tampering.  Car thieves have a clear shot.

This is a perfect example of what commercial and government organizations face with their IT-based resources.  Certain “privileged accounts” are built into nearly every IT product to allow authorized administrators to service and repair the systems.  Used properly, and by trusted, authorized people, they present no problem.  But of course, in malicious or careless hands, these accounts can cause catastrophic damage.

Best practices are emerging around a three-stage approach to managing these potential vulnerabilities.   First, protect the credentials to these accounts, so only authorized users can access them. Next, add accountability.  Ensure that every time a privileged account is used, you know who the specific user is, what they did with the account and why they did it. Finally, provide real-time intelligence on how these account are being used so that any potential misuse can be addressed immediately, and not after the damage is done.

Using the BMW example for the purpose of illustration, here’s how it might play out if proper privileged account controls are in place.  First, access to the administrative function would be limited to authorized personnel only.  Every action taken using the account should be recorded, with the owner being able to review exactly what work was done, which mechanic did it and why.  And of course, a real-time alert on the car owner’s smart phone telling them that the key was cloned would be very helpful in trying to catch the thief before they drove away with the $60,000 car.

I realize I’m ignoring many realities of cars and mechanics, of which I know very little.  But it’s a great way to think about the privileged account problem in our IT infrastructure.  Protection. Accountability. Intelligence.