Blog Archive

Thursday, 10 November 2011

Burp is voted #1 web scanner

Every couple of years, SecTools.org carries out a survey of the most popular security tools, as voted for by thousands of users. The latest results are out and Burp has done pretty well:

Needless to say, I'm pretty happy with this result, especially given the survey's overall focus on network security tools.

Burp has come a long way since it started off as a hobby project which soaked up my spare time. Burp wouldn't be where it is today without the huge support I get from users - with useful feature requests, bug reports, and telling other people about the software. So I owe a massive thank you to everyone who uses Burp and has helped over the years.

Despite being number one, I will of course be trying harder. I'm working on a lot of cool new features for Burp, which will be released over the coming year. Please do keep the feature requests coming!

Wednesday, 12 October 2011

Breaking encrypted data using Burp

A while ago, Burp Intruder added a bit flipping payload type, suitable for automatic testing for vulnerable CBC-encrypted session tokens and other data. If you aren't familiar with this vulnerability, take a look at The Web App Hacker's Handbook, 2nd Edition, pages 227-233, and also check out this exercise (login required) in the MDSec online training labs.

Burp Intruder now has a further payload type, suitable for automatic testing for vulnerable ECB-encrypted data. The theory behind these vulnerabilities is described on pages 224-226 of WAHH2e. Here, I'll briefly describe an example of the vulnerability, and show how it can be exploited using Burp.

ECB ciphers divide plaintext into equal-sized blocks, and encrypt each block separately using a secret key. As a result, identical blocks of plaintext always encrypt into identical blocks of ciphertext, regardless of their position within the structure. This means that it is possible to meaningfully modify the plaintext in a structure by duplicating and shuffling the blocks of ciphertext. Depending on the contents of the structure, and the application's handling of the modified data, it may be possible to interfere with application logic - for example, switching the user ID field in a structured session token, changing an encrypted price, etc.

Let's look at an example from the MDSec online training labs. Here, the application uses session tokens containing several meaningful components, including a numeric user identifier:

rnd=2458992;app=iTradeEUR_1;uid=218;username=dafydd;time=634430423694715000;

When encrypted, using an ECB cipher, the token becomes:

68BAC980742B9EF80A27CBBBC0618E3876FF3D6C6E6A7B9CB8FCA486F9E11922776F0307329140AA
BD223F003A8309DDB6B970C47BA2E249A0670592D74BCD07D51A3E150EFC2E69885A5C8131E4210F

The individual blocks of plaintext correspond to blocks of ciphertext as follows:

rnd=2458 68BAC980742B9EF8
992;app= 0A27CBBBC0618E38
iTradeEU 76FF3D6C6E6A7B9C
R_1;uid= B8FCA486F9E11922
218;user 776F0307329140AA
name=daf BD223F003A8309DD
ydd;time B6B970C47BA2E249
=6344304 A0670592D74BCD07
23694715 D51A3E150EFC2E69
000;     885A5C8131E4210F

Now, because each block of ciphertext will always decrypt into the same block of plaintext, it is possible to manipulate the sequence of ciphertext blocks, and meaningfully modify the corresponding plaintext. Depending on how the application handles the modified data, this may allow you to switch to a different user or escalate privileges.

For example, if the second block is copied following the fourth block, the resulting sequence of blocks will be:

rnd=2458 68BAC980742B9EF8
992;app= 0A27CBBBC0618E38
iTradeEU 76FF3D6C6E6A7B9C
R_1;uid= B8FCA486F9E11922
992;app= 0A27CBBBC0618E38
218;user 776F0307329140AA
name=daf BD223F003A8309DD
ydd;time B6B970C47BA2E249
=6344304 A0670592D74BCD07
23694715 D51A3E150EFC2E69
000;     885A5C8131E4210F

The decrypted token now contains a modified "uid" value, and also a duplicated "app" value. What happens will depend on how the application processes the decrypted token. If you are lucky, the application will retrieve the "uid" value, ignore the duplicated "app" value, and not check the overall integrity of the whole structure. If the application behaves like this, then it will process the request in the context of user 992, rather than user 218.

Now, it is possible to perform this attack manually, but this involves a lot of effort if you are working blind, without knowledge of the actual contents of the plaintext blocks. The new Burp Intruder payload type helps you to automate the process of finding and exploiting these vulnerabilities, in a much more effective way.

The configuration for the new payload type looks like this:

In the present case, we're going to tell Burp that the token contains 8-byte blocks and is encoded as ASCII hex. If you didn't know or couldn't guess this information, you could try different configurations, as this attack is normally fairly fast to run.

When the attack runs, Burp will split the base value into blocks, and will systematically duplicate and shuffle them, inserting a copy of each block at each block boundary. In some situations, this method alone will be sufficient to find a vulnerability. However, to make your attack more effective, you should also if possible use the further configuration "obtain additional blocks from these encrypted strings", as described below.

There is often a large element of luck involved when blindly shuffling blocks in ECB-encrypted data structures, and success often depends upon happening to find a block of ciphertext whose decrypted plaintext contains the right meaningful data when inserted into the structure (such as a number that could be a valid user ID within a session token). You can dramatically increase the likelihood of success by providing Burp with a large sample of other data that is encrypted using the same cipher and key. In the present example, you can harvest a large number of valid tokens using Burp Intruder or Sequencer, and configure the ECB block shuffler payload to use these tokens to derive additional blocks. Burp will then take all of the unique ciphertext blocks that you have provided, and use these when inserting blocks into the original data. In practice, if you can find suitable additional encrypted data, this method proves highly effective when targeting vulnerable applications.

Having used Burp Sequencer to obtain a large sample of tokens via the main application login, our configuration of the ECB block shuffler now looks like this:

To deliver the attack, we're going to target the user's account page within the application, which displays information about the logged in user (based, of course, on the supplied session token):

In order to identify the user context associated with each attack request, we're going to use the Extract Grep feature to highlight the name of the current user within the account page response:

We then start the attack and review the results. Unsurprisingly, a lot of the requests cause a redirection back to the login, because we have corrupted the format of the token. Many of the requests result in an apparently valid session, but showing "unknown user" - here, we have modified the UID to a value that does not correspond to any actually registered user. But in other requests, we are apparently logged in as a different user, including, as luck would have it, an application administrator:

A successful attack like this still requires a lot of luck, including whether and how the application tolerates modifications to the modified data, the positioning of block boundaries in relation to interesting data, and the ability to find a block containing suitable data for substitution. But the new Intruder payload type takes a lot of the pain out of testing blind for this vulnerability.

Have fun!

Wednesday, 21 September 2011

It's a biggie

Kindle schmindle. You can't quite beat a kilo and a half of dead tree landing on your desk. Should make an ample paperweight / doorstop if nothing else.

Tuesday, 20 September 2011

MDSec online training labs

Now that the second edition of The Web Application Hacker's Handbook is being shipped, it's time to start talking about the online training labs that accompany the new book. These labs are:

  • Written by the authors of WAHH.

  • Available online and on-demand, for you to use as you work through the book.

  • Very extensive, containing over 300 individual examples demonstrating almost every kind of web application vulnerability.

  • Cheap, costing only $7 per hour to use.

  • Hosted, fashionably, in the cloud, so you get your own server to play on, without worrying about interference from other lab users.

We hope that these labs will make the new edition of the book even more effective as a learning resource, letting you try for yourself any particular vulnerability types or variations that you have not encountered in the wild.

Try out the MDSec labs now!

Wednesday, 17 August 2011

The fame of Peter Wiener

Here's an extract from The Basics of Hacking and Penetration Testing by Patrick Engebretson, which was published earlier this month:

I guess it's a testament to Burp's popularity that Peter is getting around so much.

Remember, if you do want to change the default Burp Spider settings to submit a different name in your forms, the configuration details are here.

Update:

It seems Peter's fame continues to grow. Someone sent me the following photo showing the result of testing a network device:

If anyone has any further evidence of Peter's travels, email me and I'll post them here.

Friday, 3 June 2011

Burp Suite Free Edition v1.4 released

Burp Suite Free Edition v1.4 is now available for download.

This is a major upgrade with numerous new features, including:

Have fun!

Wednesday, 11 May 2011

Web App Hacker's Handbook 2nd Edition - Preview

The first draft of the new edition of WAHH is now completed, and the lengthy editing and production process is underway. Just to whet everyone's appetite, I'm posting below an exclusive extract from the Introduction, describing what has changed in the second edition.

(And in a vain attempt to quell the tidal wave of questions: the book will be published in October; there won't be any more extracts; we don't need any proof readers, thanks.)

What’s Changed in the Second Edition?

In the four years since the first edition of this book was published, much has changed and much has stayed the same. The march of new technology has, of course, continued apace, and this has given rise to specific new vulnerabilities and attacks. The ingenuity of hackers has also led to the development of new attack techniques, and new ways of exploiting old bugs. But neither of these factors, technological or human, has created a revolution. The technologies used in today’s applications have their roots in those that are many years old. And the fundamental concepts involved in today’s cutting-edge exploitation techniques are older than many of the researchers who are applying them so effectively. Web application security is a dynamic and exciting area to work in, but the bulk of what constitutes our accumulated wisdom has evolved slowly over many years, and would have been distinctively recognizable to practitioners working a decade or more ago.

This second edition is by no means a “complete rewrite” of the first edition. Most of the material in the first edition remains valid and current today. Approximately 30% of the content in the second edition is either completely new or extensively revised. The remaining 70% has had minor modifications or none at all. For readers who have upgraded from the first edition and may feel disappointed by these numbers, you should take heart. If you have mastered all of the techniques described in the first edition, then you already have the majority of the skills and knowledge that you need. You can focus your reading on what is new in this second edition, and quickly learn about the areas of web application security that have changed in recent years.

One significant new feature of the second edition is the inclusion throughout the book of real examples of nearly all of the vulnerabilities that are covered. Any place you see a Try it! link, you can go online and work interactively with the example being discussed, to confirm that you can find and exploit the vulnerability it contains. There are several hundred of these labs, which you can work through at your own pace as you read the book. The online labs are available on a subscription basis for a modest fee, to cover the costs of hosting and maintaining the infrastructure involved.

For readers wishing to focus their attention on what is new in the second edition, there follows a summary of the key areas where material has been added or rewritten.

Chapter 1, “Web Application (In)security”, has been partly updated to reflect new uses of web applications, some broad trends in technologies, and the ways in which a typical organization’s security perimeter has continued to change.

Chapter 2, “Core Defense Mechanisms”, has received minor changes, with a few examples added of generic techniques for bypassing input validation defenses.

Chapter 3, “Web Application Technologies”, has been expanded with some new sections describing technologies that are either new or were described more briefly elsewhere within the first edition. The areas added include REST, Ruby on Rails, SQL, XML, web services, CSS, VBScript, the document object model, Ajax, JSON, the same-origin policy, and HTML5.

Chapter 4, “Mapping the Application”, has received various minor updates to reflect developments in techniques for mapping content and functionality.

Chapter 5, “Bypassing Client-Side Controls”, has been updated more extensively. In particular, the section on browser extension technologies has been largely rewritten to include more detailed guidance on generic approaches to bytecode decompilation and debugging, how to handle serialized data in common formats, and how to deal with common obstacles to your work, including non-proxy-aware clients and problems with SSL. The chapter also now covers Silverlight technology.

Chapter 6, “Attacking Authentication”, remains current and has received only minor updates.

Chapter 7, “Attacking Session Management”, has been updated to cover new tools for automatically testing the quality of randomness in tokens. It also contains new material on attacking encrypted tokens, including practical techniques for token tampering without knowing either the cryptographic algorithm or the encryption key being used.

Chapter 8, “Attacking Access Controls”, now covers access control vulnerabilities arising from direct access to server-side methods, and from platform misconfiguration where rules based on HTTP methods are used to control access. It also describes some new tools and techniques that you can use to partially automate the frequently onerous task of testing access controls.

The material in Chapters 9 and 10 has been reorganized to create more manageable chapters and a more logical arrangement of topics. Chapter 9, “Attacking Data Stores” focuses on SQL injection and similar attacks against other data store technologies. As SQL injection vulnerabilities have become more widely understood and addressed, this material now focuses more on the practical situations where SQL injection is still to be found. There are also minor updates throughout to reflect current technologies and attack methods, and there is a new section on using automated tools for exploiting SQL injection vulnerabilities. The material on LDAP injection has been largely rewritten to include more detailed coverage of specific technologies (Microsoft Active Directory and OpenLDAP), as well as new techniques for exploiting common vulnerabilities. This chapter also now covers attacks against NoSQL.

Chapter 10, “Attacking Back-End Components”, covers the other types of server-side injection vulnerabilities that were previously included in Chapter 9. There are new sections covering XML external entity injection and injection into back-end HTTP requests, including HTTP parameter injection/pollution and injection into URL rewriting schemes.

Chapter 11, “Attacking Application Logic”, includes more real-world examples of common logic flaws in input validation functions. With the increased usage of encryption to protect application data at rest, we also include an example of how to identify and exploit encryption oracles to decrypt encrypted data.

The topic of attacks against other application users, previously covered by Chapter 12, has now been split into two separate chapters, as this material was becoming unmanageably large as a single chapter. Chapter 12, “Attacking Users: Cross-Site Scripting” focuses solely on XSS, and this material has been extensively updated in various areas. The sections on bypassing defensive filters to introduce script code have been completely rewritten to cover new techniques and technologies, including various little-known methods for executing script code on current browsers. There is also much more detailed coverage of methods for obfuscating script code to bypass common input filters. There are several new examples of real-world XSS attacks. There is a new section on delivering working XSS exploits in challenging conditions, which covers escalating an attack across application pages, exploiting XSS via cookies and the Referer header, and exploiting XSS in non-standard request and response content such as XML. There is a detailed examination of browsers’ built-in XSS filters, and how these can be circumvented to deliver exploits. There are new sections on specific techniques for exploiting XSS in webmail applications and in uploaded files. Finally, there are various updates to the defensive measures that can be used to prevent XSS attacks.

The new Chapter 13, “Attacking Users: Other Techniques”, draws together the remainder of this huge area. The topic of cross-site request forgery has been updated to include CSRF attacks against the login function, common defects in anti-CSRF defenses, UI redress attacks, and common defects in framebusting defenses. A new section on cross-domain data capture includes techniques for stealing data by injecting text containing non-scripting HTML and CSS, and various techniques for cross-domain data capture using JavaScript and E4X. A new section examines the same-origin policy in more detail, including its implementation in different browser extension technologies, the changes brought by HTML5, and ways of crossing domains via proxy service applications. There are new sections on client-side cookie injection, SQL injection and HTTP parameter pollution. The section on client-side privacy attacks has been expanded to include storage mechanisms provided by browser extension technologies and HTML5. Finally, a new section has been added drawing together general attacks against web users that do not depend upon vulnerabilities in any particular application. These attacks can be delivered by any malicious or compromised web site, or by an attacker who is suitably positioned on the network.

Chapter 14, “Automating Customized Attacks”, has been expanded to cover common barriers to automation, and how to circumvent these. Many applications employ defensive session-handling mechanisms that terminate sessions, use ephemeral anti-CSRF tokens, or use multi-stage processes to update application state. Some new tools are described for handling these mechanisms, which let you continue using automated testing techniques. A new section examines CAPTCHA controls, and some common vulnerabilities that can often be exploited to circumvent them.

Chapter 15, “Exploiting Information Disclosure”, contains new sections about XSS in error messages and exploiting decryption oracles.

Chapter 16, “Attacking Compiled Applications”, has not been updated.

Chapter 17, “Attacking Application Architecture”, contains a new section about vulnerabilities that arise in cloud-based architectures, and updated examples on exploiting architecture weaknesses.

Chapter 18, “Attacking the Application Server”, contains several new examples of interesting vulnerabilities in application servers and platforms, including Jetty, the JMX management console, ASP.NET, Apple iDisk server, Ruby WEBrick web server, and Java web server. It also has a new section looking at practical approaches to circumventing web application firewalls..

Chapter 19, “Finding Vulnerabilities in Source Code”, has not been updated.

Chapter 20, “A Web Application Hacker’s Toolkit”, has been updated with details of the latest features in proxy-based tool suites. It contains new sections about how to proxy the traffic of non-proxy-aware clients, and how to eliminate SSL errors in browsers and other clients, caused by the use of an intercepting proxy. There is a detailed description of the workflow that is typically employed when you are testing using a proxy-based tool suite. There is a new discussion about current web vulnerability scanners, and the optimal approaches to using these in different situations.

Copyright 2010 PortSwigger Ltd. All rights reserved.