Passwords are like Pants... a Creative Commons Attribution, Noncommercial, No Derivative Works image from Richard Parmiter's Flickr fotostream

One of the DefCon contests that most sparked my imagination was the “Crack me if you can” password cracking contest, organized by KoreLogic. The goal of the contest is to crack as many of the password hashes provided as possible. The rules of the contest allow the use of off-site and on-site computer equipment of any kind, but in order to be eligible for any prize money at least one team member had to be physically present at the DefCon conference.

The competition is interesting in more than one way. First of all the contest is educational in setup. Even though the amount of computer power a team can come up with is important in getting to good results, it is not the determining factor in winning or losing the contest. Key to winning or doing well in the contest was understanding human behavior. KoreLogic generated a set of passwords they feel is representative of what they actually encounter in the field. Most corporate environments rely on a common set of rules that are used to enforce user to pick “strong” passwords and force them to change them regularly. While the goal of the rules is actually commendable, KoreLogic’s experience learns them that the human behavior triggered by these rules cause passwords to be very predictable. “If you force employees to change their passwords four times a year, they will select something that naturally changes four times in most cities (except Las Vegas)”, typical passwords we find are things like Winter2010. Once you understand this pattern, you can actually reliably predict what this password will in say 9 months or a year. Teams that actually saw this pattern and used it to make smarter password guesses did better in the competition.

The key to making hard to guess passwords is to break with this predicable behavior. If people have to put a special character in their passwords they usually put them in the beginning or at the end of their password, e.g. Summer1969! We had a number of passwords that actually had a password in the middle of it and these passwords where significantly harder to crack.

There is a significant difference between the success rates of cracking certain password hashes. E.g. windows password hashes have proven at be extremely easy to crack. All the teams together cracked 94% of all the windows password hashes provided to them. These contain some LM hashes, but mostly NTLM and NTLM2 hashes. A stupid 20 character long Windows administrator password (2345678901234567890) was guessed by all teams, even though there are no rainbow tables available for passwords of this length . Operating systems like FreeBSD do much better, less than ten of these hashes where cracked and BCrypt hashes achieved an even better success rate, only a few hashes where cracked. Absolute winner where the Oracle password hashes, none of these where cracked.

While this was a serious competition and the first prize of $600 was won by team HashCat, the competition was mostly educational in its setup. Only teams that published their methods for cracking are eligible to win and all results and methods used will be published online later this week (@@@@). The contestants used an interesting array of computer equipment. Graphics Cards based systems, clustered Amazon EC2 instances and a university super computer cluster with 1TB of memory where all used as well as plain simple desktop computers.
Hopefully this competition will not only learn us how to better crack passwords, but also how to pick better passwords and thus make us all a little bit more secure.

GLOBAL BATTLE - KIDS TO SAVE THE WORLD SERIES (Explore #4) a CC, non-commercial, no derived works image from JOHN CORVERA's flickr photostream

This talk is a follow up of Felix’ talk at Black Hat Europe which I blogged about earlier here (http://www.cupfighter.net/index.php/2010/04/blackhateu-fx/) marking the release of the tool BlitzAbleiter.

One of the new point highlighted is that his work is not just of interest to normal users that are running flash content, but also to corporations that serve pre-compiled flash advertisements that they do not want to be infected with malware or other unwanted behaviour.
For the release of Blitzableiter Felix has chosen to integrate with NoScript. If you have the latest version of NoScript, you allready have BlitzAbleiter.
Next Felix actually demoed BlitzAbleiter by using it to stop some in the wild Flash exploits.

I managed to speak to Felix in a more informal setting later and he pointed out that there are two major differences between BlitzAbleiter as presented in Barcelona and the current version. BlitzAbleiter now support both the version 1 and version 2 Flash virtual machines. Besides that the code quality of the tool is now at such a level that it is actually a usable tool that can be released to the public.

The name BlitzAbleiter is the German word for lightning rod, because it has the potential to turn harfull Flash into harmless tunder.

Delchi’s talk evolves around an imaginary assignment to design the physical security system of a high security facility with CCTV, and the methodology how to handle this assignment.

If you want to design such a system you need to follow the steps of:

• Assessment – What do we secure? What is the status? What are the risks?
• Assignment – Which area gets which security? Prioritize. What external requirement do you have?
• Arrangement – Find the most effective locations for you security devices. Consider security and ergonomics.
• Approval – get quotes from multiple vendors. Consider lifetimes and service plans and take expansions into account. E.g. Will you require biometric in the future.
• Action – Lets implement it. Build, train and test.

Next Delchi encourages us keep failure into mind. Physical security systems will go wrong, building the systems will go wrong as well.

Delchi’s final section of the talk outlines the various problem security professions will encounter when dealing with various parties involved in the process. Management, vendors, people who know better, users and construction workers. With funny and concrete examples he shows what to expect and how to handle these groups.

Building access control systems are getting more and more IP enabled, but the IP enabled portions of access control systems are often poorly controlled and don’t get much love from either the it or facilities system.

But the vendors are not always helping the S2 security box e.g. Is using both a web server and a mysql version with lots of security vulnerabilities in it. The amount of security problems Shawn pointed out in various products was truly shocking.

Show continued to show us the results of the exploitation on a demo box he tested which just allowed him to open doors and get to camera feeds.

There is a worrying perception in the physical industry that hackers will not go after these systems, but after financial data and trade secrets, but this is not correct, it is very interesting flr attacks to actually attack the physical security infrastructure. There are some perceptions that these device are deep in the network and not connected to the internet, but a simple Google hack showed that there are 350+ devices connected to the internet today.

Vendors has start to offer better security and this will only happen if customers start to demand better security.

The Room was packed and warning poster where all over the place warning people that cell phone traffic may be intercepted in the area around the talk. Expectations are high at the start of the talk and we were about to find out if they are to be met.

In this presentation Chris is going to intercept cell phone calls, specifically GSM calls. For this purpose he uses what he calls an IMSI catcher. Critical for intercepting calls is the IMSI, the International Mobile Subscriber Identity, think of this as the GSM username. Chris built his IMSI catcher for $1,500 out of open software and open hardware, a fraction of the millions charged for commercial IMSI catchers.

Because handsets always choose the strongest signal and a attacker will always win the battle for this. Since GSM assumes that the network is trusted, the base station dictates the settings, so if the base station wants to disable encryption, the phone will do that. The IMSI catcher does have to not break GSM encryption, it just acts as a base station and tell the phone to disable GSM encryption. In theory the phone could warn of this behaviours, but most sims have this disabled, because it would confuse users.

Because of difference in regulations between the USA and Europe there is a frequency in both spectrums that you can use that is in the HAM radio band and thus governed by the HAM radio regulations and these regulations give enough lead way to run GSM across it without needing a telco license. A HAM radio license allows the use of transmitting power of up to 1500W, a very small fraction of the 0.25W used by Chris during his demo.

In order to spoof a network you need some information: the mobile country code, the mobile network code and th enetwork name. All this information can be easily found on Wikipedia and after programming these values into the OpenBST the AT&T network could reliably be spoofed. Without spoofing the settings 30 handsets already associated themselves with the fake basestatiion. After spoofing the AT&T network over 45 handset associated with the fake base sation.

If no additional techniques are used, it may take a phone over an hour to hand over to the fake base station, but there some tricks to make them hand over faster.  Most of these techniques do not fit into the regulations for ham radio. E.g. Disrupting the base stations around us. A noise generator and a 100W signal amplifier could disrupt GSM traffic for most of Las Vegas and force cell phones to switch over to the HAM radio frequency. This would be highly illegal, but impossible to stop. You could also spoof and advertised neighbour cells but then you would have to transmit on a GSM reserved frequency. Chris therefore refrained from demonstrating these techniques.

Fake base stations don’t actually have to transmit a strong signal, the GSM standards allow a basestation to just tell the handset to treat its signal as if it is stronger then it actually is. Because the network is trusted in the GSM system, the cellphone has to comply. Unfortunatly this command is not supported in the OpenBTS.

Is there a solution to prevent these attacks for GMS 2G. GSM 2G is seriously broken. You can compare it to the telnet vs. ssh situation. “2G is telnet and 3G is ssh”.

Chris did not play back any of the captured calls live on stage in fear of legal consequences, but cell phone calls where captured life on stage.

In this talk Fyodor and David are giving an in depth overview of the nmap scripting engine. The Nmap scripting engine allow users to create and share scripts for all ip related tasks from vulnerability detection to exploitation.

There are a lot of NSE scripts already available for tasks like discovery, authentication tests, Denial of Service, Exploitation and lots of other stuff. All come with nmap by default, there are 131 NSE scripts bundled with Nmap at the moment.  There are two catagories the are of special interest; disruptive and safe and they mean exactly what you would expect them to do.  In 3.5 years the number of available nse scripts has grown from 20 to over 130.

In the next part of the presentation Fyodor shows an example of a scenario where NSE really enables a big assessment. Fyodor applied the scripts submitted by Ron Bowes around SMB vulnerabilities against Microsoft’s public IP space, a space of over 1,000,000 ip addresses. First step was a quick scan of over 1 million hosts to find interesting targets. Nmap is currently smart and fast enough to scan these ip addresses in about 26 hours.

In his scanning Fyodor found loads of printers and RDP servers openly exposed to the internet, but he was specifically looking for the ports related to SMB. Using NSE Fyodor ran a scan looking for SMB vulnerabilities.
Microsoft has machines that share their IPS$, C$ and D$ shares over the internet and in some cases allow full user enumeration.

NSE allows you to develop scripts yourself or adapt some of the scripts provided by insecure.org. NSE scripts use the language called LUA, which distribution fits comfortable on a floppy disk. “For the young people in the audience, this is a small storage technology”  Fyodor shows us the rpcinfo.nse script which is only 46 lines long and surprisingly readable.

Next up on the stage is David who is going to demonstrate how easy it is to write an NSE script that will look for a webcam located in his home in Denver. The script was not hard to write and within a couple of minutes the webcam was found. Another script was needed to brute force the username and password and we where able to look out of David’s window.

All in all a very interesting talk that show the huge potential of the Nmap scripting engine.

I walked into the social engineering contest just as the second contestant was ready to start his assignment. His target was a major US automotive company. During his session he was able to speak to two people.

It is very good to hear that at least the first guy they got on the line was actually not comfortable to answer the questions ask them by the contestant.

The second victim was a person that only worked with the company (a major automobile manufacturer) for 2 months as a security engineer. He was eased into answering mundain but valuable questions like his work and break times, but also about food service at the company etc.

At the end of the call the contestant knew:

• The subjects name and function
• His working hours
• His break hours
• Which desktop os was used and which XP service pack was used
• The brand and model of the desktop
• The brand of anti-virus and the exact version used
• The internet browser version installed
• The home page of the browser
• If dual factor authentication was used
• Mail client installed and which version of outlook was used
• If wireless was used in the company
• If url filtering was in use (no)
• If there is an internal IT support group
• Which internal phone system is in use
• Which pdf reader was used and the exact version number
• How waist paper is disposed of

It was really scary to know that one of the reasons the contestant was not able to obtain all information was because his victim did not no some of the details.

The next thing for the contestant to find out was somebody’s pay schedule. With only two minutes to complete that task it would be a very close call, unfortunately he could not get the right people on the line.

I know that our blog is not exactly the same as presenting at Defcon, but still you can view Damien Finol’s presentation “Cracking the Poor and the Rich” here.

Cracking the Poor and the Rich tells that tale of the economical contrast between the rich parts of Caracas and its Slums and how this impacts the inhabitants efforts towards wireless network security.

The presentation is entertaining and provides food for tough, especially if you live in a more prilileged country like I do.

http://hackerpublicradio.org/eps/hpr0420.mp3

This song quite captures the spirit of Defcon.

Update: Matt’s blog, Slide deck, Sebastien Raveau’s word list (1, 2)

There are basically two types of password cracking, Online by trying usernames and passwords directly in the login screen. This only gives you a few tries since the system and its countermeasures is still opertional.
Offline, by trying to match passwords against password hashes, mostly for forensic reasons.

Basic cracking process:
1.    Generate a lot of password guesses
2.    Generate hashes for these passwords
3.    Compare the hashes against the target hashes
4.    If you don’t have enough, redo from 1

Matt at first did most of his research work from home, not going into the lab, but after his first power bill arrived which was increased by 75% he used a 3 year old Dell in his lab.

If you want to investigate how human generate passwords, you have to have a list of user generated passwords, but where can you get them? (Un)fortunately hackers helped us out and there is such a list available.
The hacker who compromised Phpbb.com website published a list of 259k unsalted md5’s and 83k salted hashes. Because of time limitations, Matt only attacked the unsalted MD5 hashes. The hacker himself submitted 117k hashes to an online password cracker. 24% of the passwords were cracked (28,635).

He used an online cracker called hashkiller.com. They do a good job and track how efficient they are and how efficient other crackers are. There is also md5-utils which is a site that submits hashes to other sites as well. However if you are going to use such a system and think that the owners are not going to keep a copy of the found passwords you are too naïve to work in security.

There are also crackers you run on your own machine. The best one is John the ripper. It is free and open source. It is actively maintained and has an active community. If you can think of a problem that might occur, it is usually already covered in John the Ripper. As an added bonus John the Ripper take its password guesses from standard input.

Usign John the Ripper Matt was able to get the following results:
4 hours – 38% cracked.
1 week  – 62% cracked.
1 month and 1 week – 89% cracked.
Currently – 95% cracked.

Some quick password statistics:
Average length of a password: 7.2 characters long
Only 6% of the passwords contained an upper case character.
Only 1% of the passwords contained a special character.
51% of the passwords consist only of lower case letters.

So where are you going to take your passwords from? There are good word files out there. Large word lists are good if the system does not enforce any password policy.

Sabastien Raveau has created an excellent word list by getting all words from all Wikipedia and related projects articles. But you can also used John the Rippers generator which is based on linguistic probability.

If a system enforces password policies, you are better of with smaller more specific word lists preferably one which is based on previously cracked hashes. Unfortunately Matt cannot share his results due to privacy implications.

There are ways to speed up the brute force process, by using Probabilistic Cracking
Certain Words more often used, e.g. password, monkey and football are very common. Also certain mangling principles are more popular then others: appending 123, 007or  $$$, capitalizing the first character, replacing the o by 0, etc.

Matt program takes words and mangling rules and assigns a weight to them. Then it starts with the most likely combinations.

Matt then shows a demonstration which clearly shows that weak passwords get cracked first.

Matt strongly believes that forcing frequent password changes does more harm then good. Humans are clearly not good at generating truly random passwords and if you let them do it often you only decrease anthropy.

Matt also indicated that salting passwords (adding a random string to the password before hasing) greatly increases the amount of effort required to brute force password hashes. It means that every hash has to be tried with every salt. But, salting only works if multiple passwords are decoded, it does not make a single hash more secure.

While the speaker did not test windows, it is highly likely that these flaws exist in Windows as well.

Rsnake and Jabra demonstrated client site exploits that will defeat common proxy techniques such as classic HTTP proxies, CGI proxies, SOCKS proxies, and Tor.

The installation of client certificates also exposes users. If you decide to offer you certificate to a site, you basically identify yourself to that site. Client site certificates are good for normal use, but the cert will tell an evil server who we are. Also, certificate can be sniffed from the wire and they will thus also expose an identity.

There is a very well known attack against the Tor network; by setting up an evil Tor node, researches where able to obtain at least 100 embassy usernames and passwords. If you use a proxy you have to decide which proxy to trust.

RSnake demonstrated a new IE attack called smbenum. By using file:// urls from javascript he can enumerate files on the user computer. The attack is still limited, because the browser is only capable of reading certain files. Smbenum learns the computer’s name by using environment variables in the url, which will expand.

Theoretically the smbenum attack can obtain the username, by searching for well known pictures in the user directory (e.g. adobe installs certain pictures in the user directory), but this attack is brute force and incredibly slow. A slower attack called res timing can be used to get more granular details. Find the right directory with smbenum, find the right file with res timing.

Another concern is the safe browsing feature firefox and chrome. This function evaluates the sites you server, this means it does a call home. Rsnake tested and found that his browser did about 30 requests per hour. Since Google users a unique non exipering cookie for each computer all the data on where you have been is in Google’s datacenter. Even if Google’s “do no harm” hold true, there could be a situation where the can be force to give it up. Safe browsing can be turned off about:config

Google’s Chrome is even worse; “Chrome 0wns Us”. Chrome’s automatic updates happen about once every 5hours. Chrome send machineID and UserID in each update request, “this is a real concern”

Jabra finished with a new 0-day java based shell code that cannot be stopped by the browser yet.

When we talk about high security locks, what are we talking about? There are us standards for high security locks, but do they offer any value?

In order to know that, we have to look at what it is that makes a lock secure? There are three factors that determine this, it resistance against forced entry, it resistance agains covert entry, and key security. In.security.org has developed a rating based on the three T’s, Time, Tools and Training needed to compromise a lock.

When you look at the standers they cover a very limited set of attacks, e.g. the US standards do not cover cover dumping attacks.

In.security.org was able to successfully attack electromechanical locks because in the end they “are still mechanical locks”.

The attacks focused on the Clock system which is the most widely used implementation of Electromechanical locks, made by ASSA Abloy. It is e.g. used in the ASSA Cliq Solo system which was just released in Europe and will not be released in the USA because they where compromised.

Contrary to their advertisements (1, 2) here are real issues with Cliq system:
•    Simulation of keys
•    Lost or stolen cannot be deleted, but in stead put the entire system of a site at risk
•    Certain cylinders cannot be rekeyed
•    It is possible to simulate credentials
•    Or to totally bypass the electronic system
•    These attacks to not leave the promised audit trail

Toool, The Open Organisation Of Lockpickers has offered key vendors like ASSA Abloy their full research in exchange for locks and a promised that the fault found would be fixed, but this offer has turned down. Vendors will provide not locks for research, will not provided fixes and has “no interest” in the data.

They then showed a video where these locks where all compromised. One of the ways to prevent the creation of an audit trail is to block the interface of the electronics of the lock with the use of an “advanced attack”; putting a piece of paper between the lock and the key.

The most smashing demonstration was manually picking of one of these locks, something these locks are supposed to prevent.

As these locks contain fundamental security engineering flaws it is the believe of the speakers that the vendors should fix these issues and offer a full free replacement of all vulnerable locks installed. Unfortunately the  vendors have a different opinion.

The speaker noticed that the same malware turned up on two compromised sites he investigated, so it seemed that there should be a relationship between the two sites. Both sites called back to a url with hostname gwtsdjeni.com. The name schema of the site seems to indicate that this is a torpig site, with one single deviation; the url contained an extra d before the word jeni. So this seemed to be a modified version of the torpig network.

The researchers investigated the command and control website and stumbled on the file en.php which turned out to be the a copy of a PHP shell. This just about gave then all the possibilities to break into the site and start a full investigation. Unfortunately this is the time to start “Dances with lawyers”.

Investigating a site/server for which you do not have permission is tricky business. Having the PHP shell posted the question if law wave been broken? If not, can you continue? What can and what can’t you do? Are we allowed to go any further? Don’t hack, don’t guess, don’t do privilege escalation. Any information not protected could be used. Luckily enough a plain text list of accounts and passwords was on the system.

The system was packed with all kinds of “interesting stuff”:
•    Neosploit
•    Automated FTP iframe injection
•    PHPmyadmin
•    Truck full of Trojans
•    AWStats logs
•    Setup instructions
•    mail backend
•    /mc366 – filled with openVPN certificates
•    Huge list of CPanel credential
•    Some more utilities and exploits

Lets look at these in more detail.
FTP IFramer is an automated web server attacker. A logfile pointed out that it was used in breakin attempts for over 200k users. Also there where multiple result logs from users of the system indicating that the server was leased to at least three separate criminal groups.

Neosploit is THE “Rock Star” of crimeware toolkits.
v1 – Offered a very solid platform for exploitation. Single user.
v2 – Build on version 1. It has multiple user support, run like a software as a service  (SaaS) platform and has enhanced reporting
v3 – Full license model and enforcement, has ROI reporting on attach success and will only run through a very specific socks proxy.

The current Neosploit platform has a full featured installed that is nearly idiot proof. It auto updates and adapts to the demands of the criminal “market”. Attacks that have a low success rate get phased out while fresh, often 0-day attacks get pushed.

All in all you can see that malware is getting really advanced. There is a professional mature market for these types of programs.

The setup instruction found where in a word document. They contained very detailed and specific setup instructions. The document was in unfortunately in Russian and this is encountered very often. According the speaker you should “Always keep a Russian speaker handy in your research team”.

The research clearly yielded a lot of data, but what do you do with the data? The data was pushed to CERT-CC because of the international nature of the compromises. CERT-CC was highly responsive and very helpful. They took the task upon then to help notify infected people.

Some applications on the server where protected be means of an .htaccess file, this gave some real insight into the inner working of these criminal neworks. Using the IP addresses in the .htaccess files, the CERT was able to identify ties to criminal networks in DC, Newark, Denmark and Russia, a proof that H*Commerce really exists.

Cyber warefare does tie in as well. The FTP iFramer is also programmed to gather “other” interesting content like PDF’s, Word documents and Excel sheets. One of the screenshot found was of a map screen with positions of F16-Ds, Apaches and radio towers including a full log of their positions.

Did the research team get any closure?
Working with CERT was working well, it even registered on the Neosploit statistics on the server. Unformtunatly the results where only temporary, after they found out that a lot of hole where suddenly patched the cracked new credentials and moved on. In the end the business model was not broken so things turned back to normal pretty quitly.

Final words
What should we be looking for when we are looking for these networks? They mostly betray themselves by their communications.

We have learned that these programs are getting more and more advance, currently they are using “traditional” methods of communications like normal http calls, direct TCP connections and IRC, but what if these guys start (ab)using web 2.0 applications like blog sites, twitter, etc. Users will nota accept this.

If you have ever encountered a blog post that does not make sense at all? It looks like encrypted and encoded binary data? Well, that is probably just what it is.

Most vendors that refuse to address these issues all use the same argument: “If users do something stupid it their problem.” Well, if they do it in your context it is your problem. This is what the guys from securewebmail.com found out as well.

So where have we found CSRF issues?
McAfee has a site which you van use to scan your own site. With CSRF an attack could use your session to create an extra account and then use that account to scan your sites and get your vulnerabilities.
Wireless routers like the Linksys WRT wireless and others are vulnerable and  can be owned and opened up to outsider attacks.
ESPN, one of the largest coomunity websites in the world is vulnerable to a CSRF attack against itself. It is wormable without any javascript at all. Noscript will not help you…
Dokeos, an e0learning platform which is also used by the Belgian Defense Agency is also vulnerable. Given its installed base, Dokeos has Millions of users
The osCommerce platform used for thousands of online shops with more then 9,300,000+ users. CSRF can be used here to steal credit card data. Interestingly a lot of these sites are branded McAfee secure.
ZenCart is also vulnerable and widely used.
cPanel/WHM is used in over 7,000,000 sites and it is also vulnerable. cPanels responsed that the cannot fix it because “it is a feature.”

But CSRF has other implications as well. It can be used to e.g. forge a persons browser history, which obviously has legel implications. “People have been convicted based on their search history.”

Alternatively it can be used to polute peoples shopping cart history on e.g. Amazon. This might make valuable advertising

Myths in CSRF mitigation.

• Only work via POST requests – This doesn’t always work
• Referrer checking – Referrers get striped in SSL session, also users turn referrer checking of for privacy reasons.
• Multi-step transactions – Multi-step transactions can also be perfored with CSRF

What does work?

• CAPTCHA’s – If they are implemented the right way
• Re authentication – Requesting reauthentication before performing critical actions is a good mitigation action
• Unique request Tokens – make sure session tokens are cryptographically secure.

An interesting comment is that they where actually able to evade Snort detection by base64 encoding the attack.

Currently there are 9 privilege escalation exploits included in Metasploit, but they are a basis for further development.

The demonstration contained the following steps:

• TNSLIST -> Version enumeration of TNS Listener
• SIDENUM -> Enumeration of the SIDs, this failed because it was an Oracle version 10 box
• Burt force SID – Obtained the SID this way
• Account brute fore – To get an account
• Escalate to DBA – Get DBA privileges
• Add JAVASYS privilege
• Upload exploit
• Run it via WINEXEC
• Get a Shell prompt.

All in all a good overview of what stuff is available to the Oracle pentester in the Metasploit Framework.

Case 1: Casino club in Las vegas
The Casino club got exploited because of classic mistakes such a a lack of egress filtering and network separation. Network was owned. Malware included keyloggers, putty, smtp servers. Since it was installed on a PoS terminal it was able to steal creditcard data as most card readers actually plug into the keyboard interface. The keylogger was a customezed version of Perfect Keylogger 1.68 a commercially available key/screenlogger. It is noteworth that the keylogger was setup to only log key input of a certain process to save resources and avoid detection. It also took a screenshot every 15 minutes.

Keyloggers are used more and more on Point of Sale systems to capture creditcard data because the data is more and more protected (encrypted) from the PoS terminal on.

Case 2: Chain of Hotels in New York
Again, classic mistakes like lack of seggragation, lack of password, lack of patchingand no AV or Anti-Malware helped the compromised. On top of that the firewall was a consumer grade firewall which allowed in RDP in for their outsourcing provider.

Actual malware was memory dumping malware and had regular expressions of track1 and track 2 credit card data. As a security measure the malware stored the data in encrypted RAR file. By searching the memory the key for this RAR file was recovered. In order to prevent anti-malware, parts of the malware where compiled on the box.

Case 3: Video poker Lake Tahoe
The video poker machines at a Lake Tahoe casino got compromised and infected with mallware. Video poker machines are just embedded PC’s. unfortunately, embeded PC’s are often not updated in fear of breaking the system, they don’t have anti-virus and mostly don’t have classical defences like unique passwords etc.

Since these machines accept vouchers as means of payment, this mechnism was used to trigger the malware.

Various vouchers have various functions. Some of these certificates performed a single function, e.g. to shift the odds towards the player. These certificates are ment to be sold to individuals, while other vouchers will give multiple functions like set credits, etc.

Unformtunatly the demonstration was not with the actual malware, but with a mockup piece of malware.

Case 4: Restaurant in Michigan
The firewall was configured to allow VNC in, they used common/waek passwords, the PoS was not running anti-virus and had unrestricted internet acess.

The software installed a custom IRC bot, contained a custom Packet Sniffer. In order to load, the malware actually needed the .NET framework.

Conclusion
Malware is dominating and it is getting better at it.
Computer memory is the target to extract sensitive data, even if you encrypt you disk and your databases, the data is still going to be in memory unencrypted.
Corporate security is still not getting it.
If a specific peace of malware is successfull it will be used, and probably sold, over and over again.

Their investigation of this specific vulnerability was triggered by an Adobe advisory which discussed the vulnerability without much detail, but mentioned the name the command and control server. Analyzing their malicious PDF samples they found this server in a malicious sample from a bit earlier and they already had the server name in their DNS monitor.

By analyzing the samples they had, they found the vulnerability exploited in them (JBIG2Decode) and started looking for matching samples.

When they informed Adobe, because the was no advisory, Adobe stated that they were aware.

When they found that the attack was not long just used in limited targetted attacks, but in stead the attack count was going up, they decided to do a partial disclosure on shadowserver.org blog. After the partial disclosure, Adobe released an advisory that told people it would be fixed in just over a month.

A few days later a PoC turns up on Milw0rm, which got turned into a weaponized exploit later.

All in all the talk gave quite a bit of insight into lifecycle of mallware.

Steven Adair can be contacte via Steven@schadowserver.com or on twitter as @stevenadair

Moxie developed a tool and technique called SSLSNIFF which is able to do undetectable Man in the Middle attacks on SSL connections exploiting the possibilities null terminated certificates offer. He defined three possible counter measures against his attack. Certificate validation, software updates and extended validation certificates. Unfortunately he was able to defeat two of these three measures.
Certificate validation these days is handled mostly by the OCSP, the Online Certificate Status Protocol. Marlinspike found a flaw in the protocol. On of the statuses the OCSP can send back is “Try later…”, represented by the number 3. Such a reply does not need to be signed by the CA an causes the browser to fail open, or as Moxie put it: “OCSP is defeated by the number 3”.
Software updates can be another issue. At the time of the presentation, these bugs where only fixed in Firefox 3.5, so how do you prevent people from updating to this version? Most browsers these days have a so called auto update function, this function searches online for a more recent version of the browser, addons or plugins. In order to ensure that no malicious content is installed, the browsers rely on SSL, the same SSL that was broken by Marlinspike’s SSLSNIFF.

But there is more trouble in paradise. Marlinspike also demonstrated a technique het called ssl stripping. Ssl stripping does not attack SSL itself, instead it actually attacks, what Moxie described as the bridge between http and https. “Https is today’s world is not often encountered directly. Users don’t often type https:// in the address bar themselves. In stead they get redirected to an https site or click on a link to it”. By performing an man in the middle attack on the http connection and carefully rewriting all https requests to http requests, Marlinspike was able to create near exact copies of the login pages for services such as gmail and paypal. The user would only know something is wrong, if they notice that the https prefix is not there or that the padlock symbol is missing.

Dan Kaminski was also able to exploit the common name field to get certificates he should not be getting. Different implementations of certificate validation routines have flaws when it comes to handling certificates with multiple common names in them. By requesting a certificate with three common names: CN=www.ioactive.com, CN=www.bankofameric.com and CN=* Kaminski was able to get a certificate that would perceived as follows; the CA would sees the certificate as an www.ioactive.com certificate, which Kaminski is allowed to request. Internet Explorer will interpret the certificate as a www.bankofamerica.com certificate and Firefox will allow the certificate to be used for any url.

Besides the common name abuse, Kaminski also showed us that there is still an MD2RSA signed root certificate present in all browsers. While practical exploitation is not possible at the moment, it is very likely that this possible in the near future. Most browser vendors are working to fix the issue right now, but Kaminski kindly requested his public to “please, do not hack MD2 in the next six months.”

The last talk I attended was Mike Zusman’s “Criminal Charges not Pursued, Hacking PKI”. Mike used another technique to get “interesting” certificates. By exploiting a flaw in the web application of a CA, he was able to request certificates for pretty much any domain he wanted.

One of the solutions seems to be popping up is Extended Validation, which in a sense takes us back a couple of years. A few years back, the only way to buy a certificate was to provide legal evidence that you had control over a domain via an out of band mechanism to a human, but then these persons at the CA’s where replaced by an online application with an automated validation process and the fun started.

Extended Validation changes this by enforcing standards for validation and requiring validation by a human before the certificate gets issued. Extended Validation (EV) CA’s are hard coded in the browser to prevent the addition of malicious CA’s. But EV certificates get trusted just as much as classic certificates.

Mike Zusman was able to perform a man in the middle attack PayPal, which uses an EV certificate to protect its site. What his program does is only redirect a small portion of the traffic, the actual login, to his own malicious website which has a non-EV www.paypal.com certificate obtained via on of the methods described earlier. The only side effect visible to the user is a brief flickering of the green address bar. But will a user notice or care?

Obviously dual factor authentication, like PayPal’s security key, will reduce the risk, but what can we really do?

I was able to share a beer with Mike after he presentation and it looks like there are fundamental underlying problems with the current certificate structure. Here we have architecture of trust, yet its foundations are built on the known insecure DNS database. Browser vendors claim they have this set of rules that should be obeyed in order for a CA to be included in the browser, yet practice shows that certain CAs that have not followed these rules are still in the browser, while on commercial CAs, like CAcert are having a hard time getting included in browsers for what seems to be political reasons.
It is time to ask ourselves fundamental questions like: Is it a good thing that a browser vendor determines who’s assertion of identity to trust. There is a trend that browsers make it harder to accept invalid certificates. Mike said: “It currently takes more clicks to accept an invalid certificate, then to import a new CA”. Is this a good thing?

Both Zusman and Kaminski agree that is would be a good thing if we had a trustworthy DNS structure that we could just to, e.g. store the fingerprints of certificates that are valid for our domain. Unfortunately DNSSEC is currently in a status quo. The current implementation still got issues, but until the root servers are going to be signed nobody will be motivated to fix these issues.