Patch Your Cisco ASA’s ASAP!

Many networks employ Cisco Adaptive Security Appliances (ASA) as firewalls or to set up Virtual Private Networks, etc. Those of you that are among this group should be aware that Cisco published a critical security advisory on February 10 concerning a glitch in their ASA software. It seems that there is a vulnerability in the Internet Key Exchange (IKE) code of Cisco ASA Software that could potentially allow an unauthenticated attacker to gain full control of the system, or to cause a reload of the system.
This vulnerability is due to a buffer overflow condition in the function that processes fragmented IKE payloads. Attackers could exploit the flaw by sending crafted UDP packets to the affected system. It should be noted that this vulnerability is bad enough that it was given a maximum CVSS score of 10.
The ASA software on the following products may be affected by this vulnerability:
• Cisco ASA 5500 Series Adaptive Security Appliances
• Cisco ASA 5500-X Series Next-Generation Firewalls
• Cisco ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers
• Cisco ASA 1000V Cloud Firewall
• Cisco Adaptive Security Virtual Appliance (ASAv)
• Cisco Firepower 9300 ASA Security Module
• Cisco ISA 3000 Industrial Security Appliance
Patches are now available for this flaw. We recommend that vulnerable users of this software apply these patches as soon as possible. For more information see:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike

Introducing Tomce

Today I am thrilled to announce that Tomce Kuzevski has joined the MSI team as an intelligence analyst, working on TigerTrax, analytics and machine learning focused services. I took a few minutes of Tomce’s time to ask some intro questions for you to get to know him. Welcome Tomce, and thanks for helping us take TigerTrax services to the next level! 
 
Q – Tomce, you are new to MSI, so tell the readers the story of how you developed your skills and got your spot on the Intelligence Team.
 
A- Ever since I was a kid, I was always into computers/electronics. I can’t tell you how much money my parents spent on computer/electronics for me, for them only to last a week or so. I would take them apart and put them back together constantly. Or wiping out the hard drive not knowing what I did until later. 
 
Growing up and still to this day, I was always the “go to kid” if someone needed help on computers/electronics which I didn’t mind at all. I enjoyed trying to figure out the issue’s. The way I learned was from failing and trying it myself. From when I was a kid to now, I still enjoy it and will continue to enjoy. I knew I wanted to be in the Computer/IT industry. 
 
I know Adam through a mutual friend of ours. He posted on FB MSI was hiring for a spot on their team. I contacted him about the position. He informed me on what they do and what they’re looking for, which was right up my alley. I am consistently on the internet searching anything and everything. I had a couple interviews with Brent and the team, everything went how it was suppose to. Here I am today about 7 weeks into it and enjoying it! That’s how I landed my spot on the MSI team.
 
Q – Share with the readers the most interesting couple of things they could approach you about at events for a discussion. What kind of things really get you into a passionate conversation?
 
A- I really enjoy talking about the future of technology. Yet, it’s scary and mind blowing at the same time. Being born in the 80’s and seeing the transformation from then to now, is scary. But, laying on the couch holding my iPhone while skyping my cuzin in Europe, checking FB and ordering a pizza all in the palm of my hands is mind blowing. I cant imagine what the world will be like in next 25 years. 
 
 
Q – I know that since joining our team, one of your big focus areas has been to leverage Atticus (our passive security assessment and Intel engine – essentially a slice of the TigerTrax™ platform) to study large scale security postures. You recently completed the holistic testing of a multi-national cellular provider. Tell our readers some of the lessons you learned from that engagement?
 
A- I absolutely could not believe my eye’s on what we discovered. Being such a huge telecom company, having so many security issues. I’ve been in the telecom business 5 years prior to me coming to MSI. I’ve never seen anything like this before. When signing up for a new cell phone provider, I highly recommend doing some “digging” on the company. We use our phones everyday, our phones have personal/sensitive information. For this cell phone provider being as big as they are, it was shocking! If you’re looking for a new cell phone provider, please take some time and do some research. 
 
 
Q – You also just finished running the entire critical infrastructures of a small nation through Atticus to support a larger security initiative for their government. Given how complex and large such an engagement is, tell us a bit about some of the lessons you learned there?
 
A- Coming from outside of the IT security world, I never thought I would see so many security issues at such a high level. It is a little scary finding all this information out. I used to think every company at this level wouldn’t have any flaws. Man, was I wrong! From here on out, I will research every company that I use currently and future. You cant think, “This is a big company, there fine” attitude. You have to go out and do the research.  
 
Q – Thanks for talking to us, Tomce. If the readers want to make contact with you or read more about your work, where can they find you?
 
You can reach me @TomceKuzevski via Twitter. I’am constantly posting Information Security articles thats going on in todays world. Please don’t hesitate to reach out to me. 

State Of Security Podcast Episode 10

Episode 10 is now available! 

This time around, we get to learn from the community, as I ask people to call in with their single biggest infosec lesson from 2015. Deeply personal, amazingly insightful and full of kindness to be shared with the rest of the world – thanks to everyone who participated! 

Comparing 2 Models for DMZ Implementations

I recently had a discussion with another technician about the security of the two most popular DMZ implementation models. That is: 
  • The “3 Legged Model” or “single firewall” – where the DMZ segment(s) are connected via a dedicated interface (or interfaces) and a single firewall implements traffic control rules between all of the network segments (the firewall could be a traditional firewall simply enforcing interface to interface rules or a “next generation” firewall implementing virtualized “zones” or other logical object groupings)
  • The “Layered Model” or “dual firewall”- where the DMZ segment(s) are connected between two sets of firewalls, like a sandwich
 
Both approaches are clearly illustrated above, and explained in detail in the linked wikipedia article, so I won’t repeat that here. 
 
I fully believe that the “3 Legged Model” is a lower risk implementation than the layered model. This outright contradicts what the wikipedia article above states: 
 
     “The most secure approach, according to Stuart Jacobs, [1]is to use two firewalls to create a DMZ.” — wikipedia article above.
 
While the Layered model looks compelling at first blush, and seems to apply the concept of “more firewalls would need to be compromised to lead to internal network access”; I believe that, in fact, it reduces the overall security posture in the real world, and increases risk. Here’s why I feel that way. Two real-world issues that often make things that look great at first blush or that “just work” in the lab environment, have significant disadvantages in the real world are control complexity and entropy. Before we dig too deeply into those issues though, let’s talk about how the two models are similar. (Note that we are assuming that the firewalls themselves are equally hardened and monitored – IE, they have adequate and equal security postures both as an independent system and as a control set, in aggregate.)
 
Reviewing the Similarities
 
In both of the models, traffic from the DMZ segment(s) pass through the firewall(s) and traffic controls are applied. Both result in filtered access to the internal trusted network via an often complex set of rules. Since in both cases, traffic is appropriately filtered, authorization, logging and alerting can adequately occur in both models. 
 
Establishing Differences
 
Now the differences. In the 3 Legged model, the controls are contained in one place (assuming a high availability/failover pair counts as a single set of  synced controls), enforced in one place, managed and monitored in one place. The rule set does not have cascading dependencies on other implementations of firewalls, and if the rule set is well designed and implemented, analysis at a holistic level is less complex.
 
In the Layered model, the controls are contained across two separate instances, each with different goals, roles and enforcement requirements. However, the controls and rule sets are interdependent. The traffic must be controlled through a holistic approach spread across the devices, and failures at either firewall to adequately control traffic or adequately design the rule sets could cause cascading unintended results. The complexity of managing these rules across devices, with different rule sets, capabilities, goals and roles is significantly larger than in a single control instance. Many studies have shown that increased control complexity results in larger amounts of human error, which in turn contributes to higher levels of risk. 
 
Control Complexity Matters
 
Misconfigurations, human errors and outright mistakes are involved in a significant number (~95%) of compromises. How impactful are human mistakes on outright breaches? Well according to the 2015 Verizon DBIR:
 
“As with years past, errors made by internal staff, especially system administrators who were the prime actors in over 60% of incidents, represent a significant volume of breaches and records ,even with our strict definition of what an “error” is.” —DBIR
 
Specifically, misconfiguration of devices were involved in the cause of breaches directly in 3.6% of the breaches studied in the DBIR. That percentage may seem small, but the data set of 79,790 incidents resulting in 2,122 breaches that means a staggering number of 76 breaches of data were the result of misconfigurations.
 
This is exactly why control complexity matters. Since control complexity correlates with misconfiguration and human error directly, when complexity rises, so does risk – conversely, when controls are simplified, complexity falls and risk of misconfiguration and human error is reduced.
 
Not to beat on the wikipedia article and Stuart Jacob’s assertions, but further compounding the complexity of his suggestion is multiple types of firewalls, managed by multiple vendors. Talk about adding complexity, take an interdependent set of rules and spread them across devices, with differing roles and goals and you get complexity. Now make each part of the set a different device type with it’s own features, nuances, rule language, configuration mechanism and managed service vendor, and try to manage both of those vendors in sync to create a holistic implementation of a control function. What you have is a NIGHTMARE of complexity. At an enterprise scale, this implementation approach would scale in complexity, resources required and oversight needs logarthmically as new devices and alternate connections are added. 
 
So, which is less complex, a single implementation, on a single platform, with a unified rule set, managed, monitored and enforced in a single location – OR – a control implemented across multiple devices, with multiple rule sets that require monitoring, management and enforcement in interdependent deployments? I think the choice is obvious and rational.
 
Now Add Entropy
 
Ahh, entropy, our inevitable combatant and the age old foe of order. What can you say about the tendency for all things to break down? You know what I am about to point out though, right? Things that are complex, tend to break down more quickly. This applies to complex organisms, complex structures, complex machinery and complex processes. It also applies to complex controls.
 
In the case of our firewall implementation, both of our models will suffer entropy. Mistakes will be made. Firewall rules will be implemented that allow wider access than is needed. Over time, all controls lose efficiency and effectiveness. Many times this is referred to as “control drift” or “configuration drift”. In our case, the control drift over a single unified rule set would have a score of 1. Changes to the rule set, apply directly to behavior and effectiveness. However, in the case of the Layered model, the firewalls each have a distinct rule set, which will degrade – BUT – they are interdependent on each other – giving an effective score of 2 for each firewall. Thus, you can easily see, that as each firewall’s rule set degrades, the private network’s “view” of the risk increases significantly and at a more rapid pace. Simply put, entropy in the more complex implementation of multiple firewalls will occur faster, and is likely to result in more impact to risk. Again, add the additional complexity of different types of firewalls and distinct vendors for each, and the entropy will simply eat you alive…
 
Let’s Close with Threat Scenarios

Let’s discuss one last point – the actual threat scenarios involved in attacking the private network from the DMZ. In most cases, compromise of a DMZ host will give an attacker a foothold into the environment. From there, they will need to pivot to find a way to compromise internal network resources and establish a presence on the internal network. (Note that I am only focusing on this threat scenario, not the more common phishing/watering hole scenarios that don’t often involve the compromise of a DMZ host, except perhaps for exfiltration paths. But, this is outside our current scope.) If they get lucky, and the DMZ is poorly designed, they may find that their initially compromised host has some form of access to the internal network that they can exploit. But, in most cases, the attacker needs to perform lateral movement to compromise additional hosts, searching for a victim that has the capability to provide a launching point for attacks against the internal network.
 
In these cases, detection is the goal of the security team. Each attacker move and probe, should cause “friction” against the controls, thereby raising the alert and log levels and the amount of unusual activity. Ultimately, this should lead to the detection of the attacker presence and the incident response process engagement.
 
However, let’s say that you are the attacker, trying to find a host that can talk to the internal network from the DMZ in a manner that you can exploit. How likely are you to launch an attack against the firewalls themselves? After all, these are devices that are designed for security and detection. Most attackers, ignore the firewalls as a target, and continue to attempt to evade their detection capabilities. As such, in terms of the threat scenario, additional discreet firewall devices, offer little to no advantage – and the idea that the attacker would need to compromise more devices to gain access loses credibility. They aren’t usually looking to pop the firewall itself. They are looking for a pivot host that they can leverage for access through whatever firewalls are present to exploit internal systems. Thus, in this case, both deployment models are rationally equal in their control integrity and “strength” (for lack of a better term).
 
Wrapping This Up
 
So, we have established that the Layered model is more complex than the 3 Legged model, and that it suffers from higher entropy. We also established that in terms of control integrity against the most common threat scenario, the implementation models are equal. Thus, to implement the Layered model over the 3 Legged model, is to increase risk, both initially, and at a more rapid pace over time for NO increase in capability or control “strength”. This supports my assertion that the 3 Legged model is, in fact, less risky than the Layered model of implementation.
 
As always, feel free to let me know your thoughts on social media. I can be found on Twitter at @lbhuston. Thanks for reading! 

Ask The Experts: Devaluing 0-days

Earlier this week, I heard an awesome speech at Columbus BSides about the economics of Exploit Kits and E-Crime. As a follow-up, I thought it would be worthwhile to ask my fellow MSI co-workers if they felt there was a way to devalue 0day vulnerabilities.

Jim Klun responded with…

I don’t think you can ever really – given how Internet/computer usage has been universally adopted for all human activity – devalue the worth of a 0-day. The only thing I can imagine is making the chance of a 0-day being discovered in an area of computing that really matters as small as possible. So that means forcing – through law – all sensitive infrastructure (public or private) and comm channels to subscribe to tight controls on what can be used and how things can work. With ongoing inspection and fines/jail time for slackers. Really.. don’t maintain your part of the Wall properly, let the Mongols in and get some villages sacked, and its your head.

I would have techs who are allowed to touch such infrastructure (or develop for it) uniformly trained and licensed at the federal level. Formal process would exist for them doing doing 0-day research and reporting. Outsiders can do same…. but if they announce without chance for defensive response, jail.  And for all those who do play the game properly and find 0-days within the reduced space of critical infrastructure/software  – money and honor.

Brent Huston added his view…

Thats a tough question. Because you are asking to both devalue something, yet make it valuable for a different party. This is called market transference.

So for example, we need to somehow change the “incentive” to a “currency” that is non-redeemable by bad guys. The problem with that is – no matter how you transfer the currency mechanism, it is likely that it simply creates a different variant of the underground market.

For example, let’s say we make 0-days for good guys redeemable for a tax credit, so they can turn them into the IRS and get a tax credit in $ for the work… Seems pretty sound…Bad guys can’t redeem the tax credits without giving up anonymity. However – it reenforces the underground market and turns potential good guys into buyers.

Plus, 0days still have intrinsic value – IE other bad guys will still buy them for crime as long as the output of that crime has a value. Thus, you actually might increase the number of people working on 0day research. This is a great example of where market transference might well raise the value of 0days on the underground market (more bidders) and the population attackers looking for them (to sell or leverage for crime).

Lisa Wallace also provided her prospective…

Create financial incentives for the corporations to catch them before release. You get X if your product has no discovered 0-days in Y time.

Last but not least, Adam Hostetler weighed in when asked if incentives for the good guys would help devalue 0days…

That’s the current plan of a lot of big corporations, at least in web apps. I don’t think that really devalues them though. I don’t see any reasonable way to control that without strict control of network traffic, eavesdropping etc, or “setting the information free”.

Interesting Talk on Post Quantum Computing Impacts on Crypto

If you want to really get some great understanding of how the future of crypto is impacted by quantum computing, there is a fantastic talk embedded in this link
 
The talk really turns the high level math and theory of most of these discussions into knowledge you can parse and use. Take an hour and listen to it. I think you will find it most rewarding.
 
If you want to talk about your thoughts on the matter, hit us up on Twitter. (@microsolved)

OpenSSH Patch Released

If you’re using version 5.4-7.1 of OpenSSH, you should install the latest patch as soon as possible. The patch is for a critical vulnerability that can be exploited to reveal private keys to a malicious server. The vulnerability is tied to an undocumented feature called “roaming”. The roaming feature allows an OpenSSH client to resume an interrupted SSH session. If for some reason you’re unable to install the patch at this time, the vulnerable code can also be disabled by inserting “UseRoaming no” into the global ssh_config(5) file or adding “-UseRoaming=no” to the user configuration in ~/.ssh/config.
Despite the fact that this vulnerability is being compared to Heartbleed, it is not quite as severe. Exploiting this vulnerability would require a client to connect to a malicious SSH server. Heartbleed could be exploited by attacking the SSH server directly. However, it is still worth addressing this newly discovered vulnerability as soon as possible.

First Power Outage Ever Caused by Malware

For the last couple of decades industrial concerns, including public utilities such as power and gas providers, have been incorporating IP networks into their industrial control systems; apparently with very little awareness of the security problems this could cause. One of the reasons for this is that ICS/SCADA systems had always been fairly safe from tampering. They were “dumb” systems that had their own protocols, and were not connected to public networks. System administrators never had to think in terms of hackers and remote attacks. They were more concerned with things like physical break-ins and theft at that time, and hackers were mainly computer-savvy kids that weren’t really out to hurt anyone.

Another reason is that security almost always takes a back seat to greater efficiency and profitability. Couple this with the fact that public utilities were increasingly strapped with budgetary cutbacks, and it’s a no-brainer from their point of view. IP protocols were already in place and off-the-shelf hardware and software applications were relatively cheap.

Embracing expediency in this way is really costing the industry now, though. Public utilities are often guilty of failing to adequately segregate their control networks from their business networks, and even if they do, it is very difficult to fend off a persistent and talented attacker. Malware and social engineering techniques become more clever every day.

Factors such as these have made the security industry increasingly antsy for years. We have been warning that these vulnerabilities exist, and have been expecting a concrete example to crop up – and now it has!

Late last month, hackers caused what is believed to be the world’s first power outage using malware. It occurred in the Ukraine and knocked out regional power for several hours. The malware family used to perpetrate this outage is known as “BlackEnergy” and has been on the radar for some time.

Luckily, this was a relatively minor, short lived incident, and nothing like this has occurred (yet) in the United States. However, the fact that this outage was possible should be a wake-up call for all of us. Hopefully, the industry will pay attention to this incident and redouble their efforts to update, secure and monitor their systems.

Time Warner – 320,000 passwords compromised

Knock knock! Who’s there? The FBI….

This is never the way you’d like your day to play out. Last week, Time Warner was notified by the FBI that a cache of stolen credentials that appear to belong to Time Warner customers had been discovered.

At this point, the origination of the usernames and passwords is a bit of a mystery. Time Warner states: 

“We have not yet determined how the information was obtained, but there are no indications that TWC’s systems were breached.

The emails and passwords were likely previously stolen either through malware downloaded during phishing attacks or indirectly through data breaches of other companies that stored TWC customer information, including email addresses.

For those customers whose account information was stolen, we are contacting them individually to make them aware and to help them reset their passwords.”

Time Warner customers who have not yet been contacted should still consider changing their  passwords – there is no indication at this point if this is new or previously compromised password data, and a new password is never a bad idea.

Please share with anyone who is using Time Warner systems – friends, co-workers, weird relatives and neighbors as well. Remember that any password that is used twice isn’t a safe password – unique passwords are always the best practice. Password managers (LastPass, KeePass, etc.) are often a good idea to help maintain unique, difficult to decipher passwords.

It’s Tax Time Again: Watch Out for the Fake IRS Phishing Scams!

It seems like every year there is another phishing scam using the name of the Internal Revenue Service. Well, this year is no exception. This version claims to be a refund notification and contains an attachment for the unwary to click on. Don’t do it! For one thing, you should be aware that the IRS never initiates contact with taxpayers by email, text messages or social media channels to request personal or financial information.
This scam and other, similar scams also are perpetrated by telephone. Callers may say you have a refund due and try and get you to disclose private information to them. They may also call, say you owe them money, and demand immediate payment; they may even threaten to send the police to your home! Don’t panic. The more serious and immediate their demands seem, the more likely they are to be fakes. It will never hurt you to take the time to call the IRS and see if the call, text or email you have received is legitimate. Also, if you do happen to lose money to one of these scams, you can file a complaint with the Treasury Inspector General for Tax Administration.
The IRS website has resources in place to help taxpayers with this problem. This information is not particularly easy to find, but is accessible in a couple of areas of the website. If you click on the “News & Events” tab of the website there is a hyperlink to “Tax Scams”. This will get you started. You can also go to the “Help & Resources” tab. This area has links for reporting suspicious emails and scams, as well as a link to report tax fraud activity. For more information about past scams of this type, there is a page entitled “Phishing and Other Schemes Using the IRS Name.”
The important thing to take away from this is that Phishing and other types of social engineering techniques are becoming more prevalent every day, and are not about to go away. This is because as firewalls, SIEM solutions and other information security mechanism have become more effective, cyber criminals have had to find new ways to worm their way into your networks. So stay wary and avoid being credulous. Never open an attachment or click on a link anywhere without checking it out first. Also, never give unsolicited or suspicious callers any kind of private information. The old adage “Look Before You Leap” has never been more true and appropriate than it is right now!