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