Details about how MD5 weaknesses especially what is refered to as known prefix collisions were used to help to compromise the trust put into one of the CA's that is builtin major browsers :
http://www.win.tue.nl/hashclash/rogue-ca/

Quick Summary:
Not all CAs using MD5 are automaticaly broken, three things were required :
- MD5 signed CA
- prediction of the Serial Number (RapidSSL increments by one)
- prediction of the certificate validity date (RapidSSL issues always 6 second after your press the button.
- A way to find collisions fast enough

Only with these 4 things in place it was possible to pull this off.

More information :

History:
2004 - first attacks against md5
2006 - Colliding PKCS Certificates http://www.win.tue.nl/~bdeweger/CollidingCertificates/
2007 - know prefix collision attacks against md5 futher speeding up the time it takes to find collisions.

Basicaly the stage for the attack shown this year at 25c3 attack was already set in 2006 however the Serial number + Validity period were a problem, because you don't know where they are (in the data) in advance.

So how to reduce the entropy (uncertainty what the validty of the certficate is) ? They found a way to use the RAPIDSSL autonomous system which gives the certificate extactly 6 seconds after you click the I approve button.

What about the Serial number? How to predict the serial number ? RapidSSL just incremented the serial number by one...

This means they potentialy could predict the serial number,however they need three days to bruteforce the collisions - so they needed to get the serial number right for that date - they choose sunday night because the entropy introduced by customer buying certificates hindered the process of hitting the sweet spot.

The required 4 attempts, the three previous times someone else got the Serial Number they targeted.

The question what happens with certificates that use MD5 checksums have been
openly asked (and tried to be answered) in 2005 as shown here :
http://www.cryptography.com/cnews/hash.html

Summary :
Academic research + hacker ingeniousty at it's finest. We need more of it. Awesome.
This only worked because RapidSSL incremented the serial number by 1 and they could predict the validity date.

So, in other words : Remove (or edit the Trustsettings) for the following CA's -

Firefox :
* RapidSSL
C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1
* FreeSSL (free trial certificates offered by RapidSSL)
C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Network Applications
* TC TrustCenter AG
C=DE, ST=Hamburg, L=Hamburg, O=TC TrustCenter for Security in Data Networks GmbH, OU=TC TrustCenter Class 3 CA/emailAddress=certificate@trustcenter.de
* RSA Data Security
C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
* Thawte
C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
* verisign.co.jp
O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign International Server CA - Class 3, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign


(Thanks to Security4all)

Relates to this story :
http://www.pcworld.com/article/155190/new_web_attack_exploits_unpatched_ie_flaw.html

Here is the extracted shellcode from the IE7 0day referenced above.
XOR encoded payload for analysis - compile and run it through Ollydbg.
http://secdev.zoller.lu/research/shellcode_ana1.c

The decrypted shellcode is available for download here :
http://secdev.zoller.lu/research/decrypted_asm_shellcode.txt

Update
I was not interested in posting the 0day, but somebody choose to do so on milw0rm.com, so I might aswell link there : http://milw0rm.com/sploits/2008-iesploit.tar.gz

Update2
HDmoore posted a nice analysis here : http://www.breakingpointsystems.com/community/

Update 3
11/12/2008 - 04:19
5 out of 32 scanners recognising the 0day in HTML form
http://www.virustotal.com/de/analisis/596d88d57bc91d977f037f317eb9aa99

11/12/2008 - 17:34
7 out of 38 scanners recognising the exploit
http://www.virustotal.com/en/analisis/a68e1c2813483a58cfdd6509ccd8fe5e
http://virscan.org/report/4907067f0f0aab53261348413dea9bc9.html

12/12/2008 - 17:04
11 out of 38 scanners recognising the exploit
http://www.virustotal.com/de/analisis/475269215b8379537e45a8fd94f8dc9c
http://virscan.org/report/7a00119178654949124b62e85d2a42c8.html

13/12/2008 - 17:00
12 out of 38 AV engines recognise the exploit
http://www.virustotal.com/en/analisis/286266a9e8096ef17bb1aa6f15a1a31f

14/12/2008 - 19:45
14 out of 38 AV engines recognise the exploit
http://www.virustotal.com/en/analisis/5e8909eea79dc716caac8af09f22ac3f
http://virscan.org/report/47f8b4811744eaebb7d48fcc942009cb.html

15/12/2008 - 18:25
Still 14 out of 38 AV engines recognise the exploit
http://www.virustotal.com/de/analisis/592728a9493349692fc2b33e799a6a33

16/12/2008 - 18:25
15 out of 38 AV engines recognise the exploit
http://www.virustotal.com/en/analisis/28208f37d1d2c732be026a9a2990c86e

17/12/2008 - 18:25
Still at 15 out of 38 AV engines recognise the exploit
http://www.virustotal.com/de/analisis/2fa1f88d9a1372f023844af40911c83e

19/12/2008 - 16:04
18 out of 38 AV engines recognise the exploit
http://www.virustotal.com/de/analisis/2d23479870f34a8786f3229da5db23cf

20/12/2008 - 16:04
19 out of 38 AV engines recognise the exploit
http://www.virustotal.com/de/analisis/6f21e0dffcc117b695324ed93cd7a803

21/12/2008 - 16:04
20 out of 38 AV engines recognise the exploit
http://www.virustotal.com/en/analisis/6dd28dced88f1c8982503e8547d5ef01

22/12/2008 - 16:04
21 out of 38 AV engines recognise the exploit
http://www.virustotal.com/en/analisis/37537b52f8d4584fb1d294f3ccc0b385

23/12/2008 - 16:04
21 out of 38 AV engines recognise the exploit
http://www.virustotal.com/de/analisis/e22efb9c30a1e7e911466b0194d2f279

24/12/2008 - 16:04
22 out of 38 AV engines recognise the exploit

http://www.virustotal.com/de/analisis/9ee7bf2ca2aa85b6de52a08d1e417a15

26/12/2008 - 16:04
22 out of 38 AV engines recognise the exploit (Result misses Securecomputing)
http://www.virustotal.com/de/analisis/40439a3a049d46623cfffd7e2ed05c92

27/12/2008 - 16:04
22 out of 38 AV engines - (Result misses VBA32)
http://www.virustotal.com/de/analisis/5a8e26b11632745dc8c5742d5403b8ec

28/12/2008 - 16:04
22 out of 38 AV engines - (Result misses VBA32)
http://www.virustotal.com/de/analisis/89fdc7975178090411d72b167e4420e8

30/12/2008
21 out of 38 AV engines - (CA) E-trust no longer recognises the sample, Esafe missing
http://www.virustotal.com/de/analisis/a6e158b4cdca3da09480fdd4c49e5934

Dear Vendor,

You probably reached this page because I referred to this policy when I reported a vulnerability within your products. This policy represent the terms under which I am willing to coordinate disclosure with you.  Should you not be able to meet the requirements please notify me beforehand so we can discuss your concerns. Failure to do so might result in immediate disclosure of my analysis and  vulnerabilities. 

The rationale behind this policy (and ultimately it's reasoning) is that I am obliged to protect the customers, end-users as well as you the vendor.

The likelihood of rediscovery of vulnerability is a  proven fact and likely to be relatively high. The longer the time frame between discovery and patch the higher the chances this vulnerability is (re)discovered and used by malicious entities against you and/or your customers.

Source: Jason

Please understand that this is a free service too you, I have not sold the information on the open market [1, 2] and have taken the time to report it to you. I am trying to help you protect your customers. 

If you don't consider the bug I reported to be a security bug, it will be published without further coordination (see here). 

The reasoning behind this action is simple, you made this choice with full access to your product code and ressources and decided that my report represents solely a bug that poses no risk to your customers - hence the publication of it cannot possibly pose an issue to you.

Things to be communicated in order to correctly inform your customers and myself correctly:

• Affected product ranges, including exact version information.
• Advisory location and patch release schedule
• CVE number

Begin of Terms/Policy 

___________________________________________________

You are not allowed to share any details, proof of concept files with other vendors, irregardles of what your own policy or even terms say. I own the copyright on the code/examples and anything else submitted, regardless of your terms.

Should a request from a third party reach you, please simply forward it to myself, I will happily provide further details and work directly with these vendors.

1. If no security contact is known for the vendor and no security contact can be found at HackerOne, an e-mail requesting the security contact e-mail address may initially be sent to certain public e-mail addresses associated with the vendor. Online forms may only be used to request security contact information.
2. When a security contact or other relevant e-mail address has been identified, a vendor initially receives a mail with vulnerability details along with a pre-set disclosure date (usually set to a Wednesday 4 weeks later). 
3. If the vendor does not respond to the initial mail within a week, it is resent. 
4. If no response has been received at the day of the pre-set disclosure date, the vulnerability information is published immediately without further coordination attempts. 
5. If the vendor responds to either the initial mail or the resent mail, a new disclosure date may be set in case the vendor cannot meet the pre-set date.
6. I expect to receive continuous status updates from the vendor and a list of all affected products. Should no list be given it is assumed all products are vulnerable. 
7. Should a vendor not respond to a status update request, it is resent.
8. Should the vendor not respond to two consecutive status update requests, a mail is sent to the vendor advising that the vulnerability information will be disclosed a week later if no response is received. Has no response been received by this date, the vulnerability information is immediately published without further coordination attempts.
9. Eventually, the vulnerability information will be published if:
   a) The pre-set/agreed disclosure date is reached.
   b) The vendor issues a fix and/or security advisory
   c) Information about the same vulnerability is published by a third party.
   d) A year from the initial contact date has passed
   e)The vendor denies the security nature of the bug and/or gives no credit or other form of compensation 
10. Unless the vendor asks for an extension, I will not coordinate a vulnerability disclosure for more than 5 months. After 5 months the details will be published regardless of patch availability.

Additional Clauses 

Transparency clause: You may be quoted or the complete e-mail communication may be published if I deem it necessary.

____________________________________________

END of Policy/Agreement

I stumbled across this info when looking for a Javascript-debugger similar to Firebug for IE.

MSE7 is nothing short of a full blown script debugger in an Visual Studio outfit, it ships with Office 2003 SP3 : Filename found here.
How to enable the debugger :
Uncheck the options:

Tools->Internet Options…->Advanced->Disable Script Debugging (Internet Explorer)
Tools->Internet Options…->Advanced->Disable Script Debugging (Other)

The debugger itself looks like this:

Talk:

http://technet.microsoft.com/de-de/security/dd285253.aspx

Interview :
Silverlight Video (Impressive quality)
http://technet.microsoft.com/en-us/security/dd285260.aspx

WMV download:
http://mediadl.microsoft.com/mediadl/technet/s/security/BHInt_MattMiller.wmv

If your into Network captures and forensics you really should take a look at the FREE version of Netwitness (released today) - Give it a try, it is versatile enough that it should give you benefits over wireshark also for pentests.

Video below :



http://download.netwitness.com/download.php?src=DIRECT

For those who want an extra layer of bruteforce resistance for authentication shemes that support unicode (NTLM2 for example) : Why not try to flip some, or all characters of the password up side down ?

There is an online tool to help you convert the appropriate strings to unicode, the site is called ǝlʇıʇdılɟ : http://fliptitle.com/

Update (added below)


Paper released : http://dl.aircrack-ng.org/breakingwepandwpa.pdf

It's all over the place - WPA cracked.

Here is why it isn't (yet):

• Attack does not give you access to the data transmited
• Only the TKIP keystream is being recovered
• Besides WPA-PSK-TKIP there is WPA-PSK-CCMP which is not vulnerable - so even if WPA-PSK-TKIP would be broken there still is WPA-PSK-CCMP, so WPA is not dead.
  

Temporal Key Integrity Protocol (TKIP) is nothing else then our good old friend RC4 (same as used in WEP, yep) with the difference that the KEY changes every 10KB packet,

hence the name (Temporal). Another change was to add the MAC into the calculation making it basicaly a salt that results in different key set with the same IV (Initialisation Vector). This also reduces the possibility of a replay attack.

What the author basicaly says is that they found a way to :

- have the AP generate LOT of traffic, meaning lot of encrypted datapackets you can

then use a new way to bruteforce TKIP

Quote :
They have not yet, however, managed to crack the encryption keys used to secure the data that travels from the PC to the router.

In my book not crack the encryption keys means...well wpa is not cracked.. I can't say more until the airodump-ng SVN repositry is reachable, part of the code is already in there.

Update :

Facts :

• Currently the attack only affects TKIP (not ccmp) gives access to one keystream, no keys are recovered but it allows for decryption of short individual packets ie DNS, ARP (sounds like known plaintext to me)
  
• Allows reinjecting of short (ARP, DNS) packets or packets there is a small amount of unknown data
  
• If you use AES mode you are perfectly safe

Assumptions :

• more traffic may render the attack impossible (as rekeying happens)
• setting to rekey on intervals also is a mitigation to those who have to use WPA
  

My recommendation on Wi-Fi still is valid and is totaly safe (until further notice) :

• Home User: Use WPA2 (AES - CCMP)
• Enterprise : Use WPA2 EAP2-TLS

History :
The history of wireless standards is a mess to say the least: IEEE was to slow for AP vendors so they created the Wi-Fi alliance, and pushed for their own names staying compatible with IEEE one way or another :

- WEP (RC4)

- WPA-PSK TKIP (RC4) AND WPA-PSK CCMP - which is not vulnerable (afaik not certified but exists)

- WPA2 (AES, CCMP,TKIP or Enterprise - EAP, TTLS)

http://lists.shmoo.com/pipermail/hostap/2006-August/014137.html :

Both TKIP and CCMP can be used regardless of which version of WPA is used.
WPA was not certified with CCMP, but WPA2 certification includes tests for
both TKIP (only for backwards compatibility with WPA) and CCMP.

An excellent write-up from SID (rstack) can be found here (french) : http://sid.rstack.org/blog/index.php/304-tkip-comment-ca-marche

According to Koby Kahane, somebody made an whooopsie @ Microsoft as private debugging symbols were included in the VS 2010 Beta. :)

What are private debugging symbols ?

Public debugging symbols are stripped versions of the original private symbols generated by the build process. They do not contain parameter information and do not contain the names of local variables in functions.

Link :
http://kobyk.wordpress.com/2008/10/29/oops

More info : http://www.carrotmob.org/

The sky last evening over here :)

My colleague Alexios gave a talk about evading XSS filters at the recent OWASP conference, what strikes me is the multitude of ways you can do it. I am sure you find something you didn't know when watching it :

http://iase.disa.mil/stigs/checklist/dod_bluetooth_headset_security_requirements_matrix_v2-0_7april2008.pdf

NIST recently published the Special Publication 800-121 "Guide to Bluetooth Security". I skim read it and while it certainly is a good overview it seriously lacks in some areas. Unfortunately I concentrated on other areas than bluetooth the last year and after doing the 23C3 speech and publishing BTCrack I have not really dug further. Maybe it's time to digg into it again a bit more.

Need an argument to sell a secure development lifecycle to upper management ?
Present them this (probably) hand drawn scientific chart:

I expect this chart to be somehow close to reality when refering to large and mature software projects, although it's soooo interestingly non-scientific ;)

If you're interested in attaching a debugger everytime a particular process is started in windows use :

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\myapp.exe

Debugger = REG_STRING c:\debuggers\windbg -g

PS. This represents als an autostart vector in use by certain malware.

Here is a picture of my next mid-term project :

Https connections are often used to transfer important data, such as passwords, PINs, or credit card numbers. The browser ensures that the sender can be identified with a valid certificate and that the transferred data are encrypted. An error in the Debian Linux distribution has generated numerous certificates that are child's play to crack. Many servers still use these weak certificates, even though it is impossible to establish a secure connection using them. The heise SSL Guardian checks the SSL certificates and warns you when it detects a weak one.

Download :
http://www.heise-online.co.uk/security/Heise-SSL-Guardian--/features/111039/

Together with the server-side stripslash() php function this call slips through the IE8 XSS filters because it strips the slashes server side and such evades IE8 detection when the HTTP request is being sent by IE8:

See: http://www.0x000000.com/?i=634

Sensepost released their JSP/PHP/ASP pivot/covert channel named reDuh :

Basic concept :

• Glenn has the ability to upload / create a JSP page on the remote server
• Glenn wishes to make an RDP connection to the server term-serv.victim.com (visible to the web-server behind the firewall)
• The firewall permits HTTP traffic to the webserver but denies everything else

http://www.sensepost.com/research/reDuh/

Skape released whentrust as opensource :
http://www.codeplex.com/wehntrust

Thanks skape and good luck at MS

PS. Don't underestimate Whentrust, even with Windows2003 and Hardware NX it still increases protection (nx pages)

There are quite a few sql injection tools around, Pangolin is one of the most sophisticated blind SQL injetion tool I have come across, you can find it here :Pangolin Enjoy

For those into RCE, you surely came across Themida and know it can be a bitch.
Here is the PEB hooking loader from ARteam :

1. you will need to build fake_kernel32.dll and fake_advapi32.dllsolutions, and 2 dlls will be created in ..\..\fake\ folder.
2. in ..\..\fake\ folder you have adjust_fake.exe which you MUST use onnewly created dlls to get valid import table for kernel32/advapid32.dll
3. rebuild themida loader project, as fake_kernel32.dll and fake_advapi32.dllare stored in resources of themidaloader.exe
   

Another nice ARTeam release : http://arteam.accessroot.com/releases.html

Addendum :in other news ARTeam is hooking Services .exe To Hide Softice

Here is an old but still relevant and nice description on how to analyse a session ID (cookie, session value) from scusi , includes all required code.



@scusi

http://www.nullcode.com.ar/ncs/crash/nsloo.htm

What was theoretically feasible has been practically tested : "BIND used fully randomized source port range, i.e. around 64000 ports. Two attacking servers, connected to the attacked one via GigE link, were used, each one attacked 1-2 ports with full ID range. Usually attacking server is able to send about 40-50 thousands fake replies before remote server returns the correct one, so if port was matched probability of the successful poisoning is more than 60%. Attack took about half of the day, i.e. a bit less than 10 hours."

More Info :
http://tservice.net.ru/~s0mbre/blog/devel/networking/dns/2008_08_08.html

Here is an interesting flaw called "Surfjacking"

Pre-requisites :

• Take a MitM situation
• Take a site that uses Cookies for Session handling
• Take a site that does not set the "secure" cookie flag.
  

Result :

• Victim logs into https://www.somebank.com/
• Session cookie is generated and set on the client
• Victim visits another website (http://www.example.com)
• The MitM attacker sees clea text traffic to www.example.org
• Attacker sends a 302, or "301 Moved Permanently" to “Location: http://www.somesecurebank.com/”, . Note the HTTP (not HTTPS).
• Victim browser follows the redirect and sends session cookie to http://www.somesecurebank.com in clear text.
  

Recommendation:

Set-Cookie: NAME=VALUE; expires=DATE; path=PATH;
domain=DOMAIN_NAME; secure

as such the cookie will not be sent to the HTTP site - simple fix, pay attention to this during your next pentest.

Whitepaper : Surf Jacking.pdf

Video :

Sandro Gauci

Here is the white paper and the slides to Mark Dowd & Alexander Sotirov Talk "How to Impress Girls with Browser Memory Protection Bypasses" - a must read :

Especially the whitepaper has some interesting details.

Whitepaper :
http://taossa.com/archive/bh08sotirovdowd.pdf

Slides :
http://taossa.com/archive/bh08sotirovdowdslides.pdf

Who am I to disagree : I think the lack of quality only partially has to be accounted to the prices being paid for 0day, 0day in terms of bugs are rarely being presented at conferences. I think the security market has become crowded and noisy, press is jumping more and more on it security over the last 5 years and have not been helping to increase quality but sensationalism. See DNS bug vs. SNMPv3 bug. I also think that time is increasingly getting spare to prepare for such conferences (this implies research) for every researcher there are 5+n consultants. Anyways that's the reason I have not been at BH or Defcon this year - last year really sucked.

PS. The 100k price tag for an SSH 0day is too low by the way.

After the dns + evilgrade fiasco I hope that insecure auto update functions are taken as serious as they should always have been Back in 2006 I warned about it when reporting that Zango Adware was downloading and executing udaptes without checking for authenticity. Zango fixed it eventually, my scenario I illustrated back then however was seen as unlikely event. Fast Forward 2 years - oops.

What is of more concern is that adware update process seems to be more "secure" in 2006 than adobe acrobat is in 2008. ouch.

Here are the slides and the code from the Blackhat USRP talk :
http://ossmann.com/bh-usa-08/