IDP (Intrusion, Detection and Prevention) provides cybersecurity, information assurance, compliance, vulnerability assessments, penetrating testing and a variety of security consulting services.
We have identified a vulnerability in the Internet Public Key Infrastructure (PKI) used to issue digital certificates for secure websites. As a proof of concept we executed a practical attack scenario and successfully created a rogue Certification Authority (CA) certificate trusted by all common web browsers. This certificate allows us to impersonate any website on the Internet, including banking and e-commerce sites secured using the HTTPS protocol.
Our attack takes advantage of a weakness in the MD5 cryptographic hash function that allows the construction of different messages with the same MD5 hash. This is known as an MD5 "collision". Previous work on MD5 collisions between 2004 and 2007 showed that the use of this hash function in digital signatures can lead to theoretical attack scenarios. Our current work proves that at least one attack scenario can be exploited in practice, thus exposing the security infrastructure of the web to realistic threats.
This successful proof of concept shows that the certificate validation performed by browsers can be subverted and malicious attackers might be able to monitor or tamper with data sent to secure websites. Banking and e-commerce sites are particularly at risk because of the high value of the information secured with HTTPS on those sites. With a rogue CA certificate, attackers would be able to execute practically undetectable phishing attacks against such sites.
The infrastructure of Certification Authorities is meant to prevent exactly this type of attack. Our work shows that known weaknesses in the MD5 hash function can be exploited in realistic attack, due to the fact that even after years of warnings about the lack of security of MD5, some root CAs are still using this broken hash function.
Co-authored by Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger
There is much debate about how to define security - as in digital or IT security.
All too often IT security is spoken of as a "cost to the business". On a broader level I believe IT security is a responsibility management has it its stakeholders. That's not a definition of IT security, simply what it is.
Keeping with the concept of what IT security is - well it is not a cost to the business; rather, it is an investment by the business. It only becomes a cost to the business AFTER an exploit has taken place and digital information has been compromised or stolen.
Another fallacy I hear in my travels is that an investment in IT security is nothing more than an insurance policy; i.e. insurance that the digital information will remain safe if the proper investment is made to protect it.
A businesses' investment in IT security is not an insurance policy. An insurance policy pays the insured to compensate for a covered loss. Certainly, there are various types of business insurance a company can buy for data loss, but that is missing the point, because we're talking about IT security, not insurance.
So what then is the definition of IT security? By Daniel Miessler on September 3rd, 2008 The process of maintaining an acceptable level of perceivedrisk. There are a few things to like about this definition.
Process. i.e. it doesn't end.
Acceptable. This alludes to the fact that the organization's upper management decides-based on the entity's goals as a whole-how much risk to take on. The crucial piece here is that this isn't for security professionals to decide.
Perceived. In short, "you don't know what you don't know". And this is where security professionals come in. Their entire job is to ensure that management is making informed decisions.
Risk. As we all know, it's not a good idea to use words with disputed definitions as part of another definition. And since risk is one such word, I'll clarify briefly how I define risk. In general, I prefer NIST's description from NIST Publication SP 800-30:
Risk is a function of the likelihood of a given threat-source's exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization. To determine the likelihood of a future adverse event, threats to an IT system must be analyzed in conjunction with the potential vulnerabilities and the controls in place for the IT system.
This reveals a few primary components: likelihood, threat-source, vulnerability, and impact. The word "function" used in the definition is pivotal; it reveals that if any of the values increase or decrease, the total risk does as well. I also prefer to add asset value to the equation, and this is a popular choice.
Ultimately, however, the definition of risk can be reduced to a much more usable, less academic form, and this is the way you are going to be most successful communicating it with those who are not security professionals.
A risk is a chance of something bad happening.
Too simple? Not really. It's instantly understandable to virtually everyone, but at the same time it does not contradict the more complex definitions.
So when should you use one definition vs. the other?
In general, use the simple version. Getting entangled in the infinite number of ways risk can be calculated is something to avoid. It drains time and rarely accomplishes anything when broken down much farther than is described above.
So, written out (i.e. without the word "risk") we arrive at:
Security is the process of maintaining, based on what we know, an acceptable level of likelihood that something bad will happen to the organization.
…and once again, in it's more succinct and elegant form:
Security is the process of maintaining an acceptable level of perceived risk.
Hackers defaced collider site, say reports Published: 2008-09-12
UPDATED: A group of online vandals compromised the security of a server at the Large Hadron Collider (LHC) this week, putting up a Web page mocking the site's security but not the experiment, according to reports in two U.K. newspapers.
"We don’t know who they were but there seems to be no harm done," James Gillies, a spokesman for CERN, told the Times. "It appears to be people who want to make a point that CERN was hack-able."
CERN, the largest particle collider in the world, made history this week when the giant $8-billion machine was activated and its first beam of particles completed the 27 kilometer circuit underground. The two test beams created so far have been dumped, as the technical teams calibrated and check the performance of the large experiment. Eventually, the collider will smash two beams of particles into each other in an attempt to detect elementary particles not present since the Big Bang and gain insight into the nature of gravity.
The hackers targeted a server hosting the portal for the science team responsible for the Compact Muon Solenoid Experiment (CMS) at CERN. The organization's press office did not immediately return an e-mailed request for comment.
UPDATE: Two readers who have translated the Greek Web site have disagreed with the newspaper reports of the incident. The defaced Web page does not belittle the LHC's security, but appears to make fun of other hackers in the Greek Internet underground scene, the readers maintain. More can be found on this security researcher's blog.
In light of the biggest identity theft case ever prosecuted in America, the spotlight is being turned on just how secure is our credit and debit card information?
Mr. Tabeling was interviewed by the BBC for his thoughts.
Unless something of significant interest occurs, this will be my last post on the DNS flaw that everyone has been talking about for the past several weeks.
Before I leave the subject I'd like to throw out two valuable links.
1) Determine if your ISP has installed the proper patches - http://www.doxpara.com/ (click the "Check My DNS" button)
2) IntoDNS - http://www.intodns.com This site provides a very nice snapshot of your ISP's DNS configuration. Just enter your domain name and click on the report tab.
An RSA survey found the e-mail-borne malware and phishing that affected 69% of respondents' companies, may not have led to serious consequences in every instance.
More than 89% of security incidents went unreported in 2007, according to survey of about 300 attendees at this year's RSA Conference.
Security incidents, as defined by the study, represent "an unexpected activity that brought sudden risk to the organization and took one or more security personnel to address."
Some of the security incidents, such as the e-mail-borne malware and phishing that affected 69% of respondents' companies, may not have led to serious consequences in every instance. But 29% of those answering the survey said their organizations experienced customer or employee data leakage. Twenty-eight percent reported insider threats or theft and 16% reported intellectual property theft.
"With 29% of respondents stating that they experienced the leakage of employee or customer data in 2007, it is alarming to see that only 11% of those types of incidents went reported," said Tim Mather, chief security strategist for RSA Conference, in a statement. "Security professionals need to remain cognizant of the regulations that their organizations must comply with and ensure they are taking steps to properly report the security incidents that are required by law -- whatever they may be."
Such findings echo a recent a study of over 500 data breach forensic investigations conducted by Verizon Business Security Solutions. According to Bryan Sartin, VP of investigative response at Verizon, the publicly reported breaches are "just the tip of iceberg." He said that less than 5% of the more than 500 cases covered in the Verizon study involved some form of disclosure.
In short, companies appear to be far more insecure than they acknowledge. The RSA survey indicates that 46% of companies experienced no security incidents in 2007, 19% experienced 1 to 2, 14% experienced 3 to 5, 7% experienced 6 to 10, 3% experienced 11 to 20, and 13% experienced more than 20 security incidents.
The top security challenge, according to respondents, is lost or stolen devices (49%), followed by non-malicious employee error and employee education (tied at 47%), budgetary constraints (44%), external hacking threats (38%), executive buy-in (26%), and malicious insider threats (22%).
On July 8th, Dan Kaminsky of IOActive announced a major DNS “vulnerability” in conjunction with a number of major DNS vendors. The announcement was off the charts in fanfare and attention, but what was the real impact on risk?
First, it is worth noting that this “bug” is more properly classified as a new attack technique invented by Dan. It combines two vulnerabilities that have been well-known for some time – the ability to guess non-random transaction IDs and the use of Additional RRs to insert new entries into the DNS cache. A fix against either of these vulnerabilities also negates the attack itself.
The fundamental question that determines the risk impact revolves around whether it is reasonable to expect fewer or more incidents that use this technique when comparing the period prior to disclosure -- or, more properly, before the date of Dan’s invention of the technique (this also assumes prior art) – with the period after invention/disclosure and into the future. If the disclosure reduces the number of those incidents, then risk is reduced; if the disclosure increases the number of those incidents, then risk is increased.
With that litmus test as our guideline, it is useful to break down the functional elements of risk and look at the impact on threats, vulnerabilities, and consequences (we will cover consequences, then vulnerabilities, and finally threat).
Consequences Though the consequences are the same before and after disclosure, it is worth discussing the impact here, given that the implication was that the “entire web” could be taken down. The nature of the attack requires the following:
An attacker must convince/trick a user into making a DNS request for a domain that doesn’t already exist in their DNS server’s cache. The expectation here is that s/he can be easily tricked into doing this.
Then, the attacker must simultaneously attack the DNS server by guessing the transaction ID. According to Kaminsky, the request/attack phase can be done reliably in about 10 seconds.
The attack is DNS server-specific. Only users on the same DNS server are affected.
Propagation: once the cache is poisoned, anyone requesting that domain will be routed to a malicious server.
Without combining this attack with other attack techniques, there can be three results:
Spoofing of a single website for multiple, perhaps many, users using the same DNS server. Presumably, this would be followed by more traditional phishing and malware attacks.
Denial-of-service by rerouting traffic from a legitimate site thereby taking potential customers or “eyeballs” away.
Denial-of-service be rerouting traffic from a legitimate high volume site to a legitimate low-volume site thereby overloading the servers on the low-volume site.
Because of the point-to-point (user-to-website) nature of the attack, to do something that constitutes “taking over the entire web” is infeasible by a longshot.
The bottom line analysis for the effect on risk due to a change in consequences from pre-invention to post-invention: no change, and therefore no impact.
Vulnerabilities These vulnerabilities have existed for years, and there have been workarounds for years. Along with this announcement, new patches were introduced in all major DNS server solutions. It is reasonable to assume that many DNS server implementations have been patched, though public accounts have suggested that number is in the 66%-75% range.
Bottom line analysis: the vulnerability level has been reduced, probably significantly, and the affect is positive for risk reduction. If 100% of DNS servers were patched, then overall risk would be reduced for this attack (assuming that there were actual attacks using this technique in the past.)
Threats The real question regarding risk impact comes in the arena of the less-controllable manipulation of threat. The general threat equation revolves around an attacker’s willingness to attack, based on his/her own cost/benefit analysis that compares the cost to attack to the expected benefits, tempered by the potential for being caught and penalized.
Cost to attack – prior to disclosing the invention, there were likely few, if any attackers with “prior art” that mirrored this technique. It is anybody’s guess how many potential attackers might have figured it out eventually, but they would have had to come from the pool of folks with enough expertise to do so – I am going to guess 500,000 people.
After the disclosure, the hints provided in the press release, the podcast, the sorted stories, and the blog entries made it much easier to figure out. Let’s guess that 5 million people could execute the attack. With automated tools, that number goes up to 50 million.
These numbers are estimates that illustrate the nature of the exercise. You are welcome to fill in your own estimates and come to your own conclusions.
Bottom line analysis: a significant increase in threat and corresponding risk.
Net Effect The risk manager's challenge is to weigh the decrease in vulnerable systems compared with the corresponding increase in threat, within the context of number of incidents and anticipated future incidents. Given the sheer size differential, it is difficult to conceive of a situation where risk is not increased.
Sometimes it "feels" like someone is taking action for the greater good, when that action actually creates a negative impact for all. For example, it is common for people to believe that raising prices of scarce resources during times of trouble (e.g. gasoline in the hurricane Katrina aftermath) is unconscionable even though a majority of economists recognize that raising prices actually provides for the greater public good. Vulnerability discovery and disclosure, and attack inventions, might feel like the right thing to do, but the net result is almost always a negative impact.
Baltimore, MD (07-29-08) - IDP, LLC, a local Internet security consulting firm, has announced the release of its latest vulnerability assessment and penetration testing offering. Built with commercial, open source and custom developed software modules; this comprehensive enterprise offering is ideally suited for every business who wants to ensure there are no external or internal vulnerabilities in their networks that could be exploited by malicious attackers. Hackers and malicious insiders are an undeniable threat to your organization's network. They have sophisticated tools and backdoor programs at their disposal with which to steal information, perform unlawful or unauthorized activities, and cover their tracks. Security professionals charged with protecting their organizations can become overwhelmed in developing specialty applications to combat these threats. The unfortunate reality is that all networks are constantly being probed and scanned for "open doors", poorly configured perimeter and internal hosts, weak passwords and authentication, software bugs and application design flaws. "Every day businesses who believe they are not attractive targets or who think they are secure are spending untold amounts of money remediating previously unidentified vulnerabilities", says Jerry Tabeling, President of IDP. The investment to identify and correct problems before they are exploited is just a fraction of the monetary, good will and business losses an attacker can bring about. IDP is currently offering a no cost, no obligation consultation to assist businesses quantify their risk tolerance and develop an ROI for the company's stakeholders. For more information contact Jerry Tabeling or visit http://www.idpnow.net.
About IDP: IDP specializes in assisting businesses assess vulnerabilities in their networks, identify intrusions and implement remediation solutions to prevent intrusions in the future.
By Kim Zetter-Wired Blog NetworkJuly 22, 2008 | 8:49:55 PM
Dan Kaminsky is understandably swamped today, given the unexpected early release of information about the critical DNS flaw he discovered that potentially affects the security of every website on the internet.
But he found some time to speak with Threat Level about how he discovered the vulnerability that has system administrators scrambling to patch before an exploit -- which is expected to go public by the end of today -- is widely available.
Kaminsky discovered the bug by chance about six months ago, which he promptly disclosed to people in the DNS community. At the end of March, an emergency summit was convened at Microsoft's headquarters, gathering 16 people from around the world to discuss how to address the problem.
On July 8, Kaminsky held a press conference announcing a multi-vendor patch and urging DNS server owners to upgrade their software with the patch immediately. But he declined to disclose details of the bug until next month, when he plans to deliver a talk about the flaw at the Black Hat Hacker Conference. Until then, Kaminsky asked researchers not to speculate about the bug, to avoid giving hackers information that could help them exploit it.
Thirteen days after that press conference, however, the security firm Matasano inadvertently released details about the bug on a blog post that the company quickly removed, but has been re-posted elsewhere.
I spoke with Kaminsky about that disclosure, among other issues.
Threat Level: So how pissed off are you?
Dan Kaminsky: (Laughs) I am not the important part here. The important thing is that people patch.
I have to be blunt. The drama is fun and interesting and cool, but it's a distraction. (The important thing is that) it's a really bad bug that really impacts every website you use and your readers use. It impacts whether or not readers are even going to see the article you're about to write. Now I could get into a big fight with lots of people ... and that might happen at some point! But it's a distraction from right now, which is, you know, we did good. We got 13 days of a patch being out without the bug being public. That's unprecedented. I'm pretty proud of at least 13 days. I would have liked 30, but I got 13 ... But the circumstances of how it went public are not what's important today. There will be a time for that, just not now. What is important now is people need to patch.
TL: There were a lot of people who balked at patching because they didn't know the details of the bug.
DK: Well you know, there were people who said, 'Dan, I wish I could patch but I don't know the bug and I can't get the resources I need to patch it.' Well you know the bug now.
You know, Verizon Business has a blog entry where they say that the greatest short-term risk from patching DNS was from the patch itself, from changing such a core and essential element to their systems. I know this. I was a network engineer before I was a security engineer. So that's why we took such extraordinary lengths to try to get people as much time as possible (to patch their systems). There's just a lot of complexity in doing something on this scale. This is something I think a lot of people don’t realize. It was difficult to get the patches even written, let alone get them all released on a single day.
But let me tell you, the complete lack of whining from the (DNS software) vendors ... if I could have gotten as little whining from the security (professionals) ... no I'm not going to say that. It's so tempting! I'm simply going to say this in positive terms. I wish everybody could be as cooperative and understanding and as helpful as Microsoft and ISC (the Internet Systems Consortium) and Cisco and everyone else was who worked so hard to get customers what they needed to protect our networks.
TL: How did you come across the bug? You said in the press conference on July 8 that you hadn't even been looking for this. So what were you doing when you found the bug?
DK: If you look at the history of my talks ... one year I had done some stuff on triangular routing. It's where you have multiple hosts that are all trying to host the same data and you want the fastest one to host it.
So I'm working at this, and I'm wondering if I can, like, use DNS races to figure out the fastest name servers to provide data. I started thinking about this trick I had done (before) with CNAMES -- they're an alias in DNS.
I realized I could look up a random name, and then whichever random name won would override the record for www.mywebsite.com. Essentially, I was looking for a faster way to host data on the internet and I remembered I have ways of overwriting which record the name server uses for 'www' by looking up something else and having it overwrite. And then I thought about that for a second. Wait, it's going to overwrite whatever is wwww.mywebsite.com! This kind of has security implications! Because if it works you can get around all of our DNS cache-poisoning protections. Then it worked!
I first tried it about six months ago. It took a couple of days to get working. I wrote it in Python to begin with and it was pretty slow. Then I rewrote it in C and it wasn’t slow anymore. It was a couple of seconds. That's when I realized I had a problem.+
TL: Then what did you do?
DK: I looked at it for a while, talked to a couple of really, really trusted people about it. Eventually I went to Paul Vixie (of ISC).
I've been ... looking at other issues with DNS for some time and I had already been working with Vixie on some of the fallout from last year's talk, when I was talking about DNS re-binding attacks. So I go to Paul and I say, Listen, we've got a bigger problem. And I send him the code and the packets and the details. And then there's that moment of, Yeah, we do have a problem.
Paul's an institution in the DNS realm and he basically goes ahead and contacts everybody and brings in Florian Weimer from Germany and brings in representatives from Cisco, Open DNS ... And we start talking on (an e-mail) thread for a couple of weeks about what the implications of this are. A couple of weeks in we realized we should probably have a summit and we should probably have it soon. So I asked Microsoft if they'd provide hosting and they absolutely agreed. On February 20 I had mailed Paul Vixie. And on March 31, 16 people from around the world were in Microsoft headquarters.
When I say there was no b.s. from the vendors, there was just no b.s. from the vendors. They got it. They understood they were in trouble. We skipped past the entire "Is it really a bug?" phase, that's still continuing in public (discussions).
TL: But you’ve got to understand why people said that. You acknowledged that in not disclosing the details, you opened yourself up to people being skeptical about the bug.
DK: People are allowed to be very, very skeptical. But, you know, don't be so skeptical that you're telling people to not patch.
This is a really bad bug. And for everyone who (says), Oh, I knew about this years ago . . . no, you didn't. Stop pretending you did. Because every time you say it, another network doesn't patch (their system).
This (attack takes) ten seconds to hijack the net. . . . Unless you like other people reading your e-mail, go patch. If you want to actually see Google and Yahoo and MySpace and Facebook and the entire web, if you actually want to see the correct web sites, go patch. The debate about whether this bug is new or old is ultimately useless. In ten seconds, the ISP DNS servers are taken over.
TL: It was kind of pie-in-the-sky to think that everyone was going to sit on their hands for 30 days and not post information about what they thought the bug was wasn't it?
DK: You know, a lot of people did. The guys who were actually smart enough to find the bug (didn't disclose it). The people who have been complaining have been people who couldn’t figure it out.
The people who could figure it out e-mailed me privately. And that says a lot. . . . The people who were good enough to figure out the bug by themselves I am incredibly gracious and appreciative of them for mailing me and helping me get the thirteen days that I got.
TL: How quickly did you get the first response from someone who discovered what the bug was?
DK: It was a couple of days.
TL: How far along are people in patching the DNS servers? Do you know how many have been patched?
DK: Way more than I ever would have hoped, (but) less than I would have liked. We were in the high double digits (in terms of percentages). We were getting some pretty good pickup on this patch. The last time I looked at people who were testing against my site it was somewhere in 30 to 40 percent . . . people who were going to my site to test their name servers.
There are a couple million name servers on the internet. There are many million more that are not physically on the internet but are behind firewalls. Ultimately any name server that is not patched is vulnerable and will probably eventually be attacked. The attack is just too good and too easy. My grandma's going to be in the audience (at Black Hat). My grandma's going to understand the bug.
I saw an interesting article this morning by Steve Bigelow from searchsecuritychannel.com. Although his article is entitled Security Risk Analysis Basics for Solution Providers, it does a good job articulating why it is important for the client to understand the reality of threats, both from inside and outside the organization.
Steve does a good job pointing out the differences between a risk and a threat, and why they need to be evaluated independently in the context of a company's overall security strategy.
The first and last paragraphs really say it all - "No matter how much effort and resources go into securing IT infrastructures, businesses still face a wide range of risks as a result of threats and vulnerabilities like configuration errors, intrusions, viruses and even employees themselves. Corporations are rarely skilled or objective enough to perform thorough evaluations of their own security strategies, so solution providers can step in to perform a security risk analysis -- a detailed investigation that examines every aspect of the client's security posture, identifying weaknesses and recommending corrective actions."
"Security risk analyses are rarely one-time endeavors. The results of periodic analysis can often be used as waypoints that help an organization maintain a proper security posture in the face of changing threats, technologies and corporate cultures......."
Vulnerability assessments have never been more important!
Did you know that malicious attackers are selling your digital assets to the highest bidder?
Whether it's a customer list, a pricing matrix, harvested email addresses, credit card numbers, social security numbers, passwords or confidential strategic plans, your digital assets are being offered to the highest bidder on black market online auctions. What's more, most of the time you are not even aware the information has been compromised.
Security firm Symantec Corp. reports a significant rise in the amount of data theft and data loss to the online black market. Dean Turner, director of Symantec's Global Intelligence Network, says, "If I had to guess, I'd say the losses could reach multimillions, if not billions, of dollars worldwide."
Steve Sakamoto-Wengel, the Maryland attorney general's consumer protection counsel for regulation, legislation and policy, agreed and said, "Remember the TJX Companies data breach last year? That was 47 million credit card numbers, maybe more, obtained by hackers just for those purposes."
"A lot of these chat rooms and Web sites are international, based in other countries," Sakamoto-Wengel said. "It's hard to track who is behind them."
Businesses need to continue to invest in digital security. Executives who say "it won't happen to me" or "who would want our information" are doing a disservice to their stakeholders.
Understanding where the "open doors" are and what vulnerabilities exist in your systems are the first steps in keeping malicious attackers at bay. Arms-length vulnerability assessments by certified security professionals should be a line item in every IT budget. Don't be penny wise and pound foolish!
DNSstuff has released a new tool to help organizations detect if their DNS servers are vulnerable to the DNS protocol flaw revealed last week.
DNSstuff.com is offering a free tool for organizations looking to test the susceptibility of their domain name servers to a fundamental flaw in the Domain Name System protocol revealed publicly last week.
A provider of on-demand DNS and network analysis tools, DNSstuff made the freeware, which company officials have dubbed DNS Vulnerability Check, available on its site Wednesday. The tool is meant to test for the vulnerability reported by Dan Kaminsky, director of penetration testing for IOActive.
You go to a coffee shop for a cup of coffee and to utilize the shop’s Wi-Fi HotSpot to surf the web. You connect to the hotspot network and decide to perform some online banking or to purchase something online. By the way, this could happen to you at home, as well. As an end-user, you feel quite secure, as you see the lock in the bottom corner of your Internet browser, symbolizing that the online banking or online credit card transaction is safe from prying eyes. Your data, including username, password, credit card info, etc. will be encrypted with 128-bit encryption. So it's secure, right?
It is not uncommon to perform banking and to purchase products online with your credit card. It is also a common thought that doing so is secure, as this is done via SSL. For the most part, this is true and the sessions are secure. Discover Card, for example, posts the following statement on their website:
Figure 1
The problem is that it is not “virtually impossible” for someone else to see your data, such as login information or credit card numbers. It can actually be relatively easy, as you’ll see, if you as an end-user are not knowledgeable about how you can be exploited and know the signs that this is occurring.
Figure 2 (Indicates a Secure SSL Session)
Continuing with the scenario, what you didn’t realize is that a hacker has intercepted your Online Banking login credentials and credit card information and can now log into your Online Banking Website or purchase items with your credit card. How is this possible, since SSL was used and is hard to break? The answer is that you made a fatal mistake that subjected you to an SSL Man-in-the-Middle (MITM) attack.
The Attack
The fatal flaw that enabled the sensitive information to be stolen is possible when an end-user is not properly educated on an easy to do and well-known SSL exploit – SSL MITM.
Here’s how it’s done:
The hacker goes to coffee shop and connects to the same Wi-Fi network you are connected to. He runs a series of utilities to redirect other user’s data through his machine. He runs a number of other utilities to sniff the data, act as an SSL Certificate Server and to be the Man-the-Middle. The following diagram shows a very simplified graphic of how your SSL Banking session should work under normal conditions, then how it would work during an attack:
Figure 3
Figure 4
An important concept to grasp here is that a certificate is used to establish the secure SSL connection. This is a good thing, if you have a good certificate and are connecting directly to the website to which you intended to use. Then all your data is encrypted from your browser to the SSL website where the bank’s website will use the information from the certificate it gave you to decrypt your data/credentials. If that is truly the case, then it is pretty darn hard for a hacker to decrypt the data/credentials being transmitted, even if he is able to sniff your data.
This is a bad thing if you have a “Fake” certificate being sent from the hacker, and you are actually connecting to his machine, not directly to the bank’s website. In this case, your credentials are being transmitted between your browser and the hacker’s machine. The hacker is able to grab that traffic, and, because he gave you the certificate to encrypt the data/credentials, he can use that same certificate to decrypt your data/credentials.
Here are the exact steps a hacker could use to perform this attack:
The first thing he would do is turn on Fragrouter, so that his machine can perform IP forwarding
Figure 5
After that, he’ll want to direct your Wi-Fi network traffic to his machine instead of your data traffic going directly to the Internet. This enables him to be the “Man-in-the-Middle” between your machine and the Internet. Using Arpspoof, a real easy way to do this, he determines your IP address is 192.168.1.15 and the Default Gateway of the Wi-Fi network is 192.168.1.1:
Figure 6
The next step is to enable DNS Spoofing via DNSSpoof:
Figure 7
Since he will be replacing the Bank's or Online Store’s valid certificate with his own fake one, he will need to turn on the utility to enable his system to be the Man-in-the-Middle for web sessions and to handle certificates. This is done via webmitm:
Figure 8
At this point, he is setup and ready to go, he now needs to begin actively sniffing your data passing through his machine including your login information and credit card info. He opts to do this with Ethereal, then saves his capture:
Figure 9
He now has the data, but it is still encrypted with 128-bit SSL. No problem, since he has the key. What he simply needs to do now is decrypt the data using the certificate that he gave you. He does this with SSL Dump:
Figure 10
The data is now decrypted and he runs a Cat command to view the now decrypted SSL information. Note that the username is “Bankusername” and the password is “BankPassword”. Conveniently, this dump also shows that the Banking site as National City. FYI, the better, more secure banking and online store websites will have you first connect to another, preceeding page via SSL, prior to connecting to the page where you enter the sensitive information such as bank login credentials or credit card numbers. The reason for this is to stop the MITM-type attack. How this helps is that if you were to access this preceeding page first with a "fake" certificate and then proceeded to the next page where you were to enter the sensitve information, that page where you would enter the sensitive information would not display. That is because the page gathering the sensitive information would be expecting a valid certificate, which it would not receive because of the Man-in-the-Middle. While some online banks and stores do implement this extra step/page for security reasons, the real flaw in this attack is the uneducated end-user, as you'll soon see:
Figure 11
With this information, he can now log into your Online Banking Account with the same access and privileges as you. He could transfer money, view account data, etc.
Below is an example of a sniffed SSL credit card purchase/transaction. You can see that Elvis Presley was attempting to make a purchase with his credit card 5440123412341234 with an expiration date of 5/06 and the billing address of Graceland in Memphis, TN (He is alive!). If this was your information, the hacker could easily make online purchases with your card.
Figure 12
Also Real Bad News for SSL VPN Admins
This type of attack could be particularly bad for corporations. The reason for this is that Corporate SSL VPN solutions are also vulnerable to this type of attack. Corporate SSL VPN solutions will often authenticate against Active Directory, the NT Domain, LDAP or some other centralized credentials data store. Sniffing the SSL VPN login then gives an attacker valid credentials to the corporate network and other systems.
What an End-User Needs To Know
There’s a big step and end-user can take to prevent this from taking place. When the MITM Hacker uses the “bad” certificate instead of the “good”, valid certificate, the end-user is actually alerted to this. The problem is that most end-users don’t understand what this means and will unknowingly agree to use the fake certificate. Below is an example of the Security Alert an end-user would receive. Most uneducated end-users would simply click “Yes”… and this is the fatal flaw:
Figure 13
By clicking “Yes”, they have set themselves up to be hacked. By clicking the “View Certificate” button, the end-user would easily see that there is a problem. Below are examples of the various certificate views/tabs that show a good certificate compared to the bad certificate:
Figure 14 (Good Certificate) (Bad Certificate)
Figure 15 (Good Certificate) (Bad Certificate)
Figure 16 (Good Certificate) (Bad Certificate)
How an End-User Can Prevent This
Again, the simple act of viewing the certificate and clicking “No” would have prevented this from happening.
Education is the key for an end-user. If you see this message, take the time to view the certificate. As you can see from the examples above, you can tell when something doesn’t look right. If you can’t tell, err on the side of caution and call your Online Bank or the Online store.
Take the time to read and understand all security messages you receive. Don’t just randomly click yes out of convenience.
How a Corporation Can Prevent This
Educate the end-user on the Security Alert and how to react to it.
Utilize One Time Passwords, such as RSA Tokens, to prevent the reuse of sniffed credentials.
When using SSL VPN, utilize mature products with advanced features, such as Juniper’s Secure Application Manager or Network Connect functionality.
Conclusion
This type of attack is relatively easy to do in a public Wi-Fi hotspot environment. It could also easily happen on a home Wi-Fi network, if that Wi-Fi network isn’t properly configured and allows a hacker to connect to that home network. An educated end-user and sound security practices by corporations can protect your valuable data.
"In general, cross-site scripting refers to that hacking technique that leverages vulnerabilities in the code of a web application to allow an attacker to send malicious content from an end-user and collect some type of data from the victim." (acunetix.com).
"Websites today are more complex than ever, containing a lot of dynamic content making the experience for the user more enjoyable. Dynamic content is achieved through the use of web applications which can deliver different output to a user depending on their settings and needs. Dynamic websites suffer from a threat that static websites don't, called "Cross Site Scripting" (or XSS dubbed by other security professionals)." (cgisecurity.com)
Cross site scripting holes have been found in many well known websites including FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, Zdnet, Wired, and Newsbytes.
"A web page contains both text and HTML markup that is generated by the server and interpreted by the client browser. Web sites that generate only static pages are able to have full control over how the browser interprets these pages. Web sites that generate dynamic pages do not have complete control over how their outputs are interpreted by the client. The heart of the issue is that if mistrusted content can be introduced into a dynamic page, neither the web site nor the client has enough information to recognize that this has happened and take protective actions." (CERT Coordination Center).
"Cross Site Scripting allows an attacker to embed malicious JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable dynamic page to fool the user, executing the script on his machine in order to gather data. The use of XSS might compromise private information, manipulate or steal cookies, create requests that can be mistaken for those of a valid user, or execute malicious code on the end-user systems. The data is usually formatted as a hyperlink containing malicious content and which is distributed over any possible means on the internet. " (acunetix.com).
As a software developer the way to protect against XSS is simple - never trust user input and always filter metacharacters. This will eliminate the majority of XSS attacks. For example, converting (ignore the brackets - they are just here for formatting purposes) [<] to [<] and [>] to [>] is suggested when it comes to script output, as is translating [(] to [)] and [)] to [)], ["] to ["], ['] to ['], [#] to [#] and [&] to [&]. Even after making these sort of changes, it is best to always have an independent third party scan your website for XSS vulnerabilities.
From the user's perspective only follow links from websites you trust. As an example and although somewhat cumbersome, if you visit a website and it links to CNN, instead of clicking on that link, go directly to CNN's main site and use its search engine to find the content. This will probably eliminate ninety percent of the problem.
Another way to protect yourself is to turn off Javascript in your browser settings and in IE adjust your security settings to high to prevent cookie theft. This may impede navigation in some websites, but it will make web surfing safer.
Lastly, don't be fooled by websites that use SSL (https). You are no more protected than websites that are not encrypted, because the web applications work the same way in either case.
OBERURSEL, Germany--(BUSINESS WIRE)-- “During the past few months, specialists from the n.runs AG, along with other security experts, have discovered approximately 800 vulnerabilities in anti-virus products.
The conclusion: contrary to their actual function, the products open the door to attackers, enable them to penetrate company networks and infect them with destructive code. The positioning of anti-virus software in central areas of the company now poses an accordingly high security risk.
The tests performed by the consulting company and solutions developer n.runs have indicated that every virus scanner currently on the market immediately revealed up to several highly critical vulnerabilities. These then pave the way for Denial of Service (DoS) attacks and enable the infiltration of destructive code – past the security solution into the network. With that, anti-virus solutions actually allow the very thing they should instead prevent.”
AV-Vulnerabilities Q1/2008 - Source : University of Michigan
Yesterday, Dan Kaminsky, a security researcher disclosed a fundamental flaw with the Domain Name System (DNS), the mechanism that translates URLs into IP addresses and visa versa. This flaw makes it possible to guess values in advance and assert a malicious server as the authoritative DNS server for a any site, including bank and e-commerce sites.
Dan Kaminsky, director of penetration testing services for IO Active, found the DNS flaw earlier this year. Dan proactively worked with the affected parties prior to his public announcement. Although he did not disclose any technical details, he said, "the severity is shown by the number of people who've gotten onboard with this patch."
Back in March, Kaminsky said 16 researchers gathered at Microsoft to see whether they understood what was going on, as well as what would be a fix to affect the greatest number of people worldwide, and when they would issue this fix.
In a unified response to address the flaw, Kaminsky said the researchers all decided to conduct a synchronized, multivendor release. Accordingly, Microsoft in its July Patch Tuesday released MS08-037. Cisco Systems, Sun Microsystems, and BIND were expected to roll out patches on Tuesday as well.
The coordinated release covers a wide variety of vendors with DNS servers and DNS clients. Not all of the DNS client vendors have announced patches. Most systems will be patched automatically. Those that require a manual patch will have 30 days to patch their systems before additional details are made public.
This issue also affects Internet service providers used by home users, but hardware routers used by home users should not be affected.
Kaminsky intends to release details before Black Hat 2008, on August 7 and 8 in Las Vegas.
Not a day goes by without a new revelation of how malicious attackers can compromise your systems. Although this most recent security alert is far reaching and could potentially affect huge numbers of users, there are hundreds of other known vulnerabilities lurking in business systems. This is just more reinforcement to invest in ongoing vulnerability assessments.
To check to see if your system is vulnerable, Kaminsky has provided a DNS checker
Question: What is the course for the budget-strapped executive, who assumes that the current security systems are good enough, robust enough, and up-to-date enough to stop the next wave? How does he prove due diligence, and assure all stakeholders that their confidence in the systems under his control is well placed? A difficult, costly and often intimidating process!
Answer: Clearly, the only solution is to monitor and assess the exact vulnerability state of every component of the infrastructure constantly and consistently. Outsourced security operations will offer many advantages and excellent services in this regard, which can greatly enhance the overall security level of the enterprise. Costs, however, are often difficult to justify in real terms, and for most security spends a true ROI is difficult.
Where the risks are clear, the solution is often seen as a necessary evil rather than an investment, but where vulnerability assessments are concerned, determining an accurate ROI can be a highly involved process, and is practically impossible to achieve in isolation.
The real return on investment for vulnerability assessment technology and technical audit services cannot be determined simply as a factor of risk mitigation, but MUST also incorporate the improvement effect that these systems have on ROI calculations for more specific security architecture, such as firewalls, IDS, biometrics and the like. To illustrate this concept: the necessity of a firewall is clear for any Internet-connected concern, and its worth can be clearly demonstrated in pure risk mitigation and network protection terms. The continual stringent maintenance and accurate configuration of that firewall, however, directly impacts its effectiveness and therefore its worth, and hence ROI.
Regular assessment of its configuration, and timeliness of patching newly discovered problems, maintains or increases the effectiveness, and therefore the worth of that firewall. True ROI calculations for vulnerability assessment must include the real threat that a compromise of these assets poses to the security of other, linked and/or underlying systems, data, and processes. Assumptions:
The value of information is often considered to be at least as important as the value of a company's physical assets.
Protecting the confidentiality, integrity, accuracy and accessibility of company information is important to a firm's ability to function in today's business environment.
A breach of a company's information systems could result in the disclosure not only of its information, but also its trading partners' sensitive data.
Biggest threat is unauthorized users - including insiders, hackers, corporate raiders / intelligence gathering companies (they use and sell this information to other companies), professional criminals.
Most E&O, liability, business continuation and property insurance policies require a proactive security policy - and vulnerability assessments go a long way in satisfying that requirement
Statistically, the average percentage of a firm's information technology budget that is spent on information security is between 1-2% of average revenues
Three drivers in decision to proceed: What is the loss resulting from a breach occurring?
Downtime
Compromised / damaged / stolen data
Monetary cost
Legal costs
Costs related to loss of system / data availability
Lost business
Internal / external services to correct / remediate situation
Costs related to loss of information integrity / confidentiality
What is the probability of a threat occurring?
Challenge, status or thrill
Every day, your network is being scanned and probed by a variety of automated tools and people seeking nothing more than "breaking in". This occurs whether you know it or not - guaranteed, so the threat is indeed real - it's happening today.
Most first time exploits go undetected. You usually don't know about it until it is too late and the damage has been done.
Damage to electronic assets, data, reputation or ability to conduct business.
Can occur purposefully, by accident or by random "luck of the draw"
Loss of customer trust
Ability to win future business
What is the / probability that that a threat would be successful?
Probability of an asset being compromised can be estimated based on the availability and ease of performing the exploit and the attractiveness of the target.
This probability of compromise is then combined with the possible loss or cost resulting from a security breach to determine a risk value for the asset.
Until an assessment is performed you don't know how available or easy it is for a vulnerability to be identified and exploited.
What you don't know, CAN hurt you.
Unknown vulnerabilities make a target very attractive and without regard to the company or what it does, once vulnerabilities are identified they are posted on various Internet sites for all to see - and take advantage of.
Firewalls are not enough.
Your investment is small relative to the cost of a vulnerability being exploited!
Large businesses have long known that they are targets for malicious attackers and have taken proactive steps to prevent intrusions.
A common misperception among small businesses(*) is that they are safe from attack. Statements like “who would want to attack us” or “we don’t store information anyone would be interested in” are often what the owners and managers of small businesses think to themselves when it comes to Internet security. They assume they are safe because “we have a firewall in place and our IT guys said we were ok”. Nothing could be further from the truth.
The reality is that random IP scans go on all day long with the attackers looking for nothing more than an easy target. Aside from purposeful, targeted attacks perpetrated by criminals, random trolling for unsuspecting targets make up the greatest percentage of attacks. It’s not so much that businesses fail to take Internet security seriously, but that they don’t really have a handle on where their vulnerabilities lie. Additionally, IT staff (if there is one) are too busy putting out the daily fires to really take the time to fully understand and appreciate where they are vulnerable.
The solution is simple. Engage a qualified, certified third party to conduct a vulnerability assessment and penetration test. Using a combination of open source, commercial and self-developed tools, these security professionals will assess your environment and make specific recommendations to “close the doors” and ultimately provide a disincentive for malicious attackers from choosing you as a target.
Technology entrepreneur with over 35 years of leadership and business development experience.
Founded IDP in 2006. IDP (Intrusion, Detection & Prevention) is a Maryland-based cybersecurity consulting firm that assists businesses defend against cyber attacks and protect their digital assets.
Posts
