Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Category Archives: Security

Defense by Numbers: Making problems for script kiddies and scanner monkies

Since early 2012 I’ve been working on a simple theory…

The Theory:

By varying [response|status] codes, it should be possible to slow down attackers and automated scanners.

If you’ve met me at a conference any time in the last year I’ve probably talked about it at length and bored the hell out of you (sorry about that BTW).

After researching a number of aspects of this theory I put forward a presentation for BSidesLondon to talk about my findings and how it might be applied to application defense.

The topic can be a little complex due to the various ways browsers handle [response|status] codes. Even within a specific browser the handling of different content types varies. JavaScript is a prime example of that. Where as a browser will happily show you a webpage received with a 404 “Not Found” code, the same browser may not accept active script content with the same code.

During testing I also discovered a couple of interesting issues with Proxy servers that could be used by attackers to expose credentials… as well as some very interesting browser quirks that are probably only interesting to a handful of people. Still, I like edge-case stuff, it’s weird and that suits me just right ;)

BSidesLondon Abstract

On the surface most common browsers (user agents) all look the same, function the same, and deliver web content to the user in a relatively uniformed fashion. Under the surface however, the way specific user agents handle traffic varies in a number of interesting ways. This variation allows for intelligent and skilled defenders to play with attackers and scripted attacks in a way that most normal users will never even see.
This talk will attempt to show that differences in how user agents handle web server responses can be used to improve the defensive posture of a website. Further examples will be given that show specially crafted responses can disrupt common automated attack methods and cause issues for casual attackers and wide scale scanning of websites

If the topic is something that interests you (and I’m sure there’s a lot more research to be done here) feel free to take a snoop at the slides… The talk was recorded also, so keep an eye on the BSidesLondon website and twitter feed for information on the video/audio release.

 

 

Links:

  • Some thoughts on HTTP response codes –> HERE
  • Privoxy Proxy Aauthentication Credential Exposure [cve-2013-2503] –> HERE
  • mitm-proxy scripts used in testing –> HERE

BSidesLondon 2013

It’s been a while since I’ve had the chance to update the blog, and that makes me a sad panda… still, sometimes life gets in the way of the really important stuff. Plus, nobody really reads this crap anyway right!

Still, pleasantries aside, next week is BSidesLondon (and a couple of events that run alongside it, such as 44cafe, and that small $vendor thing called InfoSec Europe). I was lucky enough to get selected as one of the speakers for this years event, and despite not dressing up like a gay biker, I hope the talk will be interesting. So, if you like number, weird edge cases, or innovative ways to protect web applications, come along to my talk and let me know what you think!

  • Defense by numbers: Making problems for script kiddies and scanner monkeys

Chris John Riley
Track One 12:45 – 13:30

On the surface most common browsers (user agents) all look the same, function the same, and deliver web content to the user in a relatively uniformed fashion. Under the surface however, the way specific user agents handle traffic varies in a number of interesting ways. This variation allows for intelligent and skilled defenders to play with attackers and scripted attacks in a way that most normal users will never even see.
This talk will attempt to show that differences in how user agents handle web server responses can be used to improve the defensive posture of a website. Further examples will be given that show specially crafted responses can disrupt common automated attack methods and cause issues for casual attackers and wide scale scanning of websites

Just to warn those brave souls to plan to attend… I have LOTS of slides… it could get messy ;) I’ll try to put my slides up on Slideshare prior to the talk so people can follow along if they want.

Anyway, as part of the build-up to the conference I wanted to list a few of the talks I’m really looking forward to seeing (time permitting).

  • Pentesting like a Grandmaster

Abraham Aranguren
Track One 10:15 – 11:15

Chess is a complex game: The number of permutations is just too great to compute the best possible move during a game. This is similar to pen testing in that we also have too many vulnerabilities to find and choose from not only on a 1 by 1 basis but also how we would chain them together like a real attacker. Chess players must analyse efficiently to beat time constraints like pentesters but unlike pentesters they have been doing this for a long time.

Abraham’s talks are always interesting, and I expect nothing less from his latest talk. He seems to have a unique way of looking at things and from a sneak peek at his slides, I think this one is going to be another interesting talk point.

  • Going Stealth: Staying off the Anti-Virus RADAR

Alex Polychronopoulos
Track One 17:00 – 18:00

Anti-Virus software is often the first line of defence in host based intrusion prevention. For years both black-hats and ethical hackers have researched how to avoid detection – some to compromise hosts reliably and others to improve detection. Executable packers are a popular technique used by virus and malware writers. They “pack” their malicious payload by compressing and/or encrypting it and they distribute it with enough clear-text instructions to “unpack” it. In particular, we’ll look at basic AV detection concepts and the basic design principles for packers. We’ll also touch on advanced techniques like polymorphism and metamorphism. You’ll leave marvelling that your AV ever catches anything at all.

Sometimes AV is the only standing between a good penetration tester and total domination… Anything we can do to test the limits of AV and maybe get that elusive shell is certainly worth the time to learn. Hoping for a few hints and tips here that might help in those situations.

  • How to build a personal security brand that will stop the hackers, save the world and get you the girl

Javvad Malik
Track Two 11:30 – 12:30

You’re a security professional, but even your boss doesn’t remember your name. Your brilliant ideas aren’t listened to, you’re never invited to speak at conferences and not even your mother visits your blog. In this talk I will take you down a journey of self-discovery that took me 3 years and went from another faceless security dude, to someone in control of my personal security brand. What worked, what didn’t work and all the behind-the-curtain magic exposed. If you’re into building your personal brand, making your voice heard amongst the 100′s of security ‘rockstars’ and dinosaurs who get all the attention – this is the talk for you to attend.

Fuck rockstars… no really, in this industry we need solutions, not primadonas with a god complex. Still, that said, having a brand and a platform to shout from is something we need. Plus Javvad is wicked funny and I’m sure he’ll CISSP mofo everybody in the crowd at LEAST once!

  • Dissecting Targeted Attacks – Separating Myths from Facts

Candid Wuest
Track Two 14:30 – 15:30

A lot of media do report on targeted attacks or so-called APTs, but how sophisticated or those attacks really? Flamer & co. are only the tip of the iceberg and even they had flaws. Most of the attacks are not so smart at all, but nevertheless successful. I will elaborate on the common methods of targeted infection & exfiltration, happening every day around the globe. Explaining the methods and tools used by the attackers with real life examples. I will show why they successfully bypass most security tools and analyse where these attacks differ from the common malware flood.

Learn your APT from your elbow… not everything is OMGtargetedStateSponsoredBBQ Malware from China with love!

—————————————————-

Well, those are my picks… so much cool stuff, so little time! Before I sign-off however, I wanted to remind all attendees that it’s your JOB (yep, attendees also have a job to do) to give feedback to speakers. Even if it’s a single point, an idea, or a pat on the back and “that was cool” comment… be part of making the conference better… give feedback or the kitten gets it!

Read my thoughts on “Giving feedback” –> HERE

Hope to see you all in London. Please come up and say hi if you’re about… I only bite when provoked!

Privoxy Proxy Authentication Credential Exposure – CVE-2013-2503

Privoxy Proxy Authentication Credential Exposure

Product: Privoxy
Project Homepage: privoxy.org
Advisory ID: c22-2013-01
Vulnerable Version(s): 3.0.20 (and possibly prior)
Tested Version: 3.0.20-1 (tested using Debian Sid)
Vendor Notification: March 6, 2013
Public Disclosure: March 11, 2013
Vulnerability Type: Insufficiently Protected Credentials [CWE-522]
CVE Reference: CVE-2013-2503
Risk Level: Medium
CVSSv2 Base Score: 4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N)
Discovery: Chris John Riley ( http://blog.c22.cc )

Advisory Details:

During research into browser and proxy server handling of HTTP Response Codes, an issue with the way that Privoxy handles HTTP Response code 407 “Proxy Authentication Required” was discovered. Privoxy in versions 3.0.20 (and possibly prior) ignores the presence of ”Proxy-Authenticate” and “Proxy-Authorization” headers and allows these values to be passed to and from a remote server without modification. The resulting behavior could allow a malicious websites to spoof a  Proxy-Authentication response appearing to originate from the Privoxy service. The Privoxy user will then be prompted for a username and password that appears to originate from the Privoxy software.

Scenario:

  1. A Privoxy user visits a website using a browser of their choice
  2. The remote website responds to the request with a 407 “Proxy Authentication Required” HTTP response code and the appropriate ”Proxy-Authenticate: Basic” HTTP response header
  3. This response is passed through the Privoxy service without modification to the users browser
  4. As the browser is configured to use a proxy server, the browser believes that the upstream proxy (Privoxy) has requested authentication and prompts the user for a username and password. This prompt states that the proxy server at “127.0.0.1:8118″ requires authentication (this prompt may vary if Privoxy is running on a machine other than localhost and/or on a non-default port number)
  5. If the user enters a username and password, the browser will send a request through Privoxy to the remote website with a “Proxy-Authorization: XXXXXXXX” HTTP request header (where XXXXXXX is a base64 encoded version of the username and password the user entered at the browsers proxy authentication prompt)
  6. The remote website receives this header and can store or re-use these captured credentials

Proof of Concept:

http://c22.cc/POC/c22-2013-01.php

The above URL will respond with a “Proxy-Authenticate: basic” header when a request is received that does no contain a “Proxy-Authorization” header. This will prompt the users browser to request a username/password from the user. If you enter a value in the username/password box and click ok, it will send a Base64 encoded version to the remote website (the server will display the response headers at the bottom of the resulting page under request headers (one of the values will be “Proxy-Authorization” with a base64 encoded version of the entered username/password). For a full walkthrough it is suggested to capture this in your favourite packet capture program and walk through the requests to view the entire process. 

Note –> The above POC does not store any data sent to the server, however it is suggested to use bogus credentials if testing this proof of  concept.

Solution:

The following solution was suggested and implemented in Privoxy 3.0.21 stable.

Proxy authentication headers are removed unless the new directive enable-proxy-authentication-forwarding is used. Forwarding the headers potentionally allows malicious sites to trick the user into providing it with login information.

References:
Privoxy 3.0.21 ChangeLog –> http://ijbswa.cvs.sourceforge.net/viewvc/ijbswa/current/ChangeLog?revision=1.188&view=markup

Vulnerability Timeline:

March 5, 2013 20:00 – Initial discovery of vulnerability
March 6, 2013 14:48 > Emailed Privoxy developer list to request a security contact
March 6, 2013 15:26 < Received response with dedicated security contact information
March 6, 2013 16:01 > Emailed details of the vulnerability to security contact
March 6, 2013 17:19 < Received response acknowledging issue. Fix indicated in upcoming release
March 6, 2013 18:38 > Acknowledged receipt of email and advised of updated CVSSv2 score
March 7, 2013 15:50 < Received response detailing proposed fix, including link to CVS check-in of new code
March 7, 2013 18:48 > Acknowledged receipt of email
March 9, 2013 16:54 > Emailed CVE number to security contact and requested information on release plans
March 10, 2013 14:28 < Received confirmation of release timeline
March 10, 2013 14:58 – Release of Privoxy 3.0.21 stable
March 11, 2013 07:30 – Release of advisory

{QuickPost} Research Teaser – HTTP Response Codes

So I’ve been a little slack recently when it comes to blog posts… and conferences… and, well pretty much everything. Still, I’ve been doing some interesting things (for me at least) in the background that I’m hoping to be talking about later this year. I don’t want to give too much away, but I’m sure people can figure it out based on stuff I’ve previously put out… if not, then here’s just a pretty picture of 3 browsers side by side ;)

teaser

… and no, the above isn’t doing anything with the user-agent string (you’re thinking of the wrong research ;).

Here’s hoping that the fine folks over at BSidesLondon accept my talk so I can talk about it in April… and that everything pans out so I don’t look like a moron on stage… again! ;)

Follow

Get every new post delivered to your Inbox.

Join 59 other followers