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

By Dan Kaminsky (@DaKaMi)

In his talk Dan addressed why web security is hard, but he also tries to to come up with solutions.

One of the solutions explorer is referrer checking. If you think you cannot use them because they can be spoofed? No, referrer tags have been pretty much un-spoofable, however, not each and every call to a website contains a referrer header. One of the problems is that security solutions such as Symatec Internet Security strip referrer headers.

Since we cannot rely on the server site to detect this, maybe we should turst the client. Even if common lore says: “thou shall not trust the browser”.

It appears that the browser is the only one that can actually detect CSRF and XSS. Is it possible for the interpreter to commit suicide if it sees an “evil” request. By using the very definition of javascript to abort the interpreter by keeping it hung up in the first javascript block on the page.

Does this stop XSRF, not because XSRF does not require a return apply, however, the server could actually send a bit of javascript back on the request. It turns out the object.send() method can be overloaded to insert an extra header. So what can we do to use this extra header? There are a lot of methods that don’t work, but what does work?

Unfortunately there does not seem to be a session/domain context variable where we can store our magic cookie.

Another problem Dan tried to address was input validation.

Using regular expressions to do input validation is, the reasons the ha.ckers.org cheatsheet for XSS works is because regular expressions don’t.

Parameterization, Pascal Strings and Tain Checking don’t work.

Mime seems to provide the answer here: Randomzied closing tags, dubbed Tree Locking by Dan. There is however a risk, because of the xml.findAll() method that can be made to return any tag, regardless of which tag it was embedded in.

JSON doesn’t even use named closing tags. One could use comments, but these are not supported by JSON. But, by embedding the data into a base64 string because it cannot be predictable guessed.

It doesn’t just work just work for JSON, it works for XML, SLQ and LDAP as well. It actually adds back type safety in the browser.

Unfortunately Unicode bytes back.0XC0 0×80 is an over wide null character. It is interprited by the Microsoft Crypto API.

Base64 encoding will actually neutralize these unicode attacks. Untimely this code needs to go into the database engines. E.g with a special encapsulation routine.

Since the root CA is in another domain then the issuing CA, it took some fiddling and tweaking around with my CDP and AIA extensions, but that is another blogpost all together.

I knew I was in for some fun when when the following happened:

• I installed my Issuing CA and generated the certificate request
• I issued the request to my Root CA and generated the Issuing CA certificate
• I tried to install the Issuing CA certificate and got the following error:

Cannot verify certificate chain. Do you whish to ignore the error and continue? The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2168885613)

My first reaction was to call one of the network guest and notify him that I needed http access to the Issuing CA to the CDP location. But whil on the phone, I decided to try and to my surprise I was actually able to manually pull down the crl.

Intregued, I decided to check a few things:

• I could download the CRL from both CDP locations with Internet Exporer
• I could open the downloaded CRLs
• I could telnet to port 80 of the both webservers
• I could telnet to port 80 manually issue the GET /crl/CRLname.crl HTTP/1.0 command and get data back

O.K. what is going on here… Lets open PKI view, which is now included in Windows 2008 and Vista and can be downloaded for Windows 2000 and 2003.

It seemed that PKI view as in agreement, it too could not download the CRL from the CDP location

PKI view shows "Unable To Download" for both CDP locations

This did sent me on a wild goose chase:

• Microsoft own documentation, clearly blames it on unavailability of the CDP location, something I, by now, had triple checked four times and refused to believe
• This “Network Builders” forum and many others, simply suggest to turn off revocation checking, but that is clearly not a worthy solution either.
• Apparently there is also an issue with serving delta CRLs threw IIS because the + sign at the end of the basename of a delta CRL file leads to so called “double escaping”. I could rule this out by looking at the IIS logs.
• In the end this technet forum post, about OCSP reponders Brian Komar points out:

But, as stated, I would use certutil to get the “best” answer on how is my configuration.
Certutil -verify -urlfetch “certfile.cer” will check *every* CDP and AIA URL (including OCSP) and tell you how they are all doing *at that specific instance in time” since it goes to the URLs immediately.
Brian

I exported the Issuing CA certificate from the certificate database of the Root CA and ran the command against is and this is what I found

E:\>certutil -verify -urlfetch <certfile>.cer
Issuer:
CN=Root CA
Subject:
CN=Issuing CA
Cert Serial Number: 115d5f6400020000000b
<snip>

—————-  Certificate AIA  —————-
Verified “Certificate (0)” Time: 0
[0.0] http://IIS1.domain1local/crl/Root-CA.crt

Verified “Certificate (0)” Time: 0
[1.0] http://IIS2.domain1.local/crl/Root-CA.crt

—————-  Certificate CDP  —————-
Wrong Issuer “Base CRL (13)” Time: 0
[0.0] http://IIS1.domain1.local/crl/Root-CA.crl

Wrong Issuer “Base CRL (13)” Time: 0
[1.0] http://IIS2.domain1.local/crl/Root-CA.crl

<snip>
E:\>

So while PKI view and the other error messages I was getting all pointed to the most common cause, it actually turned out that the CRl did get downloaded, but was not cryptographically relevant to what the system believes is the Root CA certificate.

Root cause

Inspection of the CRLs generated and the Root certificates installed showed what had caused the problem. In order to test the CDP extensions I had reissued the Root CA certificate, causing the Root CA to have three active certificates. Each with a different key.

This CA has three CA certificates

When validating the Issuing CA certificate, validation would end at the last certificate issued, however the CA still signs its CRLs with the key pair of the first certificate.

I guess for me there is nothing left but to reinstall the entire chain.

You can download the slides below:

• TLS renegotiation authentication GAP v1.1 pdf
• TLS renegotiation authentication GAP v1.1 pptx

Special thanks to Marsh Ray for his suggestions and corrections.

On the 19th of November Frank Breedijk announced that Jason Mansfield, who runs the website http:/clinicallyawasome.com, has won the contest by sending in the name Seccubus. A bottle of Vueve Clinquot champaing will be sent to him shortly.

The author has provided the following explanation of the name Seccubus:

Seccubus is a mythical creature that helps security professionals analyze and report the results of, repeated, vulnerability scans. Like its distant cousins the Succubus and Incubus the Seccubus is also a creature of the night. At night, or any other scheduled time, the Seccubus draws its energy from repeatedly performing vulnerability scans  of infrastructures until the vulnerabilities become exhausted or die.
The Inseccubus is the male counterpart of the Seccubus. While the Inseccubus draws his life energy from the assessor by repeatedly requiring him to (re-)analyse the same findings, the Seccubus get her energy from pleasing the assessor by reducing the number of findings by means of delta reporting.

The name Seccubus was chosen from a list of over 50 ideas sent after the contest was announced via the AutoNessus.com website, Hacker Public Radio, Paul dot com and various other social media outlets like Twitter, Facebook and LinkedIn.

“I wanted a name that was completely different from AutoNessus” said Frank Breedijk, explaining why suggestions like AutoVAS and AutoVAMP where turned down. Other suggestions where turned down because their name was already taken on media like twitter (e.g. VAsak, Vulnerability Assessment Swiss Army Knife) or “simply because I didn’t like them” (e.g. Mick Douglass is awesome).

Now that the new name has been announced the “rebranding” will be complete before the end of the year. The website www.seccubus.com is already live but still points to the AutoNessus.com site. Also Frank’s twitter account, @autonessus, will be renamed to @seccubus soon.

The response to the renaming contest was overwhelming and we would like to thank everybody who participated.

This new attack adds to the issues published by Moxie Marlinspike, Dan Kaminski and Mike Zusman I blogged about earlier.

So what does this new attack do?

The attack described by Marsh Ray et al. exploits a feature of the TLS protocol called renegotiation. Renegotiation allows the TLS client or server to initiate a renegotiation of the encryption of the connection in order to refresh keys, increase authentication, increase the strength of the cipher suite or any other reason. This renegotiation can be performed by the server or the client by sending a server or client hello message.

The man in the middle attack works by intercepting and forwarding the first client hello message sent by the client (C) to the server (S) and then negotiating the cipher between the Man in the Middle (M) and the server only. At this point there is an encrypted session between M and S and M can insert his own data into the connection and even read the reply for the period that the underlying protocol (e.g. HTTP for HTTPS) allows for a reply to arrive. M then replays the original client hello message received from C which will start a renegotiation of the cipher between C and S. Depending on the timing of the replay of the client hello message C will either append its request to M’s request, receive the answer to M’s request or will not be aware of M’s request and S’ reply to M’s request.

TLS handshake with MitM renegotiation attack

Using techniques similar to request smuggling M can even insert his own request into a session that requires client certificate authentication. In fact the original whitepaper’s first example deals with TLS renegotiation in case of client certificate authentication. Like Cross Site Request Forgery this attack allows an attacker to send requests to resource within the, possibly authenticated, context of the client.

Because this attack requires the attacker to manipulate the traffic stream between client and server and is thus classified as a man in the middle (MitM) attack, it does not allow the attacker to decrypt any traffic sent between client and server.

What are the consequences of this attack?

While this attack does not completely break TLS, it does break on of its fundamental functions, in that it does not fully guarantee the integrity of the first request from the client to the server. This means e.g. that the attacker could insert a transaction into an online banking application without the user being aware.
This attack does NOT affect the integrity of the reply from the server to the client (other than maybe not sending the reply to the client), so it does not allow the attacker to rewrite the reply from the server to the client. This means that if, e.g. an online bank publishes an overview of the transactions before and after the transaction is authorised, the user can spot the inserted transaction.

The attack also does not affect the confidentiality of either the original request or the reply from the server, however as with cross site request forgery, it may allow an attacker to use the clients credentials (e.g. a client certificate, cookie, or password) without knowing them.

While the attack only works for the first request sent over a TLS session (subsequent renegotiation requests are sent in the encryption context and can thus not be inserted) M could force the session to reset after x seconds of inactivity by sending a reset packet to both C and S, thus forcing a new TCP and TLS session to be re-established and thus gaining a new window of opportunity.

What can be done against this attack?

Currently there are no fixes available. In their whitepaper Marsh Ray et al describe several possible solutions, which unfortunately all more or less break backwards compatibility.

In response to this attack OpenSSL today released OpenSSL 0.9.8l which does not fix the vulnerability, but disables renegotiation completely. This change to OpenSSL may break certain applications so it should be carefully tested before it is implemented.
From an HTTPS perspective the problem has similarities with cross site request forgery and can be defended against in a similar manner. If a program requires a unique session ID with sufficient entropy as part of the URL this session ID cannot be read or reused by the attacker.
The problem currently has the full attention of Internet Engineering Task Force (IETF) TLS workgroup so hopefully they will come up with a fix soon. In the mean time you could disable renegotiation for OpenSSL based products if this does not break the application stack.

Conclusion

While the attack does not break the confidentiality of the communication between client and server it does allow an attacker to insert text into the first request of the client, thus breaking its integrity. This issue is a fundamental protocol level issue that cannot be fixed without breaking backward compatibility. If the application using TLS (e.g. HTTPS) does not need renegotiation, turning renegotiation off may be a possibility, however there are numerous situations where renegotiation is needed (e.g. certain scenarios where client certificate authentication is used for https).
I do not agree with Moxie Marlinspike who was quoted to say “It doesn’t affect your webmail, online banking or online shopping experience.” However the attack is hard to use and the attacker will need to have detailed knowledge of the application he is attacking. This attack will first appear in highly targeted scenarios. Since the attack is a man in the middle attack the attack will have to have control over all the traffic between client and server and vice versa in order to fully exploit the attack.

With this attack TLS does not fully protect the integrity of the communication between client and server.