The Identity Context

The Identity Context
Jason Soroko
Part 3 of 3 in the Series — Identity Context: Defense's Next Play

Part Three: The Identity Context

 All attacks involve some form of stolen identity.

According to Mandiant’s threat landscape study, 100 percent of breaches they investigated involve stolen credentials.

In our own studies — where we reverse-engineered malware and studied the source code of viruses such as Zeus — much of the functionality is designed to steal usernames, passwords and even SMS-delivered one-time passcodes.

As an example, Eurograbber redirected Android SMS messages, often referred to as TANs (Transaction Authorization Numbers). Another common example of stolen credentials is hashed Windows desktop credentials, which is known to be how hackers laterally move within a corporate network.

 Kill Chain – Identity

The word identity only appears once in Lockheed Martin’s paper on the Kill Chain, and this was in relation to the identity of the intruder, not a stolen identity of the victim.

It could be argued that identity is at the core of every item on Lockheed Martin’s kill chain. From earliest reconnaissance to final actions on the target, an identity is either being actively searched, stolen or utilized.

 Simplistic Identity Context

Some security vendors refer to the identity context and offer a customer the ability to create blacklist and whitelist rule sets such as:

–          A finance employee should never have login access to computers containing sensitive intellectual property.

–          Employee logins should not be authorized to access sensitive computers past 7 p.m., or on weekends.

–          Never let an IT administrator access central financial servers (a rule which may often get overruled)

These rule sets (simplified from the complex levels they can attain), whether enforced at endpoints or by an internal firewall or IDS/IPS system, are all useful. But this does not take in to account inevitable flaws in the operating systems on the network. Nor does it address the biggest problem of securing identities, which is when they are ambiguous.

 Identity Ambiguity

Identity-based security that does not address identity ambiguity is a way to give the advantage to the adversary.

–          Privilege Escalation. Malware on a desktop PC assumes the identity of the person logged in. Privilege escalation can enable a hacker to move further toward their goal.

–          Pass the Hash. Stolen hashes can assume the identity of anyone who has logged in to compromised PC. Adversaries can collect credentials as they move laterally in your network.

–          Spoof. It is possible to spoof MAC addresses, IP addresses, etc. Protecting the device identity is very important. This is where device certificates can be very effective.

–          Session-Riding. Authentication is vital, but insufficient for more sophisticated forms of malware.

Too Much Trust: Flat Networks

A critical infrastructure penetration tester once told me an anecdote about an enterprise that was faced with a unique situation. Parts of the organization’s network were inoperable at certain parts of the day, intermittently. It turned out that a person, who was tasked with mapping their network resources in a Visio diagram, was unknowingly taxing the entire corporate network — sometimes over very limited bandwidths to remote locations.

Network isolation and segmentation is not a hallmark of most corporate networks. Technologies like Active Directory were originally offered as a way to both simplify deployment and manage large numbers of network-connected objects and identities.

The lack of segmentation of these networks is patterned on the selling point of large-scale management.  End-point security and network perimeters were good enough to protect us, right?  We now know better. Networks are too flat, and too trusting.

Worst-Case scenario: When Critical Functions Trust Everyone

Imagine for a moment a programmable logic controller (PLC) device, which controls pumps and valves in a critical infrastructure plant. That PLC device has firmware that controls all of its functions and is connected to an Ethernet jack where it listens to commands and sends status reports. One of the commands it listens for is a firmware reprogramming.

If the PLC device receives a valid command to reprogram itself, it will. And it will never question the identity of who sent the command. If anyone remembers Stuxtnet, this may all sound very familiar.

Was the command authorized by the plant manager? Or could the command have been sent by malware? Or, maybe the command was sent by an insider threat, unbeknownst to the plant manager.

The PLC device trusts everyone on the network and will act on the command, regardless of the origin. It had always been assumed that perimeter defenses would never allow malicious activity inside the perimeter, but we now know this assumption to be a fallacy.

 Internet of Things

Some people on the bleeding edge of technology may like the idea of their refrigerator automatically ordering groceries when supplies get low. And now Google has purchased the company that created the always-connected Nest smart thermostat. More and more things in our daily life will be connected to the Internet.

The explosion of connected devices now makes identity context even more important. Some may not be worried about refrigerator malware. And some may even trust Google to do non-evil things with the data they could potentially mine from connected thermostats and sensors. But I suggest that there are other things to worry about.

Jay Radcliffe gave a talk at Black Hat 2013 about hacking his insulin pump. Could an Internet-connected insulin pump be hacked to give a fatal dose?

What about an Internet-connected pacemaker? The benefits of having a stream of data being sent from a pacemaker to a hospital would be very useful. But Dick Cheney’s doctors disconnected his pacemaker from the Internet for fears that it could be used to hurt him.

So, what is the underlying problem? These connected devices quite often trust the network too much.  Sometimes their authentication strength isn’t strong enough and, even after mutual authentication, they continue to trust transactional commands being issued.

 It isn’t Just Authentication Strength

Malicious weaponization has the capacity to sit and wait for strong authentication to occur. This is true on a desktop PC or an Internet-of-Things-connected device.

Commands that occur after strong authentication may not originate from you. During a session-riding attack, your identity, for the duration of the authenticated session, has essentially been stolen. This does not have to be a cookie-stealing event on a website, but complete PC takeover, either by remote control or by ‘logic bomb.’

Remote control would necessarily require some kind of command and control communication — part of the Kill Chain — and potentially can be detected. Other types of malware have shellcode loaders that enabled cloaked instruction transfer. Some malware comes pre-packaged with all the instructions it requires to achieve its goal — all without requiring external commands. 

The sophistication of most of the attacks we have seen has been low to moderate. Attackers are bound by the same economic laws as the rest of us and will only spend as much resource as necessary to achieve their goal. The technology pipeline of the attackers is also stacked with things we have not seen yet.

 Identity Context

If an inventory list of critical transactions for your corporate, government or critical infrastructure environment were in front of you, it would be frightening to consider that a malicious actor could enact those transactions without your knowledge or permission. The silence of the malicious toolsets is a reality, but it can be reduced by identity assurance.

Jason Soroko
Jason Soroko
Manager, Security Technologies

Soroko has spent 17 years in systems architecture and development roles in diverse industries with an emphasis on security. As the threat landscape becomes more advanced, the need for Entrust to understand evolving threats requires deep and dedicated thinking in security concepts. Soroko's thought-leadership in security is rooted in connecting the threat perspective to how systems work as a whole. He frequents security conferences and publishes on important security topics.


Add to the Conversation