How do I know my cloud service is being hacked and abused if it is not running inside my datacenter? What possibilities do I have to check if my employees are acting along the lines of my Acceptable Use policy? Where are the logs of that abuse, and how can I trust the logs? How do I know that my data is not copied elsewhere in the cloud, and analysed offline by my competitor?

With regards to cloud storage, the CDMI (Cloud Data Management Interface) is trying to address some of the questions, but is only one step forward.

Cloud service providers still have a long way to go. An initiative like Eurocloud  is doing great work in paving the road to trust in cloud service providers.

When cloud service providers will be able to succesfully address the concerns, they have a big advantage over the classical IT model of running your own IT: they provide all the securities you would normally build and control youself, but combined with cloud advantages like fast provisioning and fast reuse of resources.

Small and medium-sized business will then be able to actually get a better and more secure service with cloud services, then what they could build and control themselves.

What does this mean for SBP? Sure there will be competition from the cloud providers. But we are nothing more than just another cloud provider. We build services for our clients with our own cloud technologies of fast provisioning, centralized log analysis, but since we build private clouds for our customers, these customers can demand tailored solutions to address their specific needs and concerns.

Cloud computing is not a threath to our business model, but is preparing the market more and more for putting commodity services in the big generic clouds, combined with the need of supporting highly tailored private clouds.

So it is time to face the fact: Schuberg Philis, the private cloud company!

Phone Bill a CC NC ND image from Nikita Kashner's Flickr stream

By Darren Anstee of Arbor Networks

Why is it a good idea to us flow information?

• You don’t need to invest in new equipment to get flow information
• It can be used to detect malware infected hosts, DDoS, zero-day exploits, attack and abuse
• Network flows information is generated regardless if there was symmetric or a-symmetic routing

Network flow information is like a phone bill, you cannot tell what has been said, but you can use it to prove who talked to who.

So what does a flow record contain?

• Source IP address
• Destination IP address
• Source port
• Destination port
• Input IfIndex
• Protocol
• Type of Service
• packet count
• Byte count
• First packet time
• Last packet time
• Output ifIndex
• Etc…

Flow information allows you to monitor large geographically dispersed networks.

So how can flow information be used for security purposes?

Flow information helps you understand how you network normally behaves. Unusual behavior might indicate DDoS attacks of malware infections.

One could look at the flow information manually, but it does make more sense to install a collection and analysis system. These systems often give the benefit of providing historical data that can help us understand current data and allow us to use this information for forensic purposes.

There are a lot of open source and commercial flow collection and analysis systems available.

Next Darren showed demonstrations of how flow information can be used.

First example is how to detect malware infected hosts in an enterprise environment.

How? One of two ways:

• Looking for abnormal behavior
• Looking for known bad behavior, e.g. communication to known Command can Control servers

So what is typical unusual behavior?

• Unusual outbound SMTP
• Off-net DNS queries
• Scan detection
• Unusual outbound behavior
• etc.

Finding more then one anomalies increases the likelihood of these systems being infected.

One of the bonuses of flow information is that routers and switches still generate flow information even if firewalls drop the traffic.

Darren showed us how tools like nfdump can be used to detect systems with various abnormal behavior such as connecting to external mail servers or DNS servers too much or generating classic DDoS attacks.

Naturally you can also use flow information to detect DDoS attacks.

How do tools, like those Arbor makes, detect DDoS attacks?

• Baseline detection and baseline deviation
• Misuse flow detection (SYN-flood, UDP-flood)
• Detect bursts in the network
• Use thresholds

Why would you use flow information over firewall logs? Routers and switches are much more omnipresent and switches and routers do generate flows even if the firewall drops the traffic.

The slides for this talk with links to whitepapers and open source tools can be downloaded from the first.org website.

Bad day at the office a cc nc ND iamge from Roger Smith's Flick stream

By Itzik Kotler

Slides on the HitB Materials page.

Itzik start his presentation that writing StuxNet for a company is much less hard then writing one for a nuclear reactor. Stuxnet is interesting in that it is a purely software based attack that had a real hardware based effect.

So can software damage hardware? Yes it can:

• Software controls hardware ad can make it perform damaging hardware
• Software can damage software that runs hardware
• Software runs hardware and can make this hardware take an action that damages other hardware

So what is PDOS (Permanent Denial of Service)? Damaging hardware so bad that it needs to be replace or reinstalled.

Users the brick their phone when they try to jailbreak it are basically causing a self inflicted PDoS.

So who would do it and why?

Possible scenario’s are:

• Industrial espionage/sabotage

• Rival companies
• Foreign nations

• Hacktivism
• Revenge

So what techniques can you use to cause PDoS:

• Phlashing: malicious overwrite of firmware
• Malicious overclocking. Overclocking hardware too much will break it, e.g. by overheating
• Overvolting. Increasing the voltage of equipment
• Overusing. Causing too much wear and tear on a mechanism
• Power Cycling. most equipment does not handle frequent on-off switching very well

So lets look at some local attacks first:

• Disabling or slowing down fans of computer or other equipment will cause temperature increases which may lead to other failures
• CPU overheating by causing an infinite loop
• Microcode flashed directly into the CPU can be used to cause a PDoS as well, e.g. by overwriting hard wired instruction with faulty instructions
• The techniques for CPUs work for GPUs as well
• Hard drives can  be overheated using excessive read and writes, worn out by excessive parking and phlashed
• Solid state drives van be bricked by wearing out the flash memory by excessive writing

And example of a harddrive attack is a Pseudo format. E.g. by using the script:

# while true; do dd if=/dev/hda1 of=/dev/hda1 conv=notrunc; done

Another harddrive attack is a Spindown attack:

# hdparam –S 1 /dev/had

# while true; sleep 60; dd if/dev/random of=foobar count=1; done

DVD/CD Rom attack:

# while true; do eject /dev/cdrom; eject –t /dev/cdrom; done

Flash memory wear attack:

# while true ; do dd if=/dev/urandom of=/dev/flash; done

But even older equipment can be PDoS-ed. e.g. a CRT monitored can be damaged by sending them the wrong requencies. E.g. the XFree86 configuration warns about this.

Also floppy drives can be damaged by, e.g. moving the head to a sector outside the drive enclosure.

But these updates are also possible remotely, e.g. many devices allow over the wire (OTW) or over the air (OTA) firmware updates.

There are some countermeasures that can be used:

• Overclocking protection
• Overvolting protection
• Temperature protection
• Digitally signed firmware

Breaking the ice a cc nc nd by image from MarcelGermain's Flickr stream

By Ivan Ristić

Slides on the HitB Materials page.

Ivan researches SSL for Qualys. SSL was designed as a protocol add-on by Netscape to secure http, but can be used to secure other protocols as well.

The main challenges today are:

1. Fragility of the trust ecosystem
2. Incorrect or weak configuration
3. Slow adoption of modern statndar
4. Lack of support for virtual SSL hosting
5. Mismatch between HTTP and SSL

There are three main attacks against SSL:

• Passive MitM

• Session Hijacking

• Session bypass (ssl strip)
• Renegotiation attack
• Rogue certificates
• User attackers (who reads warnings)

Ivan’s has a lot of data based on the a surveys conducted by his employer Qualys SSL Labs, EFF’s SSL Observatory. In total 1.2million sites with valid certificates where investigated.

Ivan showed a slide that indicates that of the sites visited only 0.6% of the sites had a fully correct SSL configuration, nearly 50% of the sites did not offer SSL at all.

In Qualys’ most In the most recent SSL Survey only 32% of the sites offering SSL where configured correctly.

So now for the bad stuff:

• 48% of the sites offering SSL still offer SSLv2 which is know to be cryptographically insecure, it is a good thing that most browsers reject it
• Most sites do not offer any support for TLSv1.1 and TLSv1.2
• 62% of the sites still use weaks ciphers
• The TLS renegotiation vulnerability discovered in 2009 still effects nearly 35% the sites

But it is not just about how SSL is configures, but also about how it is used:

• Nearly 80% of the sites offering SSL do not redirect their users to the secure sites by default.
• HTTP Strict Transport Security is only used by 80 out of the the nearly 250,000 sites tested by Qualys.
• The adoption of EV certificates is also low
• Of the tested sites on 9 used all three above techniques.
• A lot of sites mark their cookies as HttpOnly or Secure, but even less that use both techniques
• 22% of the tested sites use some form of mixed content, if you exclude the sites that only use it for images this number only drops slightly to nearly 19%
• 68% of the login forms where not served over HTTPS and 54% submitted data to an http site

So what can we concluse:

• Systematic issues are hotly debated
• However SSL is often broken  by bad deployment and implementation issues
• It is possible to achieve reasonable security, but most sites choose not to do it
• Among the popular sites only a handful have decent SSL deployments

SSL is a success because it bought a relative security to the general public.

Florida Fragments a cc nc sa by image from Merrick Brown's Flickr stream

By Elena Kropochkina and Joffrey Czarny

Slides on the HitB Materials page.

Lots of Webshells used by pentesters to get access to the systems are detected by conventional security products like anti-virus, IPS and WAF. In stead of building a new websheel for each assignment the presenters tried to work towards a framework for webshells, that was modular and added obfuscation as a protection against AV/IPS/WAF.

But if you want to build a webshell framework you need to know what is out there. Most webservers on the internet are dominantly Apache, IIS and Weblogic. Pentesters are most in need of Webshells based on ASP, PHP and Java shells as it is heavily used for intranet applications.

The presenters gave an overview of the webshels out there for webshells for Linux, MySQL, PHP, JSP, ASP. Many of the common shells have high detection rates on the most common anti-virus platforms.

Even tough there are some webshells that are nearly complete in features and others that are not detected by Anti-Virus there isn’t one that is both.

There are a few ways to get around anti-virus encoding, obfuscation and encryption. There are common tools available to obfuscation for different languages like PHP, VBScript and Java. Obfuscation tools make reading the code harder, but are analysis is often still possible.

Using this knowledge the presenters designed a webshell platform. The platform should be language independent, resistant against third party unauthorized access and not be detected by AV/IPS/WAF.

Protection against unauthorized third party access is archived by mean of encryption based on “user provided key”, server IP address and client IP address.

So what are the must have functionalities of the framework:

• System information
• Graphical file maanger
• file upload/download
• command line cmd
• SQL manager

Elena and Joffrey show the design and some code fragments of the platform and demonstrated the proof of concept platform.

The proof of concept is already very feature rich.

Elena Kropochkina begins her professional career in Devoteam Audit Security team. She was graduated by Ecole Polytechnique and Telecom ParisTech with a M.S. in Computer Science. She is specialized in IT Security and Artificial Intelligence.

About Joffrey Czarny

Joffrey Czarny, working for Devoteam Security Business Unit (FR). Since 2001, Joffrey is a pentester, he has released advisories on VoIP Cisco products and spoken at various security-focused conferences (Wireless Conference at Infosec Paris and Wireless Workshop at Hack.lu 2005, VoIP at Hack.lu 2007/2008 and ITunderground 2008/2009). On his site, www.insomnihack.net, he maintains the Elsenot project and posts video tutorials and tools on several security aspects.

Slides on the HitB Materials page.

Don’s talk focuses about devices that are designed to track your assets or loved one., specifically the Zoombak who’s biggest selling point is that you can use it to definitely know where your kids are. Zoombak really took off after it was endorsed by TV personality Oprah.

A Zoombak devices basically consist of a GSM module and a MicroController. These two do not share any memory, but talk to each other over a serial channel using AT commands.

On of the first flaws in the Zoombak is that the GSM module can only talk using the decommissioned and broken A5/2 algorithm. A5/2 is so weak that it can be cracked in real time using PC hardware, but Don didn’t use this eakness to attack the device.

Because being on the GSM network all the time is too expensive the Zoombak device works differently. If you want to know the location of the device you send it an SMS, the SMS is polled from the SIM by the Micro Controller and acts on this command, e.g. by sending the location of the device to a website over the GPRS network.

The SMS received by the Zoombak does not only contain what should be sent back, but also the IP address where the device needs to post this data.

By reverse engineering the messages sent between the MicroController and the GSM module Don was know the protocol and to spoof the devices.

Using a small shell script and tons of SMSes you can actually test devices to see if they are Zoombak devices. But using a technique Don dubbed ‘War Texting’ he was able to avoid SMS spam detection, e.g. by changing the nonce and thus generating a different messages per hosts.

But spamming all phone numbers is not needed. There are device characteristics that can be used to narrow the target range. E.g. by polling the HLR we can determine if the device is a T-Mobile device.

Next step after being able to identify a target, but can we intercept the data and spoof the device? Yes we can!

So what fun can we have with these devices? It can be used to e.g. know or spoof the location of valuable goods that are often protected by these devices. E.g. to pinpoint a “good” location for a heist or to convince the security system that nothing is wrong.

What can be done?

• Don’t send IP addresses in SMS messages
• Encrypt the SMS messages
• Don’t allow non-Zoomback devices to receive IP messages from the Zoomback devices
• Use HLR data to detect fraud

Embedded Security is hard:

• Weak security surface
• Big threat surface
• Many “moving parts”
• The days of obfuscation are over

It is very likely that Zoomback is not the only example of this, mechanisms like this are also used in traffic control systems, SCADA systems and many other applications.

While Don’s primary expertise is in developing exploit technology, he is also well versed at reverse engineering, fuzzing, enterprise programming, binary analysis, root kit detection and design, and network penetration testing. In addition, Don has helped develop and enhance risk management programs for several Fortune 500 companies in recent years and has been invited to speak about risk management from a CISO perspective at government organized conferences.

For the past five years, Don has presented research at several international security conferences discussing topics such as stealth root-kit design, zero-day exploit technology, DECT, GSM, and microcontroller security. Most recently, Don spoke at Blackhat Abu Dhabi 2010 and ToorCon San Diego 2010 regarding vulnerabilities in the global telephone network and the GSM protocol.

For Heat a CC-NC-ND image from ailatan's Flickr stream

By Xavier Mertens

Managing security events from you network. It is often perceived as boring. There is a lot of information and lots of tools. Additionally log formats are not standardized.

There are also economic issues, uptime often takes precedence over uptime, it takes time, staff may be reduced and it not a revenue generating activity.

Additionally there are legal issues, these issues center around privacy and have to be checked against local law.

Managing security logs is a layered approach:

1. Log collection
2. Normalization
3. Storage
4. Search
5. Reporting
6. Correlation

Correlation can be used to give events more meaning. This can be done with external sources like vulnerability information, but also with internal sources like e.g. badge swipes or geo-location.

Xavier is not a big fan of the big vendors. They provide expensive solutions, but only 10% of the features is used. The most expensive product is not automatically the best solution.

There is a difference between Log management (step 1 to 4 maybe 5) Security (Incident) Event Management (SIEM) should include all 6 steps.

When you want to buy a solution you need to consider:

• Compliance
• What suspicious activity are you looking for
• Web application monitoring
• Correlation
• Supported devices
• Buying a SIEM is a very specific project.

Syslog daemons are a good way to start, but syslog is not issue free. Since a syslog message can contain a free format message it is very hard to pass.

A good too to start is SEC, “Simple Event Correlation”. It performs correlation of logs based on Perlregular expressions to produce new events, trigger scripts or write entries to a file. Perl knowledge is required.

OSSEC is actually a Host Based IDS, but it does Log collection and parsing as well. Like SEC it can create new events or launch scripts and supports rootkit detection and file integrity checking and has log archiving.

There are more protocols then syslog. Unfortunately there is no standard format yet.

Cooking book

Xavier then showed some “recipes”:

• OSSEC to do USB Stick insertion on windows
• MySQL Integrity Auditing
• Detection of suspicious IP’s and users
• To map attacks on the map using Google Maps.
• And an example OSSEC dashboard

There are other tools to get more visualisation:

• Loggly (Saas)
• Splunk
• Secviz.org

Xavier’s conclusion: you need log management because you cannot review your logs manually. You need to stick to your requirements. However you do it, it will cost time and money.

More informaiton on Xaviers blog.

Wrong Way ... Way Wrong a CC NC SA image from Bob.Fornal's Flickr stream

Virtualization aims to save money, make things simple and quick to deploy. Saving money and quick deployment are arch enemies of security

Virtualization products require security on the hypervisor level. Being able to hop from one virtual machine to another is not acceptable. Also there are a lot of products that focus on the security in the virtual machines, but virtualized infrastructure are complex by nature.

Relative lame bugs like XSS can be a big deal in virtualization infrastructures

Claudio demonstrates that live on stage, by exploiting a XSS bug in VMWare vCenter which took 1.5 years to patch.

Claudio showed us how an unprivileged user on the vCenter machine able to read a logfile contain the administrator SOAP session ID. Using this ID and Vasto administrator privileges where obtained. Until the last patch read-only access to vCenter meant that the user could take over the virtual infrastructure using standard tools.

Next attack demonstrated is against an Oracle virtual machine. Using standard “lame” exploits Claudio was able to hope from the application level administrator to the system root account.

So there are still some very simple vulnerabilities in this software.

Virtualization software is broken today, and we have to treat it accordingly. We have to make people aware that it is broken.

Virtualization infrastructures should be setup in such a way that a XSS in the management layer cannot lead to a disaster.

Claudio defines a new model that consists of a vCell and a vGatekeeper. With the goal of still providing some security if you lose your management solution.

vGatekeeper uses mod_security to define which communication is allowed between the management solution and the virtual machines.

With vGatekeer you can define which actions a user can execute on a virtual infrastructure regardless of his or her authentication level. The vGatekeeper software will generate a network configuration file and a mod_security configuration file that will prevent certain actions for propagating from vCenter to ESXi.

Claudio demos this application live on stage.

vGetkeeper will give the control back to the security team, in stead of it being in control of the virtualization team.

Ghosts of Lake Sutherland a CC NC SA image from Wyrmworld's Flickr stream

DoS, making resources unavailable to others. Common motives are hacktivism, extortion and rivalry. Most big attacks are successful.

So what are the risks of being under DoS attack? Downtime, lost revenue, large bills from the cloud service providers.

What kinds of DoS attacks are there?

• Layer 3 – Muscle-based attacks, generating too much packets for the equipment or saturating the pipe.
• Layer 4 – Consumes more resources on the device., e.g. SYN flood, connection flood, concurrent connection exhaustion, garbage data.
• Layer 7 – Attacking the application. Trying to consume as much resources as possible. E.g. HTTP page flood, HTTP bandwidth consumption, DNS query flood, SIP INVITE flood. There attacks are low rate, high impact

So how do you mitigate DoS attacks?

Static thresholds work and put the operation team in control, however they require constant tuning and restrict the detection phase to a single-dimension (rate only).

Adaptive threshold, attempting the learn real traffic characteristics, which improves accuracy, however, natural traffic peaks like e.g. a Christmas peak may be blocked too.

A more sophisticated detection can be based on using two dimensions, e.g. DNS requests v.s. HTTP requests. The presenters show a graph that shows a 3D graph of an L3 flood. Another metric that can be used is the distribution of content-types vs. the number of HTTP requests.

So by using two dimensions to determine if you are in a DoS attack you can reduce the false positive rate.

A lot of DoS bot clients have a very specific TCP header, however there are too much DoS tools to actually rely on a human to create the signatures.

Besides to passively block traffic by thresholds or patterns, you could also include a active mitigation like:

• Challenge response – This wards of clients that don’t have a full protocol stack e.g. SYN cookies or requiring JavaScript.
• Session Disruption – Causing the clients to use more resources in the attack that you need to mitigate the attack
• Tarpitting – Stalling malicious connections.

There are  a lot of different ways to do challenge response mitigation. Using JavaScript to verify is a DOM is present, detect if flash is present or use other systems.

If an attack is detected, it is important not just to drop the connection, but also to reset the backend connection. If you just reset the backend connection, but not the bot connection you may cause the attacker to consume a lot of resources himself. LaBrea is a nice way of slowing down attacks in progress slowing the connection down, sometimes to the point where the bot crashes.

Most of the shell x86 based hardware is simply incapable of handling a full 1Gb+ network stream at wire speed. Dedicated ASIC is the only hardware capable of supporting these speeds.

Mitigating LOIC

LOIC was not a new tool, but some parts like the hive mind was added lately. It is capable of generating malformed HTTP requests, but it has terrible thread and IO management.

The presenters present Roboo – Open Source HTTP Robot Mitigator.

Roboo will respond to each GET or POST request from an unverified source with a challenge: Challenge is javascript or flash based and optionally gzip compressed. A real browser with full HTTP, HTML, JavaScript and/or Flash player will be able to generate the correct response and issue the original request.

Roboo can whitelist allowed robot activity and pass it.

Roboo integrates with the high performance Nginx webserver and reverse proxy.

Roboo was tested against: LOIC, Acentuix Web Vulnerability Scanner, Metasploit Pro, Nessus and many more. It can serve as a Captcha replacement too.

Roboo can be downloaded from www.ecl-labs.org.

Roboo was demonstrated.

Summary of the talk:

• DoS is booming – attacks are growing in power and efficiency
• Cloud subscribers are the new victims
• Anti-DoS technologies has greatly evolved

---

Yuri Gushin has been involved with security research & development for over a decade, including extensive work in the fields of IPS and DoS detection and evasion technologies, network and application vulnerability discovery and exploitation, protocol fuzzing and plenty more. Yuri also co-founded the ECL Labs research group.

Currently, Yuri is the Senior Security Specialist for Europe, Middle East and Africa (EMEA) at Radware, heading the major security activities around the region, and playing an active role in the design of Radware’s next generation security offerings.

Alex Behar has been in InfoSec for the last 15 years, participating in research, exploit development and reverse engineering of network protocols and application stacks. Most recently, Alex was a Senior Researcher in Radware’s DefensePro security team and is currently Director of Security Products for Radware North America. Additionally, he is a co-founder of security research think-tank ECL-Labs and core developer of the Raptor Traffic Suite.

Cycle Garage a CC NC ND image from Ezu's Flickr stream

This talk focuses on ABAP, Advance Business Application Programming language from SAP.

ABAP:

• A proprietary language of which the exact specification is not freely available.
• It has platform independent code
• It has client separation built-in
• It has integrated auditing capabilities
• System-to-system calls via SAP RFC standard
• Built-in transportation system and version control
• Integrated platform-independent SQL Standard: Open SQL
• Built-in authentication, roles and (explicit) authorization model
• Thousands of well-known standard programs and database tables
• 150+ Million Line of Code in an ECC6.0 System

So what are the ABAP security risks?

• Back doors can be introduced, e.g. by a malicious developer.
• The program can have undesired side effect (e.g. SQL injection)
• Sub standard authentication used

Some ABAP code in the SAP system is dynamically generated at run time this can affect names of variables, SQL statements, but also ABAP variables can contain ABAP code that can be executed at runtime.

While SQL injection is possible in ABAP, it is not possible to terminal an SQL statement an start a new one in Open SQL, hence the possibilities are somewhat limited.

There is even dynamically generated ABAP code, that is generated and executed in memory and then disappears without leaving any trace in the system.

The shortest ABAP program to become super user on a SAP system is 34 characters, but will set of all alarms, a longer version of 56 characters is completely stealthy.

But ABAP has a low level ABAP kernel. It should only be used by SAP, and mostly undocumented, but can be explicitly invoked from ABAP.

There are three kinds of ABAP kernel functions:

• Kernel calls
• System calls
• Kernel methods

Kernel methods are the newest method to interact with the SAP kernel, they are called like normal functions and have typed parameters.

Some routines in the ABAP runtimes have hooks back into ABAP code. These functions are called from the C/C++ of the ABAP runtime. Data is exchanged between the ABAP code and the ABAP runtime via more ABAP kernel calls AB_GET_C_PARAMS and AB_SET_C_PARAMS.

These ABAP kernel hooks can be used to hijack calls in the ABAP runtime.

There are 8 high risk kernel calls:

• SYSTEM – OS command execution
• XXPASS and XXPASSNET – Compute password hasj
• INTERNET_USER_LOGOON
• C_GET_TABLE
• C_MOD_TABLE
• C_DB_EXECUTE
• C_DB_FUNCTION

SYSTEM can execute any OS command. It completely bypasses the list of allowed OS commands specified by the system administrator. Luckily it uses implicit authority check and the call can be disabled by setting the profile parameter rdisp/call_system to 0. But it is not the only way to execute OS commands!

XXPASS and XXPASSNET computes password hashes that is internally used by SAP to put into the user table. If you use this call outside the correct scope (e.g. Y* or Z* namespace) your session will be terminated and your user account will be locked.

INTERNET_USER_LOGON this can be used to perform user switches and create logon tickers. If can only be used to check credentials and it does keep track of failed login attempts.

C_GET_TABLE allows the programmer to read arbitrary database tables. They do allow cross client data access. So it allows one client of a host SAP installation to read tables from another client.

C_MOD_TABLE this call allow the programmer to write or modify any arbitrary tables on the system, without any restrictions.

C_DB_EXECUTE allows for the execution of arbitrary SQL statement. It allows each and any SQL statement apart from select. It does not respect client boundaries.

C_DB_FUNCITON allow for the execution of arbitrary stored procedures or any arbitrary SQL statement.

Andreas then goes on to demonstrate how to take over an SAP system using these kernel calls.

He showed this by truncating a table and accessing data from another client something you are not supposed to do in custom code. There are even more 0day kernel calls that at this time cannot be disclosed due to responsible disclosure. The ABAP runtime should guard the SAP kernel, but if a large enough parameter can be transported through ABAP an SAP kernel can be performed. Kernel call C_SAPCPARAM can be used to trigger a SAP kernel buffer overflow via ABAT. This is also available remotely via RFC.

gluey harmony a CC NC ND image from giveawayboy's Flickr stream

SAP: Session (Fixation) Attacks and Protections (in Web Applications)

Raul Siles is @taddong on Twitter

Why do we need session management in Web Applications. HTTP is a stateless protocol so the application need to handle ourselves.

Sesion Fixations if different then session hijacking. In hijacking you will use somebody else’s session ID to become them. In session fixation the attacker fixes the session ID before he logins into the target application.

So what is the state of the art of session fixation 9 years after its discovery in 2002?

Like HTTP parameter pollution session IDs can also be accepted from multiple sources, even tough the application only uses a single method. E.g. the application may user GET parameters, but still accept session ID cookies.

So how does session fixation work? An attacker sets up a session with a website, but does not log on. He then tricks a user into log in using the same session ID. As the session gets elevated, both the attacker and victim get the authenticated state.

Session fixation does not require solcial engineering, but can also be obtained by e.g. Cross Site Scripting (XSS) or SQL injection.

In order to demonstrate the problem Raul shows the vulnerability as it existed in Joomla 1.5.x-1.5.15

HTTPS does not protect against session fixation vulnerabilities, neither does using MD5 values for the cookie ID or values.

The second case study involves a web application based on WebLogic. Which is reported live today. The JSESSIONID cookie was configured to contain a too broad domain. normally WebLogic provides two cookies a post authentication cookie and a pre-authentication cookie which should tackle the problem.

The application allowed all resources to be accessed both via HTTP and HTTPS. And the HTTP site did not require the post-authentication cookie. Thus the session fixation protection was not present on HTTP.

So how easy is it to introduce this misconfiguration? If web.xml states that the “transport-guarantee” as NONE this vulnerability is present. This is the default setting.

It could very well be that that even tough you have set the default to CONFIDENTIAL, it could still be that some resources are set to NONE as an exception.

So what can you do about it?

• Set your “AuthCookieEnabled” and “transport-guarantee” setting to secure values.
• If you use the login api, use the ServletAUthenticaiton.generateNewSessionID(request) call after login to generate a new session ID otherwise force the app server to automatically generate new session IDs after login.
• Enforce both encryption and authentication (not set by default)

The third case study focuses on SAP.

In this pentest, users where authenticated against the Intranet first using NTLM then redirected to HTTP SAP application and then redirected to HTTPS SAP application. This allowed Raul to fix the sessionID using a MitM attack.

The session of any user that logged on lead to the testers being able to log on with the same authentications.

The issue was first reported in July 2009, and a fix was released in December 2010. It will take another 3 months to be implemented on the client infrastructure.

SessionIDRegeneration is still disabled in older SAP releases (pre 7.11) in order to avoid compatibility issues.

Other protection methods like SystemCookiesHTTPSenabled and SessionIPProtectionEnabled are both available in SAP but off by default.

Conclusion

• SessionIDs need to be renewed after privilige level changes
• There is no link between session management and authentication, we need to take care of it ourselves
• Limit the number of session tracking methods accepted
• Use HTTPS if you can

It is still an old but valid method affecting thousands of users. You auhtnication can be very secure, however once you have established a secure session with a token, the session ID is all that protects your session.

photo Eurofighter Typhoon Payload - A CC NC ND image from Stuart R Brown's Flickr stream

talk focuses on the w3af project, which has been Andres project for a long time, but is an open source project. It can be found at http://w3af.sourceforge.net/

Andres starts by giving an overview of w3af.

He then goes into a scenario which is common for a pentest. It starts with a pentester discovering a arbitrary file read vulnerability in a PHP application, but how to proceed to getting root? There appears to a shocking lack of post exploitation tools that can be applied to web application vulnerabilities.

Why is there such a lack of post exploitation tools for web applications?

• Buffer overflows used to be more common then web application flaws
• Web applications only allow you to interact with the system in a specific (restircted) manner

Post exploitation of web applications requires a new mindset, because you are often restricted to one or a few functions, e.g. read files with restricted privileges or write files to specific areas.

Andres shows use how a payload in w3af looks like. He shows the following process:

1. Start a w3af scan
2. identify arbitrary file read vulnerability
3. Execute the “users” payload that read /etc/passwd and parses it.
4. Show the results

W3af has payload for showing the users on the system, showing the open TCP connections and interesting files on the system. The interesting files payload tries to find interesting files in a lot of different places, including all user home directories.

There is logic in payloads as wel, based on the information obtained during the scan phase. E.g. of this is the get_source_code payload that behaves differently on windows and unix based systems. This payload makes it really simple to obtain the full source code from a webserver.

O.K. so now we have the sourcecode, now what? We have build a PoC PHP Static code analyzer and integrated it with w3af. We can now use w3af to discover even more vulnerabilities. E.g. code analysis will show e.g. an SQLi vulnerability that will lead to arbitrary file write.

Andres then showed us that this is not just theory, but demoed it too.

Bare in mind that the current SCA in w3af is only at proof of concept level only. There are many things still missing from it. If you feel like contributing, please contact Andres.

If you can use the exec() function, there are much more cool things to do. w3af can then integrate with the Metasploit framework to execute msf payloads (like meterpreter). This function was also demoed.

His main focus has always been the Web Application Security field, in which he developed w3af a Web Application Attack and Audit Framework used extensively by penetration testers and security consultants. Andres has spoken and hold trainings at many security conferences around the globe, like OWASP World C0n (USA), CanSecWest (Canada), T2 (Finland) and ekoparty (Buenos Aires).

Fog | Power Plant - A CC NC SA image from fxp's Flickr stream

Marco’s (embyte@iseclab.org) research focuses on the first automated approach to detect PHP parameter pollution.

(Slide deck)

What is parameter pollution?

In http it is allow to provide a parameter via GET and via POST. You can also provide a parameter twice. Some application do not handle this very well and interpret both, the first or the second.

E.g. will the url http://somesite.com/vote.jpt?pool_id=4568&candidate=green&candidate=white vote for Mr. Green or Mr. White? Since PHP always opts for the first parameter the vote will go to Mr. Green.

Since parameters in a get request overwrite the parameters in the post request, An attacker can pollute http parameters without manipulating the page itself.

Marco has built a system that can automatically test HTTP parameter pollution for both problems:

P-Scan scans for Parameter precedence.

It performs three tests:

• Error Test – Test if the application crashes if a parameter is repeated twice
• Identity test – Is a second parameter considered by the application
• Base test – Assume that pre-filtering works

V-Scan tests for actual http parameter pollution vulnerabilities. When it is determined that pages reactive differently when parameter pollution is applied. V-Scan eliminates those cases where these differences are not a vulnerability.

These tests are implemented in a tool called PAPAS.

Marco proceeds to present the results of deploying PAPAS against about 5,000 popular websites. The sites that appeared to vulnerable in more vulnerable where inspected in more detail.

Over 1200 of 5000 sites gave inconsistent results when parameters are duplicated and 238 sites gave a database error. 30% of the tested websites (about 1,500) contained at least one page that was vulnerable to HTTP Parameter Injection

About 14% of the tested sites where exploitable, meaning that Marco was able in inject a new parameter into the page or overwrite a parameter on the page. This figure was more or less consistent across different branches.

Sites that were tested include Facebook, Google, Symantec, microsoft, PayPal, Flickr, FoxVideo, VMWare.

Vulnerable sites:

• Facebook share button
• World Health Organization homepage
• Paypal raise account page
• Nasa slideshow page

The example of the AETV shopping page shows how shoppers can be mislead into buying a different product then they think they are buying. This could also be done with the site of US bank.

Even the main Google site could be manipulated to produce search results different from the intended results.

PARAS is available as a free online service at http://papas.iseclab.org/

This online service is then demoed by Marco.

So how can this be prevented? It can be done with classical methos:

• Input validation
• User safe methods
• Only accept parameters from the channel you expect then from

WhiteRabbits - A CC NC SA Image from Halans Photo Stream

Subtitle: Theory, Design and Implementation of Complex Systems for Testing Application Logic

Rafal works at HP (blog).

The talk is step up as a three act play.

Act 1 – Definition

What is “application logic”?. Rafal is trying to discover the definition to “application logic”, via and interactive process with the audience.

He starts of by showing a business flow for ordering items online as well as adding loyalty points. If the business flow is not implemented correctly, loyalty points get added without the transaction being completed. This means you can get hacked without your infrastructure being compromised.

The difference between flaw in the business logic instead of a flaw in the application logic, is that the latter can be patched, while the first requires a redesign of the program.

How is this different then e.g. the OWASP top 10? The closest match we have is the MITRE CWE Top 25.

Act 2 – Types of defects

There are basically two types of these attacks:

• Privilege manipulation
• Transaction control manipulation

Privilege Manipulation: Flaw based on broken or incomplete authentication/authorization mechanism.

The class of privilege manipulation contains both flaws in application logic and business logic.

E.g. a form posts besides username and password also a field that is called role. By changing the value of this field to e.g. admin, the user can elevate his privileges where this was not intended.

Transaction control manipulation: Exploiting flaws in business logic

E.g. a online ticket shop only sells ten tickets at a time. By changing the data submitted to the webserver it could be possible to order 30 tickets in one go. What if you change the number to a negative number? The company sends you money and ends up with ghost inventory.

These attacks don’t show up in a WaF, it only shows up in an audit.

A big lesson here is that all the business logic should be controlled by the server. The server should now not to allow values bigger or smaller then the allowed values.

Rafal’s research is aimed a better enable testers to find these flaws via automation.

There have been a few talks on this subject in the past, but it hasn’t been addressed concretely enough. There is currently no tool either open source or commercial that tests for these flaws.

Logic vs. Automation

There are some challenges for both humans and technology:

For humans they are: the need to understand the application, they need to drive automation and be able to document and repeat .

For technology they are: How do you map application against the process, identify control logic and how can we differentiate between successful and failed tests.

Application “logic” is tricky. This was demonstrated by the AT&T/iPad email hack. It implies human logic is a requirement.

Random fuzzing does not work well against logic errors, because it is not efficient.We are not just looking for malicious or invalid data, we are looking for edge cases that will trip logic flaws.

Act 3 – Building the framework

The framework consits of three steps:

• Model
• Manipulate
• Analyze

Modeling the application means defining the business process, what does it do, how does it do it and what should be the outcome. This should result in a state machine of the application.

Manipulate means manipulating the flow of the application to make it do something different in a meaningful way. A library of pre-defined modification is going to help here.

Analyzing the results of the manipulation is going to be hard. How can you measure the deviation form the desired behaviors cause by our manipulation.

Demo time

Rafal showed the current state of the project by means of a demo. He recorded the actions required to store an 8 dollar item into a shopping card and order the itme. Then he introduced a fictitious price increase to $1,000,000. By replaying parts of the steps required to complete the $8 order he was still able to order the item for the original $8 price.

The MSS: settings used to be here...

I recently got involved in a project where I defined the Baseline Security settings for windows and Linux. I used the settings provided by the Center for Internet Security (CIS).

We decided on the following approach:

• Based on the CIS templates we created a baseline document specific to our company
• I, in my security role, created a Nessus .audit file, so we could audit compliance to our own baseline with Seccubus
• The windows administrator created GPOs to apply the settings.

When creating in the GPOs we did a strange discovery. In a windows the settings that are normally marked as MSS: in the category Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options do not appear in a domain if its functional level is Windows 2008.

This made us wonder, have these setting become irrelevant ? If this is not the case, how can we still set them, preferably via group policy?

The settings are not irrelevant, as e.g. Peter van Eeckhoutte’s blog points out. Windows 2008 does not forward IPv4 packets that have source routing on them,  but it does accept them if the machine is the final destination. However for IPv6 Windows 2008 will forward these packets by default.

So if the settings are not irrelevant, how can we apply them if they are not in the Group Policy Editor? For this purpose we created an .adm file, which can be loaded into the Group Policy editor as a Classic Administrative template.

All the MSS settings can be controlled with this Administrative template. When we applied these settings we reached our desired compliancy with our own baselines.

Mission Accomplished!

So what are these MSS setting and what do they do?

Logo 2.0 Part I

Sharon works as a social engineer in London for First Defence. As social engineer she breaks into buildings, lies to people and pretends to be other people. It was a trade that she started young and later found out that she could earn a living and she has been doing it for over ten years. Social networks has influenced social engineering and made it a lot easier.

Social engineering is used for both good and bad, even tough the bad use gets a lot more attention then the good uses. All advertising is a form of social engineering.

If hackers are using social engineering they are effectively hacking the human firewall in stead of the technical firewall.

Why does it work?

• People have a tendency to trust
• People want to help
• People respect authorities
• It is easier to give people information then to get rid of them
• People don’t like confrontations
• Social engineers invoke emotion

Why do Social Engineering and Social Networking combine so “well”? Social engineering exploits trust, and social networks are built on trust.

Why would a social engineer use social networks?

• There is a huge attack surface (400M+ facebook users)
• Quick and easy and to some extend even automated
• Low threshold (almost not skills required)
• It is public information, so no laws are broken
• No more dumpster diving

Why does social engineering work so well?

• Trust model
• No real authentication
• Influential
  • Social Proof: People do things other peoples do
  • Similarity: People who are “similar” to us have more influence

Impersonation in the real world requires, acting, costumes, may be illegal, takes lots of planning, multiple people. So it’s easy to get caught.

Social network impersonation requires, a fake profile, a good (seductive) picture and some patience and typing. This was proven by the Robin Sage experiment.

What does Sharon used LinkedIn for?

• Tactical Research
• Organization chart
• Identity information
• Name dropping
• Check who is on holiday (Trippit)
• Fake profiles or fake invites

For ethical social engineering 90% of the time is spent doing research online.

Most on-line social engineering attempts are classical attacks adapted for on-line use:

• 419 scams used to come via fax and letter
• Instead of scams coming from a stranger they come form a friend
• “Stranded” are more believable when executed during incidents like the “ashcloud”
• Friends of targets may become first targets themselves

Sharon showed us three examples of social engineering attacks executed in real life.

Sharon was able to show us numerous examples of how she could abuse real information posted online. LinkedIn, Facbook, Blippy, Foursquare where all present.

So what can you do about it?

• User awareness
• Have a policy
• Be careful what you post online
• Avoid “promiscuous” friending
• Don’t click on links in emails that are received unexpectedly
• Google yourself

Most posts to social networks are done during work hours and form work laptops… think about it.

IVIL is an XML schema to feed vulnerability information that is the output of a tool like e.g. Nessus, Nikto or OpenVAS into a tool to further use this information like e.g. Seccubus.

We felt that there is a need for an open, non-proprietary language that is lean and mean even though a lot of tools offer a native XML output because such a solution has a number of advantages.

• Not need to modify the receiving tool. Having an intermediary language means that a new tool can be integrated into an existing tool without the need to make modification to the tool receiving the information.
• Support for home brew tools. The open format makes it possible to integrate home brew tools with other tools without the need for the original author to put effort into supporting a tool “nobody uses”.
• Programming language independent. There is no need for anybody that want to integrate two tools be master the programming languages these tools where written in.

We felt we needed to share this work on IVIL to get the widest possible basis for adoption.

During our initial call we came up with this initial version of the XML schema:

<IVIL version=0.2>
    <addressee>
        <program>Seccubus|…
        <programSpecificData>
            <ScanID>
            <ScanID>
        </programSpecificData>
    </addressee>
    <sender>
        <scanner_type>Nessus|Nessus|Nikto|MSF|OpenVAS
        <version>
        <timestamp>YYYYMMDDHHMMSS</
    <sender/>
    <findings>
        <finding>
            <ip>
            <port>
            <id>
            <severity>
            <finding_txt>
            <references>
                <cve>
                <bid>
                <osvdb>
                <url>
                <msf>
            </references>
        </finding>
    </findings>
</ivil>

During our initial call we came up with this initial version of the XML schema:

<IVIL version=0.2>
    <addressee>
        <program>Seccubus|…
        <programSpecificData>
            <ScanID>
            <ScanID>
        </programSpecificData>
    </addressee>
    <sender>
        <scanner_type>Nessus|Nikto|MSF|OpenVAS|Qualis|...
        <version>
        <timestamp>YYYYMMDDHHMMSS</
    <sender/>
    <hosts>
        <host>
            <ip>
	    <findings>
	        <finding>
                    <port>
                    <id>
                    <severity>
                    <finding_txt>
                    <references>
                        <cve>
                        <bid>
                        <osvdb>
                        <url>
                        <msf>
                    </references>
                </finding>
            </findings>
        </host>
    </hosts>
</ivil>

So, lets go through the meaning of each block.

<IVIL version=0.2>
    <addressee>
        <program>Seccubus|…
        <programSpecificData>
            <Scan>
            <WorkSpace>
        </programSpecificData>
    </addressee>

The addressee block of the file is optional. It can contains information specific to the receiving program. E.g. for Seccubus you could use this block to specify which workspace and scan to load the data into.

    <sender>
        <scanner_type>Nessus|Nikto|MSF|OpenVAS
        <version>
        <timestamp>YYYYMMDDHHMMSS</
    <sender/>

The sender block contains generic information about the scan. Which scanner was used, which version and when did the scan take place. There three attributes of the sender are mandatory, but other attributes can be added if so desired.

    <findings>
        <findings>
            <ip>
            <port>
            <id>
            <severity>
            <finding_txt>

The header of the findings block defines on which host ip and port the finding was found, this information can also be stored in the host block of the per host version of the schema. It then contains the id of the finding (e.g. the Nessus plugin number), the severity (0=undetermined,1=low, 2=medium, 3=high) and a human readable description of the finding. For Nessus this description would be the combination of the finding description and plugin output

            <references>
                <cve>
                <bid>
                <osvdb>
                <msf>
                <url>
            </references>

The references block contains one or more references. CVE tages refer to CVE findings in the format (CVE|CAN)-YYYY-####, BID to security focus vulnerability database findings in the format BID:####, OSVDB tags to Open Vulnerability DataBase references in OSVDB:##### format, msf tags refer to Metasploit Framework references in the format xxxxx/xxxxx/xxxxx and url tags can be used to refer to generic URLs.

        </finding>
    </findings>
</ivil>

This block closes the IVIL file.

So let’s say that Zate wants to write a module that starts a Nessus scan and uploads the result to Seccubus. All he needs to do is write a command line program that starts the scan, outputs the results into IVIL format and load the IVIL into seccubus. the command line would look something like this.

> /opt/zatescan/perform-nessus-scan > /tmp/scan.ivil
> /opt/seccubus/bin/load-ivil /tmp/scan.ivil

My main objective in watching the webcast (which is not my usual habit) was to find out if systems that have the described workaround applied still need to apply the patch. The webcast did not give a definitive answer but this YouTube video and the Netifera website and the twitter accounts Thai Duong provide the answer: Yes you should apply the patch a.s.a.p!

Click here to view the embedded video.

However the Q&A section of the talk did give me, as a security operations guy, quite some food for thought. I made some notes in my own Twitter feed, which I have summarized here.

Q: Why did Microsoft release and OOB update for a vulnerability rated “only” as important?
A: The vulnerability itself is rated as Important because it is not a vulnerability that directly leads to remote code execution on the vulnerable system, however exploitation of the vulnerability will lead to disclosure of all information in the webroot including web.config. This information can be used for session hijacking, compromising backend databases and to attack associations between websites, e.g. the association of a website with PayPal. Hence an out of band patch was warranted.

Q: Why only release to the download center and not to WSUS etc?
A: We felt we needed to get this update out quickly, the people that need to apply this patch quickly are mainly enterprises who are capable of applying patches without the aid of WSUS. Developing the WSUS capabilities would add another few days of delay to the deployment of this patch.

Q: Is the attack actively used?

A: We have seen limited attacks against this vulnerability as well as continuous efforts to to bypass installed workarounds.

Q: Can the patch be uninstalled, does it require a reboot?
A: The patch can be uninstalled and does require a reboot.

Q: If you have multiple versions of .Net installed on the system, do you need to install all patches for each version of .Net?
A: Yes.

Q: If you have 64bit and 32bit version of Asp.Net installed, do you need to apply both 64bit and 32bit patches?
A: No, the 64bit patch will patch the 32bit versions as well.

Q: Should we regard the ASP.NET MachineKey as compromised?
A: Yes, if you have set a static MachineKey it is recommended to replace this key with a new key. (Information on AutoGenerated MachineKeys was not provided)

Q: Will the patch have an effect on end-users?
A: Yes, information stored on the client that is protected by the MachineKey can no longer be validated. This can e.g. mean that users whoo used a ‘remember me’ function will have to login in again.

Q: Does the patch need to be applied to all nodes of a cluster?
A: Yes, because the patch changes the way data in transit (such as e.g. viewstate) is encrypted, this patch needs to be applied to all nodes in a cluster as the same time or users may experience unexpected results.

Q: Does the patch change IIS?
A: No, the patch only changes ASP.NET, not IIS.

Q: Does the patch change the way encrypted data is stored on the server?
A: No, the patch changes the way data in transit is cryptographically protected, both encryption and signing is now applied. It does not effect any encrypted data stored on the server.

Q: Are the patches in the download center “smart” enough to know if they are applicable for the machine you apply them to?
A: No, detection capabilities will be built into the patches once they are deployed to WSUS.

Q: Should the update be applied to all .net installation, not just web servers?
A: The vulnerability only manifests itself via web servers. For now it is recommended to only install patches there, and way for the patches to appear in WSUS before patching other .net installs. But remember a system with an unpatched .net installation will become vulnerable as soon as a webserver is installed.

Q: Should the workaround be removed prior to patching?
A: No, you can apply the patch with the workaround in place. If you need to do so you can then remove the workaround after the patch has been applied. CustomErrors generally does not hurt and neither does UrlScan all though UrlScan is known to break SharePoint and may break other web applicaitons as well

Q: Do customer applications need to be recompiled?
A: No.

Scott Guthrie’s blog has an excellent overview of which patch is applicable to which platform.

Paul is best know for his PodCast: Paul dot com and his work as product evangalist for Tennable.

So what do you need to take over the world?

1. Money – Bribes and stuff
2. Power – Ability to control resources to control people
3. Stealth – You don’t want people to know.

So lets work on the first step, how can you use embedded systems to make money? Well, embedded systems are part of video games, settop boxes, wireless routers and printers and faxes. All these systems are used to perform transactions.

The second step, how to we use embedded systems to gain power? Information is power, so if you can manipulate the traffic that flows through the internet you can manipulate it.

Embedded systems are also used to control manufacturing systems, power grids, etc.

Stealth is easy. nobody cares about embedded systems. Embedded systems don’t have room from security so breaking in them is easy and does not set off any alarms.

There about 1.6 million open LinkSys routers in the wild accoording to wiggle.net. At lot of these systems have vulnerabilities in them and/or use default passwords.

It is easy to find vulnerable devices. There are dynamic DNS providers that allow you to get a listing of all Linksys devices (fixed). Or you can e.g. can check for hard coded NTP servers.

Printers often have default password or do not require a default by default. But a printer is just a printer, right? Wrong! They are multifunctional systems that are capable capturing scanned documents, send email and are often connected to the Internet. They even allow you to grep their USB stick.

Paul is collecting security failures at www.securityfail.com

What are the goals of securityfail.com?

• Force users to set a password
• Force ISPs to do security
• Allow users to turn of protocols

Securityfail.com is a non profit project

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.