Security Research

You Should Work for Symantec

Jan 10, 2010

This video perfectly describes the life of an independent security researcher. I hope you like it.

CSAW final reverse engineering challenge

Nov 6, 2010

The final round of the CSAW CTF competition took place on October 29th in New York and included a reverse engineering challenge I created specifically for this event. Since the teams in the qualifying round showed some pretty impressive reversing talent, I tried to make the final harder. Much harder. So hard that in fact not a single team solved the challenge.

If you'd like to try, you can download the CSAW-FINAL-SOTIROV.RAR archive, which contains an installer for a modified version of Adobe Reader 9.2 and a PDF file. Once you extract the files, follow the instructions below:

1. Install AdbeRdr910_bg_BG.msi. This is a slighly modified version of Adobe Reader with some extra functionality.

2. Open CSAW.pdf and enter a key in the form. If the key is correct, Adobe Reader will pop up a message box to congratulate you.

Your goal is to find the modifications in Adobe Reader and find the key that brings up the message box. If solve the challenge, I would appreciate it if you post a description of how you solved it and email me to let me know.

CSAW reverse engineering challenge

Sep 25, 2010

NYU Poly is one the schools with the best information security programs in the United States, with strong connections to the security community in the New York area. Together with Dino Dai Zovi, Erik Cabetas, Marcin Wielgoszewski and other NYC hackers I helped create a set of challenges for the CTF competition during the Cyber-Security Awareness Week.

The CTF started this Friday and will be open until 8pm on Sunday. Anyone is welcome to play, but even if you don't want to register you can still download the challenges and try to solve them. My reverse engineering challenge is called KFJSCGEH.EXE and is worth 500 points.

Your goal is to find the magic incantation that will cause the program to display a message box with the secret key.

Darknet design

Aug 2, 2010

Back in 2007 I spent some time playing with a design for a file sharing darknet. It was never implemented, but I recently found my notes from that project and decided to post them here in the hope that someone might find this useful.

network size
    small darknet
        10-50 users
        full trust model
        but how do you prevent it from getting too big?
            it will degenerate into large scale unless you do friend of a friend
    multiple darknets
        5 x 10-50 users
        each user is a member of multiple networks
        no cross network identity or trust
    large scale friend of a friend network
        each user can see only their friends and friends of friends

user identities
    user id
    user SSL certificate

node identities
    IP address
    node SSL certificate
    all the above information is signed by the user SSL certificate

services provided by the darknet
    file sharing - GET requests over HTTPS
    messaging - XML-RPC over HTTPS, either direct or broadast

trust model (chosen by each user)
    everybody - as long as they are part of the network
    friends - only friends on your trust list
    friends of friends - single hop or multiple hops

join algorithm
    Alice invites Bob into the network
        Alice generates an invite key containing:
            SSL certificate for Alice
            temporary client SSL certificate for Bob, signed by Alice
            IP address of Alice's node
            expiration date
        Alice sends the invite key to Bob over an external secure channel
    Bob creates a new identity
        Bob connects to Alice using the temp SSL certificate from the invite key
            Bob authenticates Alice using her SSL certificate from the invite key
            Alice authenticates Bob by verifying his client SSL certificate
            if the invite is expired, Bob needs a new invite key
        Bob picks a user id and sends it to Alice
            if the user id is already taken, Bob has to try again with a new id
        Bob creates a permanent user SSL certificate and sends it to Alice
    Alice broadcasts the new user id and certificate to all other nodes
    Bob reconnects to Alice using his permanent client SSL certificate
    Bob gets the IPs and certificates of neighboring nodes from Alice

limited visibility of IPs
    connect only to servers you trust (need at least one, see join algorithm above)
    send your IP only to servers you trust
    your IP is forwarded to other servers only:
        if your trust model is everybody
            forwarded to everybody
        if your trust model is friend of a friend
            forwarded to their friends
        if your trust model is friends only
            no forwarding

threat model
    privacy
        get IPs that a specific user is communicating with
            attacker: ISP
            defense: random ssl traffic, no defense for high speed traffic
        get full user list
            attacker: rogue/compromised node
            defense: a node can see only friends of friends, not beyond that
        get full server list
            attacker: rogue/compromised node
            defense: a node can see only friends of friends, not beyond that
        get shares/files of user
            attacker: rogue/compromised node
            defense: per share permissions
        get records of transactions
            attacker: ISP
            defense: ssl
    disrupt network
        traffic filtering
            attacker: ISP
            defense: ssl on port 443, dedicated servers
        traffic throttling
            attacker: ISP
            defense: ssl on port 443
        DoS against network
            attacker: rogue/compromised node
            defense: none

Assured Exploitation training course at CanSecWest

Feb 17, 2010

Dino Dai Zovi and I are going to teach a two day training course at the CanSecWest conference in March of this year. Our course is titled Assured Exploitation and will focus on the advanced exploitation techniques required for developing state of the art exploits for Vista and Windows 7 systems.

Why do we feel that this course is necessary? Many security professionals have mastered stack overflows and heap spraying, but these techniques are no longer sufficient for developing exploits in 2010. Reliable exploitation on Vista and Windows 7 requires advanced techniques such as heap layout manipulation, return oriented programming and ASLR information leaks. In addition, robust exploitation necessitates repairing the heap and continuing execution without crashing the process. The goal of our Assured Exploitation course is to teach the principles behind these advanced techniques and give the students hands-on experience developing real-world exploits.

Here is a list of the topics that we indend to cover:

• in-depth review of GS, ASLR, DEP, SafeSEH and SEHOP exploitation mitigations
• heap implementation details and manipulation of the heap state (including Windows 7)
• building primitives for heap layout control in new applications
• bypassing ASLR through memory disclosure
• browser plugin exploitation in Internet Explorer, Firefox and Chrome
• return oriented programming and shellcode development
• repairing the heap and achieving continuation of process execution after the payload is executed

The training will be based on a series of hands-on exercises that will incrementally guide the students through building their own exploits for the recent Aurora vulnerability, with capabilities far exceeding those of the publicly available samples. At the end of the course, the students will have the skills to reliably exploit Internet Explorer 8 on Windows 7 with both ASLR and DEP enabled.

To register for the course, please visit the CanSecWest website. We encourage you to register early because the class size is limited and prices are going up next month.

Verisign and responsible disclosure

Jan 6, 2009

In a recent post on his company blog, Verisign's vice president of marketing Tim Callan commented on the disclosure of our MD5 collision attack:

I feel that this statement is inaccurate. Not only did we contact Verisign before our presentation to let them know about our research, we also strongly advised them to stop using MD5 as soon as possible and were given a chance to review their mitigation plans. I hope that Tim Callan's post is a result of a simple miscommunication between the technical people at Verisign their marketing department.

To help clarify this issue, in this post I will provide some background information about the disclosure of our work, as well as the exact timeline of our communication with the affected certificate authorities.

Protecting Internet users

From the very beginning of this project, all members of our team agreed that we needed to disclose this vulnerability without putting any users at risk. There were two main goals we set out to achieve: first, to prevent our rogue CA certificate from being abused; and second, to ensure that nobody else can repeat this attack before the affected CAs get a chance to fix the problem.

We took the following steps to prevent abuse of our rogue CA certificate:

• We did not release the private key for our rogue CA.
• We set the expiration date of the rogue CA certificate to August 2004, ensuring that even if the private key falls into the wrong hands, it will be useless against people who have their system date set correctly.
• We contacted the major browser vendors (Microsoft and Mozilla) to offer them a chance to explicitly blacklist our certificate if they felt that the past expiration date is not effective enough.

To make sure that our work could not be repeated by malicious attackers, we did not release the MD5 collision finding software necessary to do the attack. In addition, we chose to delay the publication of the improved collision finding techniques we had to develop for this project. Our team was confident that the R&D investment required to repeat our attack without access to this information would be prohibitive and the affected CAs would have enough time to stop using MD5 before the attack could be repeated.

Notifying the affected certificate authorities

Since we had already taken steps to ensure that the attack could not be easily repeated, notifying the affected certificate authorities before our presentation was not required in order to protect Internet users. A more important consideration was to ensure that we could present our work at the Chaos Computer Congress without interference. In the last year we have seen multiple cases in which companies have used legal threats in an attempt to silence security researchers and prevent the release of information that exposes their security failures. The most prominent examples include the lawsuit against Dutch researchers who showed fatal security flaws in the MIFARE transit cards and the restraining order that led to the cancelation of a talk about vulnerabilities in the fare collection system of the Boston subway.

Since the affected CAs did not have a significant track record of responding to public security vulnerabiltiies in their systems, we could not be confident that they wouldn't overreact and attempt to stop or delay our presentation through legal or other means. It was this feeling of uncertainty that led to our decision to avoid direct contact with them and to obtain Non-Disclosure Agreements from the browser vendors we contacted.

Recognizing the significance of the issue, Microsoft offered to act as a intermediary and contact the affected CAs on our behalf without revealing our names or the date of our presentation. Their proposal was reviewed by our team as well as our lawyers and on Dec 23 we agreed to go ahead with it:

Date: Tue, 23 Dec 2008 05:21:07 -0500
From: Alexander Sotirov <alex@sotirov.net>
To: Microsoft Security Response Center <secure@microsoft.com>

All of the team members agreed with the proposed plan, you can go ahead and
contact Verisign. Thanks for the help with this issue.

Here are the details that you can reveal to Verisign:

1) point them to the 2007 paper that describes the generation of colliding x509
   certificates: http://www.win.tue.nl/hashclash/TargetCollidingCertificates/

2) tell them that Microsoft has been made aware that this crypto attack has been
   improved and some practical limitations have been worked out, allowing the
   successful generation of colliding x509 certificates signed by real
   certificate authorities which still use MD5

3) tell them that RapidSSL and FreeSSL (also owned by Geotrust) use MD5 and
   are vulnerable to this attack

4) encourage them to move to SHA-1 for all new certificates asap

5) it is important to stress that this attack is a generic attack against
   CAs that use MD5 and not specifically targeting Verisign. They have a
   good PR opportunity to react quickly and fix the bug before other CAs
   They don't want to be the _last_ CA that uses MD5 :-)

If they request additional information from us, please pass the request along
and we'll try to help with what we can. You can call me directly at
XXX-XXX-XXXX if rapid response is required. We would be happy to chat with
Verisign directly on Dec 30, but we'd like to avoid direct contact until then.

The same day Microsoft contacted Verisign and informed them about our research. Verisign understood the severity of the issue and began working on it:

From: Microsoft Security Response Center <secure@microsoft.com>
To: Alexander Sotirov <alex@sotirov.net>
Date: Tue, 23 Dec 2008 13:18:09 -0800

We spoke to Verisign this morning, and essentially used your last e-mail as
a script to introduce them to the issue. We also passed along the roots they
own which you identified as affected, and they are reviewing their next steps
right now. They understood the severity of the issue and are taking it
seriously. At this point in time they did not have any further requests for
information.

They were however surprised by the ssl123 certificate: they claim these are
all issued using sha1. The ip address you listed for that certificate is no
longer live, and the hostname in the CN is using another Verisign certificate.
Would you mind if I pass along the subject and issuer information for them to
progress their validation?

I was happy to help Verisign by providing extra information about the SSL123 certificate in question. I also gave Microsoft permission to contact the other affected CA:

Date: Tue, 23 Dec 2008 19:38:09 -0500
From: Alexander Sotirov <alex@sotirov.net>
To: Microsoft Security Response Center <secure@microsoft.com>

> They were however surprised by the ssl123 certificate: they claim these are
> all issued using sha1. The ip address you listed for that certificate is no
> longer live, and the hostname in the CN is using another Verisign
> certificate. Would you mind if I pass along the subject and issuer
> information for them to progress their validation?

I have the original cert from that website. I've attached a zip file with all 5
Thawte MD5 certs that I found in the wild, including the SSL123 one. It's a
bit disconcerning that the CAs themselves don't know what algorithms they are
using.

You can give Verisign these certs, I collected them from public websites so
they are not secret in any way.

> The RSA root you listed is in fact also owned by Verisign, so they are
> investigating that one as well. There is one other root which belongs to
> another company, being Chosen Security/TC TrustCenter AG. We tentatively have
> a call scheduled with them tomorrow morning at 8 AM PST. If you can confirm
> that we can communicate the same information to them, this would be
> excellent.

Yes, you can communicate the same information to them.

On Dec 24, Microsoft requested permission to release more information to the CAs:

From: Microsoft Security Response Center <secure@microsoft.com>
To: Alexander Sotirov <alex@sotirov.net>
Date: Wed, 24 Dec 2008 09:09:15 -0800

One of the two certificate authorities got back to us and stated they will be
changing their engineering efforts to SHA1 within a *very short* timeframe. We
are literally talking days/weeks here. This is still going to be after your
presentation date. However, they are asking us specifically whether this
timeframe will be acceptable.

We cannot answer any questions on this for now - we are only the "voice box" in
between here. I do feel you should be giving them at least some nod in the
direction that they will still not make it in time, but also that this is not
very critical.

Could I have your permission to release the following statement to them:

"Hi [name],

The finder informed us they will likely take this issue public prior to [your
proposed switch date].  However, he wanted us to convey to you that they will
only be demonstrating that the generation of an “evil twin” certificate is
possible. They will not disclose their collision seeking algorithm, nor will
they be releasing any Proof of Concept code. Given the significant amount of
cryptographic research involved, they feel that their results will not be
repeatable for at least some time. They do plan on releasing a full research
paper on their method, but this will definitely be released much later than
your proposed switch time.

As such they don't feel that making this change will directly affect your
customers. They do think the level of responsiveness you are showing would be a
positive PR opportunity for your organization."

As this statement essentially conveys your plans and opinion, please feel free
to propose any other one with your team or make changes where you deem
necessary.

I promptly agreed to the proposed statement, with some minor edits:

From: Alexander Sotirov <alex@sotirov.net>
To: Microsoft Security Response Center <secure@microsoft.com>
Date: Wed, 24 Dec 2008 14:04:40 -0500

> "Hi [name],
>
> The finder informed us they will likely take this issue public prior to [your
> proposed switch date]. However, he wanted us to convey to you that they will
> only be demonstrating that the generation of an “evil twin” certificate is
> possible. They will not disclose their collision seeking algorithm, nor will
> they be releasing any Proof of Concept code. Given the significant amount of

make this "...releasing the software that implements the collision generation."

> cryptographic research involved, they feel that their results will not be
> repeatable for at least some time. They do plan on releasing a full research
> paper on their method, but this will definitely be released much later than
> your proposed switch time.

add "They will wait until all CAs have completed the move to SHA-1 before publishing
the details necessary to repeat the attack."

> As such they don't feel that making this change will directly affect your
> customers. They do think the level of responsiveness you are showing would be
> a positive PR opportunity for your organization."

I agree with this statement. You can share it with all affected CAs.

Alex

On Dec 29, Verisign confirmed that they are planning to stop using MD5 by the end of January.

From: Microsoft Security Response Center <secure@microsoft.com>
To: Alexander Sotirov <alex@sotirov.net>
Date: Mon, 29 Dec 2008 13:45:25 -0800

Hi Alexander,

Here is more feedback and contact information from Verisign:

"The SSL123 certs using MD5 are through a legacy reseller platform we are in
the process of EOL'ing.  We do still have resellers using it so will need to
make updates to that platform as well.

We are working on making system changes to stop using MD5. They won't all be in
place by January 5th, but will be by the end of January. From what I am reading
below, the key thing seems to be that we are taking measures to stop using MD5
in the short term - so our plan to have all system changes in place by the end
of January should be Ok. Would you agree?

As far as contacts, from a technical point of view they can contact me. My
information, including cell is below. From a PR standpoint, the best person to
contact is Tim Callan - his email address is xxxxxxxx@verisign.com and direct
line is XXX-XXX-XXXX and cell is XXX-XXX-XXXX. An alternative contact for PR if
you can't reach Tim is Tina Hou (xxxxxxxx@verisign.com). She reports directly
to Tim.

Jay Schiavo
xxxxxxxx@verisign.com
Direct: XXX.XXX.XXXX
Mobile: XXX.XXX.XXXX"

Only 5 hours after our presentation, Verisign stopped using MD5 for all new RapidSSL certificates, successfully eliminating this vulnerability.

Cryptographic algorithms can become broken overnight, so it is important for CAs to demonstrate the ability to react quickly to such issues. I'm happy with the reponse from Verisign and the other affected CAs. Based on our experience with them, I would not hesitate to work with them directly on any vulnerabilties I might discover in the future.

Creating a rogue CA certificate

Dec 30, 2008

The details of our secret project are out! Our research team, consisting of 7 researchers from the United States, Switzerland and the Netherlands, was able to execute a practical MD5 collision attack and create a rogue Certification Authority trusted by all common web browsers. This allows us to perform transparent man-in-the-middle attacks against SSL connections and monitor or tamper with the traffic to secure websites or email servers.

The infrastructure of Certification Authorities is meant to prevent exactly this type of attack. Our work shows that known weaknesses in the MD5 hash function can be exploited in realistic attack, due to the fact that even after years of warnings about the lack of security of MD5, some root CAs are still using this broken hash function.

For more details, see our project website.

Making the theoretical possible

Dec 29, 2008

Tomorrow a team of researchers I've been working with for the last 6 months will present the results of a previously theoretical attack against important Internet infrastructure that we've been able to execute in practice. I apologize for the secrecy surrounding our talk, but we had good reasons for it and I hope that people will understand when the details are revealed tomorrow.

The presentation will be at the Chaos Computer Congress in Berlin on Tuesday, December 30th. It will begin at 15:15 German time (6:15am in California, 9:15am in New York) and will be streamed live online.

All our materials, including a full paper about our attack will be published online shortly after the presentation.

Decompiling the vulnerable function for MS08-067

Oct 25, 2008

I spent a couple of hours tonight reversing the vulnerable code responsible for the MS08-067 vulnerability. This bug is pretty interesting, because it is in the same area of code as the MS06-040 buffer overflow, but it was completely missed by all security researchers and Microsoft. It's quite embarassing.

Here's the code of the vulnerable function on Windows XP SP3 and Vista SP1:

#include <wchar.h>

// This is the decompiled function sub_5B86A51B in netapi32.dll on XP SP3
// and sub_6EA11D4D on Vista SP1

int ms08_067(wchar_t* path)
{
    wchar_t* p;
    wchar_t* q;
    wchar_t* previous_slash = NULL;
    wchar_t* current_slash  = NULL;
    wchar_t  ch;

#ifdef VISTA
    int len = wcslen(path);
    wchar_t* end_of_path = path + len;
#endif

    // If the path starts with a server name, skip it

    if ((path[0] == L'\\' || path[0] == L'/') &&
        (path[1] == L'\\' || path[1] == L'/'))
    {
        p = path+2;

        while (*p != L'\\' && *p != L'/') {
            if (*p == L'\0')
                return 0;
            p++;
        }

        p++;

        // make path point after the server name

        path = p;

        // make sure the server name is followed by a single slash

        if (path[0] == L'\\' || path[0] == L'/')
            return 0;
    }

    if (path[0] == L'\0')   // return if the path is empty
        return 1;

    // Iterate through the path and canonicalize ..\ and .\

    p = path;

    while (1) {
        if (*p == L'\\') {
            // we have a slash

            if (current_slash == p-1)   // don't allow consequtive slashes
                return 0;

            // store the locations of the current and previous slashes

            previous_slash = current_slash;
            current_slash = p;
        }
        else if (*p == L'.' && (current_slash == p-1 || p == path)) {
            // we have \. or ^.

            if (p[1] == L'.' && (p[2] == L'\\' || p[2] == L'\0')) {
                // we have a \..\, \..$, ^..\ or ^..$ sequence

                if (previous_slash == NULL)
                    return 0;

                // example: aaa\bbb\..\ccc
                //             ^   ^  ^
                //             |   |  &p[2]
                //             |   |
                //             |   current_slash
                //             |
                //             previous_slash

                ch = p[2];

#ifdef VISTA
                if (previous_slash >= end_of_path)
                    return 0;

                wcscpy_s(previous_slash, (end_of_path-previous_slash)/2, p+2);
#else // XP
                wcscpy(previous_slash, &p[2]);
#endif

                if (ch == L'\0')
                    return 1;

                current_slash = previous_slash;
                p = previous_slash;

                // find the slash before p

                // BUG: if previous_slash points to the beginning of the
                // string, we'll go beyond the start of the buffer
                //
                // example string: \a\..\

                q = p-1;
                
                while (*q != L'\\' && q != path)
                    q--;

                if (*p == L'\\')
                    previous_slash = q;
                else
                    previous_slash = NULL;
            }
            else if (p[1] == L'\\') {
                // we have \.\ or ^.\ 

#ifdef VISTA
                if (current_slash != NULL) {
                    if (current_slash >= end_of_path)
                        return 0;
                    wcscpy_s(current_slash, (end_of_path-current_slash)/2, p+2);
                    goto end_of_loop;
                }
                else {  // current_slash == NULL
                    if (p >= end_of_path)
                        return 0;
                    wcscpy_s(p, (end_of_path-p)/2, p+2);
                    goto end_of_loop;
                }
#else // XP
                if (current_slash != NULL) {
                    wcscpy(current_slash, p+2);
                    goto end_of_loop;
                }
                else { // current_slash == NULL
                    wcscpy(p, p+2);
                    goto end_of_loop;
                }
#endif
            }
            else if (p[1] != L'\0') {
                // we have \. or ^. followed by some other char

                if (current_slash != NULL) {
                    p = current_slash;
                }
                *p = L'\0';
                return 1;
            }
        }

        p++;

end_of_loop:
        if (*p == L'\0')
            return 1;
    }
}

// Run this program to simulate the MS08-067 vulnerability

int main()
{
    return ms08_067(L"\\c\\..\\..\\AAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
}