After I updated to version 1.7. I could not connect to our internal repository anymore. The connection failed with the following error: SSL error: sslv3 alert certificate unkown.

SSL error: sslv3 alert certificate unknown

Our internal respoitory is secured with a certificated issued by our internal CA infrastructure.

Root CA

|
v

Intermediate Certificate

|
v

Repository certificate

Surfing to the svn repository does not produce an error, so the certificate chain is fine. At first I figured that Tortoise was using its own certificate store, but it turns out that Tortoise does use the Windows Root CA store, so there is no need to add the Root CA.

After some more investigation we found out that Tortoise does use the Windows Root CA store to validate the certificate chain, but does not use the Intermediate CA store to complete the certificate chain, like windows does. Since all our client machines have the intermediate certificate in the Intermediate CA store we never noticed that the certificates offered by apache were not chained. After chaining the repository certificate with the intermediate certificate Tortoise was able to talk to the repository again.

You can find the “Blob” values on a patched system (see attached link).

These are all the current Certificates in Internet Explorer (including known fraudulent and new DigiNotar):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\Disallowed\Certificates
\1916A2AF346D399F50313C393200F14140456616
\2B84BFBB34EE2EF949FE1CBE30AA026416EB2216
\305F8BD17AA2CBC483A4C41B19A39A0C75DA39D6
\367D4B3B4FCBBC0B767B2EC0CDB2A36EAB71A4EB
\40AA38731BD189F9CDB5B9DC35E2136F38777AF4
\43D9BCB568E039D073A74A71D8511F7476089CC3
\471C949A8143DB5AD5CDF1C972864A2504FA23C9
\5DE83EE82AC5090AEA9D6AC4E7A6E213F946E179
\61793FCBFA4F9008309BBA5FF12D2CB29CD4151A
\637162CC59A3A1E25956FA5FA8F60D2E1C52EAC6
\63FEAE960BAA91E343CE2BD8B71798C76BDB77D0
\6431723036FD26DEA502792FA595922493030F97
\7D7F4414CCEF168ADF6BF40753B5BECD78375931
\80962AE4D6C5B442894E95A13E4A699E07D694CF
\86E817C81A5CA672FE000F36F878C19518D6F844
\9845A431D51959CAF225322B4A4FE9F223CE6D15
\B533345D06F64516403C00DA03187D3BFEF59156
\B86E791620F759F17B8D25E38CA8BE32E7D5EAC2
\C060ED44CBD881BD0EF86C0BA287DDCF8167478C
\CEA586B2CE593EC7D939898337C57814708AB2BE
\D018B62DC518907247DF50925BB09ACF4A5CB3AD
\F8A54E03AADC5692B850496A4C4630FFEAA29D83

After that you can remove DigiNotar from the Trusted Root Certification Authorities store:

certutil -delstore authroot “c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c”
certutil -delstore authroot “43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3”

On Windows 2008 and newer you have a nifty option in Group Policy:
\Computer Configuration\Policies\Windows Settings\Public Key Policies\Untrusted Certificates

Install the patch on a (local) machine and export the certificates from your “Untrusted Publishers” store as DER encoded, you can import the DER files in the GPO.

Here is the registry hive export from a patched machine, including all certificates and blobs.

cheers,
Matthijs

It all started with this cartoon:

This cartoon basically started a hype about how XKCD was getting “it”. Jason posted a blog post stating that he did not agree with XKCD since:

• While four words in theory have 44 bits of entropy (2⁴⁴), it is actually 250,000 to the power of 4 (250,000⁴) since English only has 4about 250,000 words
• Most people actually would use three words, giving 15,625,000,000,000,000 combinations
• Most people know even less then 250,000 words

So what is my take on this? The key to “it” is at the bottom of the cartoon:

“Through 20 years of effort, we’ve successfully trained everyone to use passwords that are hard for humans to remember, but easy for computers to guess”

This is really the “it” XKCD does get.

So why do we use password policies in the first place? What problem are we trying to tackle?

First of all we are trying to tackle the problem that users are very bad a picking good password without guidance. This tweet illustrates that:

If you don’t give users guidance they will often pick from a set of very well known passwords. But more recent research shows that since the average person has over 50 passwords, some with and some without password policy on it, most people need a coping strategy to deal with this.

In my talk “The Road to Hell is paved with best practices” I give this example of likely passwords for a certain password policy:

• 7 characters: welcome
• 7 characters + 1 capital: Welcome
• 7 characters + 1 capital + 1 numeral: W3lc0m3
• 7 characters + 1 capital + 1 numeral + 1 special: W3lc0m3!
• 10 characters + 1 capital + 1 numeral + 1 special: W3lc0m3!!!
• 10 characters + 1 capital + 1 numeral + 1 special, 30 days max, cannot reuse last 12: Welcome01!, Welcome02!, Welcome03!, etc

As security people we need to understand that each security measure will alter peoples behaviour and sometimes not for the good.

Studies have shown that even if password policies are used, probabilistic techniques can be used to aid in password cracking attacks, that password expiry is only of limited use, that password expiry policies do not meet their goal.

Experiments with an online windows password cracker showed that “hard” passwords do not take longer to crack that “easy” passwords when rainbow tables are used:

• Empty password – 2 seconds
• 72@Fee4S@mura! – 5 seconds
• (689!!!<>”QTHp – 8 seconds
• *mZ?9%^jS743:! – 5 seconds
• T&p/E$v-O6,1@} – 11 seconds

So what is my opinion?

Security policies have driven people to the top of their ability to remember passwords and as users have got increasing amounts of passwords the behavior it induced did not improve matters. We need to tune some of these measures down and replace them with education.

Passwords should be:

• Relatively long
• Not guessable (correcthorsebatterystaple is not o.k. anymore thanks to XKCD)
• Your system should block guessing attempts or really slow them down

If hackers have you password hashes you are toast…

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.

Black Skimmer Rynchops niger Skimming a cc by image from marlin harm's Flick stream

By Adam Laurie and Daniele Bianco

Slides on the HitB Materials page.

So what is EMV it stand for Europay, Mastercard and Vista and is a new security statndard for credit cards.With the introduction of EMV the liabiliy moved from the merchant to the cardholder because fraud is thought to be unlikely.  However EMV has allready been proven to be broken. E.g. Murdoch et. al. have proven that it is possible to use a stolen card without knowing the PIN.

This talk focuses  on the ability to still skim a EMV credit card, without reading the magstripe (which is very often still present).

Skimming a chip card may be more interesting because the user cannot see the interface and thus cannot detect the skimmer. The time effort to install a smartcard skimmer is quite small.

The industry perceives these tools as complex, but that is not true. Devices are small, easy to install and hard to detect.

It is possible to clone the track 1 and track 2 magnetic stripe data from publicly readable data of EMV chip. Luckily not all EMS cards support this.

So magnetic stripe data can be stolen and a stolen card van be used without a PIN, but is it possible to do PIN and magnetic stripe harvesting with EMV cards.

The CVM list on the card, which is digitally signed, tells the terminal how to authenticate to the card. The PIN is only sent to the card is the card specifies this in the CVM list.

However it turns out that, under certain circumstances, PoS terminals do not correctly detect a tampered CVM list and thus will present the PIN in plain text even if the CVM state this shouldn’t happen.

Adam and Daniele then demonstrate the tools they have developed to actually copy a card and u

He began his professional career during his early years at university as system administrator and IT consultant for several scientific organizations. His interest for centralized management and software integration in Open Source environments has focused his work on design and development of suitable R&D infrastructure. One of his hobbies has always been playing with hardware and electronic devices.

At the time being he is the resident Hardware Hacker for international consultancy Inverse Path where his research work focuses on embedded systems security, electronic devices protection and tamperproofing techniques. He presented at many IT security events and his works have been quoted by numerous popular media.

About Adam Laurie

Adam Laurie is a freelance security consultant working the in the field of electronic communications. He started in the computer industry in the late Seventies, working as a computer programmer on PDP-8 and other mini computers, and then on various Unix, Dos and CP/M based micro computers as they emerged in the Eighties. He quickly became interested in the underlying network and data protocols, and moved his attention to those areas and away from programming, starting a data conversion company which rapidly grew to become Europe’s largest specialist in that field (A.L. downloading Services). During this period, he successfully disproved the industry lie that music CDs could not be read by computers, and, with help from his brother Ben, wrote the world’s first CD ripper, ‘CDGRAB’.

At this point, he and Ben became interested in the newly emerging concept of ‘The Internet’, and were involved in various early open source projects, the most well known of which is probably their own ‘Apache-SSL’ which went on to become the de-facto standard secure web server. Since the late Nineties they have focused their attention on security, and have been the authors of various papers exposing flaws in Internet services and/or software, as well as pioneering the concept of re-using military data centres (housed in underground nuclear bunkers) as secure hosting facilities.

Adam has been a senior member of staff at DEFCON since 1997, and also acted as a member of staff during the early years of the Black Hat Briefings, and is a member of the Bluetooth SIG Security Experts Group and speaks regularly on the international conference circuit on matters concerning Bluetooth security. He has also given presentations on forensics, magnetic stripe technology, InfraRed and RFID.

He is the author and maintainer of the open source python RFID exploration library ‘RFIDIOt’, which can be found at http://rfidiot.org. Adam is a Director and full time researcher working for Aperture Labs Ltd., specialising in reverse engineering of secure systems.

Steve Jobs for Fortune magazine a cc nc nd image from tsevis's Flick stream

By Jean-Baptiste Bédrune and Jean Sigwald

Slides on the HitB Materials page.

This talk is about data security and the iPhone. Almost all iPhone like deices (excluding the iPad2 for the moment) can book usigned code when they are in recovery mode. It is also possible to create acustom ram disk, thee are techniques used by jailbreakers and phone forensics people.

Data in the iPhone is encrypted with either the UID (unique iPhone key) or GID (key unique to each model).

In the iPhone (iOS < 4) the UID key was only used  to facilitate fast wipe (change key, cannot read flash anymore), it did not provide data security. The iPhone 4 was designed with data security in mind. Jean and Jean demonstrate the tools they wrote to get around the data protection of iOS 4

Because the unlock code is used for data security data can be set to be only available when:

• The Phone is unlocked
• After the phone is unlocked for the first time
• Always

In iOS 4 there is an escrow key which allows MobileMe and iTunes to access the phone for backup or passcode reset without unlocking the phone.

The first tool that they developed and demonstrated was the keyChainViewer which can be used to view the contents of keyChain, but not the keys.

Using the built in iOS functions (that use the passwcode) you can actually bruto force the passcode of the phone with a small application on the phone. If you boot the phone from a ram disc you can do this without knowing the passcode. Using the brute forced passcode the keyChain can be read and decrypted.

Next tools where demoed to browse the encrypted filesystem and to decrypt iTunes backup files.

Conclusion of the researchers:

• iOS4 offers far better protection then iOS3
• Mail files (with the exception of exchange) are protected by the passcode this offers additional protection, but it can be obtained if you have the phone

Tools are available on http://code.google.com/p/iphone-dataprotection/

About Jean-Baptiste Bédrune

Jean-Baptiste works at the Software security R&D team at Sogeti for 4 years. His domains of research include code (un)protection, audit of DRM solutions, applied cryptography, reverse engineering on embedded devices and distributed computing. Jean joined Sogeti in early 2010. His research topics include reverse engineering, embedded devices and smartphones security.

About Jean Sigwald

Jean Sigwald is a security researcher working at Sogeti ESEC R&D lab. His research is mainly focused on smartphones security and the services offered by the network operators.

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

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.

The Key to My Mind (11/12) a CC image from Tony the Misfit's Flickr stream

The private key is supposed to be private. It is what proves that the services and the certificate belong to each other. As an attacker you want to obtain this key in order to spoof the identity of the service.

When you import a certificate with private key or generate a private key via the Microsoft Crypto API (CAPI) you can mark it as non-exportable. But are these keys really non-exportable or is this just a GUI option to give administrators a false sense of security?

In order to find out how an attacker can export a non-exportable key RSA key, we need to dive into the CAPI calls.

Disassembling the CAPI functions shows that there are flags in memory that specify that the key is not exportable. It appears that these flags are stored on the same memory location and user the same function. And you can actually temper with this information and set these flags back to being exportable.

The situation is a bit different in the CAPI: Next generation (CNG). Again a disassembly of these functions shows that the CliCryptExportKey() via the c_SrvRpcCryptExportKey function get the private key from the KeyISO or KeyIsolation RPC service that is meant to isolate the RSA keys from the client memory.

It turns out that the memory of the lsass.exe process can reliably be manipulated to make the SPPkcs8IsKeyExportable function return 1 and thus allow the key to be exported.

In both CAPI and CNG the offsets to the flags are the same across the last 11 years of Microsoft products.

Jason has demonstrated the technique live on stage.

The code as well as the slides will be released to the www.blackhat.com website together with the presentation slides shortly.

Conclusion:Non-exportable keys are a GUI feature, they do not prevent a attacker from getting the key, they just slow him down.

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.

Miniature Dotted Hot Pink Cake a CC NC ND image from - Stephanie Kilgast's Flicker account

on in security tools. There are some tools that have some visualization, but it is limited and lacks features.

He then takes us through the hall of fail of visualizations and gives us some tips on visualization.

Thinks as a designer, be aware of who you are visualizing for. Each group has different demands for visualization and want to take different things out of it.

He then proceeds to give us some tips and tricks. He recommends to follow the work of Edward Tufte and Stephen Few who have both done excellent work on data visualization.

If you do data visualization you may want to get data from external reports like osvdb.org datalossdb.org and other industry vendors.

Common problems of data visualization are redundant elements like 3D and color. This is expressed in the ink-to-info ratio. You may want to reduce the bell and whistles you use.

Dashboards are often messy, they should really be aware of their screen real estate. Most important places on the screen are top left and the center of the screen. In order to squeze as much info as possible into a dashboard dashboard often get messy.

Wim presents a number of idea’s on how to make these dashboards better.

Visualization can really aid as well. Wim is showing use visualization tools that can really help.

First, Wim shows us a video that represents an attack on a VOIP server. The movie was created using gltail and can be downloaded from http://www.fudgie.org/.

Afterglow is another tool used b Wim a lot, it creates visualization that can really aid understand log files.

Perl perl | chart director which can also help to create understandable graphics form complex data charts.

The Google charts API and Google Visualization API may be a good alternatives as well. Wim demo’s the visualization capabilities of the Google Visualization API by using publicly available data and visualizing it. Naturally you have to be careful of what data you send to a could provider such as Google.

Sparkline and JQPlot are interesting JQuery libraries you can use for data visualization in a good way without sending it to a cloud..

Conclusions:

• We need data standardization to get more out of visualization
• You need to understand data before you can successfully visualize it
• We need to think outside the gox
• There is more to visualization then pie charts
• There are tools out there: use them wisely.

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).

But what if you have an issue with NFS and you need a network dump? 

In ESXi tipically you don’t have a local datastore where you can write files from the network dump and your datastore over NFS is not availabe!

Before running into the Data Centre and stick a USB disk or even better a SCSI disk you might want to try this.

One trick I used that worked out pretty well for me, with a little help of my a linux machine, is to send the tcpdump output to a FIFO and from a remote host (might be a VM in a different ESXi host) over SSH cat the FIFO to a local file.

How To:
On the ESXi host logon via SSH as root and create a named pipe:

root@yourESXihost# mkfifo /tmp/pipe.dmp

and from a remote linux machine launch the following:

you@yourlinuxhost > ssh root@youresxihost "cat /tmp/pipe.dmp" > capture-for-wireshark.cap

Now from a new ssh session to ESXi as root lauch

root@yourESXihost# tcpdump-uw -n -s 1524 -i vmk# -w /tmp/pipe.dmp

OR even better from the remote machine:

you@yourlinuxhost > ssh root@youresxihost "tcpdump-uw -n -s 1524 -i vmk# -w /tmp/pipe.dmp"
(replace the # with the proper vmk port number)

Reproduce your issue and when you finished just hit  “Cotrol+C” to stop the network dump and the cat.
Now you can open your file directly in wireshark (that’s what I use at least!)

This little trick of course can be used to troubleshoot network problems in a VM as well, dumping the traffic from a VMK# nic for the entire dvPortGroup. You just need to make sure that the the VM’s vNIC and the vmk# nic are connected to the same dvPortGroup and you must remember to allow promiscuous mode (not allowed by default)

Good Luck!

Please note: your network can be very chatty so the file can grow very fast and/or your ESXi host might not like the tcpdump so use it at your own risk and only if you really know what you are doing!

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