Cracking the Lens: Targeting HTTP's Hidden Attack-Surface

good afternoon again and welcome to cracking the lens exploiting HTTP hidden attack surface have you ever seen a tempting target but had to ignore it because it's not quite within the scope of your test or maybe you saw something that is within scope but it's just not very interesting looking and not worth wasting any time on load balances and analytic systems are everywhere but they're just a bit boring they form a lens in front of website still we're used to looking through rather than at in this session I'll share with you proven techniques to hunt these systems down crack them open and use them as gateways into our targets infrastructure some of these techniques involve requests so malformed that they break certain hacker tools and may exploit systems that you never even realized existed right at the start of this research I wrote a simple payload that was designed to make vulnerable systems send a ping back back to my server and I send that payload to a couple of thousand sites and I got quite a few pingbacks but there was something slightly strange about a few of them I noticed the ping backs coming from cloud mailed over and Inga comm were coming from the same ip address which was a bit weird because you wouldn't think that they would be on shared hosting and so I did a reverse DNS lookup on this mysterious IP address and found that it belonged to my own ISP which is even stranger bear in mind that this can't be caused by some kind of caching solution because they're clearly doing dynamic processing of my input or they would have been exploited and so I took the request that's in the payload and I resent it a few times in the repeater and I noticed that the response from Cloud Mayor was coming back to me in about 52 milliseconds which is suspiciously fast for a request that's supposedly going for me in England to the server in Russia and then all the way to the ping back server in Ireland and then all the way back again and so I decided to do a couple of trace routes the one on the Left simulates a HTTP connection because it's a trace route to port 80 and as you can see this connection is never getting on to the actual Internet it's being terminated inside my ISP whereas the HTTP connection goes all the way to where the server is actually located in Russia you can see that on the right and that is even more suspicious because it suggests that the person who's doing the interception doesn't have their HTTP secret keys that would enable them to actually intercept HTTPS safely and without notifying the user so it means this interception is going on probably without the permission or knowledge of cloud mail government and also I found that this was affecting not only me at work but also on my home connection so this was affecting all consumer and commercial users of BT Broadband BT Broadband being the largest ISP in England by quite a long way and I investigated this further and I found out what the purpose of this system was and I found out that I could potentially you hijack the system using the vulnerability in it and make alterations to the traffic of millions of BT users which would be kind of cool but that's just a distraction from the question that we should be asking which is given that for many years I and many are the British pen testers have been doing the security audits through an exploitable proxy system without ever realizing it what else have we missed there was one other suspicious thing about this server which was that that was a reverse DNS was hoped to predator door alias not BT dog coat UK which doesn't exactly suggest this is a friendly kind of system so first I'll talk about how to build a speculative attack pipeline then lets us efficiently hunt these systems down and initiate a conversation with them after that I'll describe two key types of attacks one focused on targeting front-end systems like reverse proxies by making the Miss route requests and one focused on targeting back in the system like analytic systems where we have to be a bit more inventive to actually get to a useful exploit after that I'll do a brief demo of one of the tools I'll be releasing and then wrap up and take five minutes of questions the systems that we'll be targeting are designed to remain invisible and as such the process of finding and interacting with them is really important otherwise you just won't for even finding systems for the purpose of this research I sent payloads designed to make vulnerable servers send a DNS or HTTP query back to my server this approach to finding vulnerabilities has been so effective in recent years that my boss recently coined an acronym for it to try getting more attention to it so we call it Oh asked out-of-band application security testing and if I use that acronym now you know what I mean it's just trying to find a vulnerability by sending a payload that will cause a ping back at the start of this research I had absolutely no idea if anything was actually going to work and as such I injected payloads in the laziest way possible I simply made a burp match interface rule that put a hard-coded payload in every request that got proxied through book and then just browsed some websites and that found quite a few interesting bits of behavior but it didn't get me much useful information because it didn't correlate the paint back that my server received with the payload or the request that caused the ping back so in many cases I couldn't even tell which website a ping back was coming from I thought I could correlate it by looking at the time the request was sent and the time the ping back happened but that doesn't actually work in many cases for example what we've got here is a server that for some mysterious reason it's decided to ping me once every 24 hours and it just kept doing that for days and I was never able to find out what caused that behavior what's this then that was will actually get anywhere useful with that so to fix this issue I won't collaborate everywhere which is an open source burp suite extension which injects a number of unique being back payloads into every request being proxied through and it uses those to automatically correlate the requests with the response Oh with the pingback so even if you get a ping back 12 hours after you send the payload it will still be able to link those together for you and give you some information that's actually useful now that to work pretty well it found about half the vulnerabilities that I'm going to show you in this presentation but I noticed on one site it was only finding an issue intermittently and that was because they were using a round robin DNS to point me to one of their five front-end load balances and only one of their load balances was vulnerable so when you're targeting front-end systems you need to bear in mind that you need to hit all of the systems rather than just an arbitrary one and to do that I switched using masscan and then eventually switched using Z grab which is basically masscan but with more useful features for sending attacks the websites so if you want to do a focused manual audit on a specific site collaborate Everywhere is the best tool for the job but if you want to send payloads to thousands of different web sites and spray them over someone's entire infrastructure Zed grabbed is the way to go so who did I target well I targeted everyone that I could legally target which means every site that has a bug bounty program that doesn't forbid automated testing and to identify them I manually reviewed every single program on hacker one and bug route which was quite boring but at the end of that I had a spreadsheet from which I could generate a regular expression that would match any domain name that was within the scope of any bounty program that I could legally test I then combined that regex with rapid evans project sonar database of all known host names and by combining those two I had a short list of three million hosts that I could send payloads to they were all within scope of bug bounties and I hadn't actually had to send any requests or do any DNS lookups myself that was over to about 50,000 active web servers I initially populated this list of targets also using reverse DNS lookups but I only do a little bit of a problem with that the problem is the google has got a bug bounty program and some websites for whatever reason that like to spoof Google's reverse DNS they like to pretend to be Google I'm not entirely sure why they do this but the result is that if you use if you trust reverse DNS you end up sending payloads to people who are probably not expecting you to send payloads to them and might not be too happy about it now you could argue that they're asking for it but in making that reverse DNS setup but I wouldn't recommend that overall now if you're gonna send in requests to 50,000 web servers you might as well make sure that it's optimized to hit as much attack surface as possible one way to do that is using the mode transform directive for the cache control header which instructs systems like reverse proxies not to rewrite the request in any way that before passing it along because that might break the payload that you're sending also you could try resending your payloads but using their exported proto header to pretend though you're using a protocol other than the one that you're really using now which can also just cause unexpected scenarios and let you hit code paths that most people never touch the end result of the setup was that during this research whenever I had an idea for a new type of technique I could spend a couple of minutes writing HTTP requests manually with that payload in it and then user draft us in that 250-thousand web servers in the space of about five minutes and just collect the results that capability to quickly try out ideas and then iteratively improve them is a large part of the reason why this research was so successful okay that's enough about the tooling and now for some exploits so first of all we're going to target things that sit in front of the application how we're going to try and trick them into routing requests to internal services this services that are meant to be private so this is a type of server-side request forgery but it's a lot more powerful than your rock than your run-of-the-mill SSR F that's because we've got generally here got a huge amount of control over the requests that we're sending to the internal service which makes it much easier to exploit internal services as we'll see shortly the simplest way to make your request get miss routed is simply to change the host header to where you want the request to get routed to this approach works on an amazing number of sites now this technique is publicly known in some locations but it's hugely underappreciated I can say that with confidence because using my pipeline I just mentioned in the space of five minutes I was able to exploit 27 different Department of Defense servers a couple of Yahoo load balances my only ISP by accident and also a Colombian RSP that threw itself into the firing line by doing DNS poisoning on one of my targets so let's take a look at what the impact of this very simple mishap can be here I'm sending a request to one of Yahoo's load balancers and I'm using the host header to trick them into routing it to port 8080 to on on a nearby IP so the service I'm accessing that you can see in the response is not publicly accessible now judging by the repeated are unknown command lines in the response this service is not talking HTTP it's using some kind of line based protocol and is therefore interpreting every HTTP header as a separate command other than that I had no real idea what the system was but I had an idea to find out I changed the HTTP method from get to help how amazingly that actually worked so the service was like hi i'm i'm an apache traffic overseer which means i'm responsible for distributing the configuration of probably a large number of Yahoo's front-end load balance and also here's how you can change configuration settings on me now know that if this was no more server side request forgery it would be impossible to exploit this service because to get in second man's we need to send requests to have white space in them and you can't do that with a normal server side request forgery but because we can send pretty much whatever the quest we like it's actually pretty easy to exploit this system so here you can see at the top I'm saying what is the value of proxy configured or alarm email and they're like hey yep that's set to nobody at Yahoo Inc com perfect and by setting variables I could potentially whitelist to my own external IP address to give me permission to push items into their cache and overwrite items in all of their caches which would give me the ability to deface a good number of the Apple services also I could enable Sox Fox seeing on all of their load balancers thereby giving me full IP level access to their internal network which would be pretty nice disadvantage with that approach is that it would also give everybody else full tcp/ip access to their network which would make things pretty short-lived I think I reported this issue to Yahoo and got a fifteen thousand dollar payout for it so that was pretty cool and I found this issue using thank you there's more where that came from I found this issue using collaborated collaborator everywhere and when I made that and they fixed it pretty fast and when I made that pipeline I mentioned a couple of weeks later I found another server with the same vulnerability so I got another five thousand for that for twenty thousand total which was a really good start to this research as mentioned the same technique also worked on my ISP and I could use it to make this set of proxy servers route my request to their own administration interface and if I could prove force the password on that or he was using default credentials they don't have a bug bound program so I don't actually know if they were I could I could use rewrite rules to like do rewrite the requests of millions of BT users which would be quite nice but what I really wanted to know was what is the point of this interception system was what is it doing and to try and find out I did a trace view of the whole ipv4 space well the tto of ten which meant the packet never left to my ISPs infrastructure and that showed me the roughly 5% of website IP addresses had been blacklisted and would be routed into this proxy system there's an interesting side effect of that which is that if your website hypee address is on this blacklist perhaps because you were just using cloud hosting and you've got no control over what IP address is you're on all traffic from all BT users which is the majority of England is going to come from about five IP addresses and that means if you're doing any IP based authentication it's gonna fail horribly and also if you decide to IP ban any of these users for bad behavior you might end up banning a substantial part of England which wouldn't be much good anyway after your traffic if your request is to one of these blacklisted by piece it gets routed into this pool of proxies and then they apply a black list of hosts names and if you're trying to access a dodgy hostname like icefilms thought info you see this message which I'm sure none of the upstanding English people in the audience have ever seen before it says access to the websites listed on this page has been blocked pursuant to orders of the High Court although of course it's pretty easy to bypass so it looks like this system is being used to prevent copyright infringement but when I reported the admin access vulnerability to BT I got a little bit of backstory this system was actually originally built as path cleaner feet which is a government initiative to block access to images of child abuse it's just that after it was made here was quickly repurposed to target copyright abuse a while later I send a payload to a different Russian application this time it was vk.com and once again got a ping back from an unexpected location this time it was from Columbia nice ISP called Metro tell and because they're not my ISP I knew that to get my payload to go to their server they had to have done DNS poisoning and I was using rapid sevens DNS database so I contacted rapid7 and they hopefully identified the responsible DNS server and then I did lookups for the Alexa top million through this server to figure out who they were targeting that showed that they were mostly focused on image hosts and social networks and if you try to hit some of those you would gain once that you just get blocked and it would say access to this has been blocked due to images of child abuse along with this logo here however once again that's not all this system was fought because they were also poisoned the DNS for BBC dog code or UK which is a news website and I don't think you'll find many dodgy images on that site which raises the question of why they want to VU all traffic to that site through their proxies unfortunately finding out why is quite difficult they weren't doing any kind of injection or rewriting on all all requests as far as I could tell so they're either targeting specific articles and maybe blocking access to or changing the content of those or maybe they're just passively watching maybe they simply want to know which articles on the BBC you're actually meeting so they can pass that information along to someone now although the payload that I've shown you is really very simple thinking you can reliably predict what will happen when you send that payload it is always a mistake I found seven Yahoo servers that would take the host header that I gave in this case recap not me and they would route the request to outage dot that host header and I would also put the host in the path twice now I've got no idea what the point of a is but luckily all I need to know is how to exploit it and as presented there it's not much use right because you're just going to get a 404 from whatever internal server you here fortunately this the vulnerable service that was rewriting the request was incredibly tolerant of what you put in the host header so if you sent the following host header it would rewrite it as you see on the right and that request to when the back in the server gets it will get normalized to enter a request to the web loop so we can actually fetch pretty much arbitary stuff using this technique that got an another 5,000 of your home to be honest I'm not sure why the bounty values from Yahoo varied so much they seem to be a little bit random but that the total amount was a good amount of money so I'm not really complaining anyway the moral of this issue is that on your on your server that's receiving pingbacks you need to use wildcard dearness to make sure that you receive everything that's been triggered by your payloads know this request may look familiar I used it back in 2013 to poison Django's password reset emails but here I found this certain US military server which would move the request to wherever I specified in the request line so I think they had a white list of acceptable hosts but the request line takes priority however I had a little bit of an issue here which is that I wanted to prove I could access an internal service to show that this issue had some kind of severity but I was too nervous to do a proper internal port scan on a Department of Defense server so instead I decided to Google a bit and see if I could find anything useful and I found an amazing forum post on defense of caring comm it says if you're looking at this and I'm not in the military or DoD then this won't mean anything to you nor will you be able to access it and then it linked a couple of internal Department of Defense websites and sure enough using this technique I could access them so that was handy I think the mall here is number one I if you can of avoid during a port scan of someone's internal network I would recommend doing so people can get quite twitchy about that Yahoo's certainly did and also the lord of the target company less likely is that you actually need to because people are just leaking tons of useful stuff online now although the network diagram only shows one proxy server it's possible that some people like to chain proxy servers and if you want to target the server in the middle of a chain that can make life a bit difficult because your payload is likely to get rejected by the first proxy in the chain for example in caps Allah uses the host header to work out which of their clients to route the quests onto so if you try the normal payload that I showed at the start it will just get dropped fortunately in caps Allah is incredibly tolerant about what they allow in the host header basically they ignore everything that comes after the colon in the request so you can send a request like the one shown there and encapsulated will route on to the target and then the target or a particular target that I found in this case would rewrite that as a URL like so and it would end up getting routed to where by choice so even though that target hadn't captured in front of it with a bit of creativity you can get around that and still get your server side request forgery this adds a slightly cool side effect which is because the payload cause the backend to connect directly to my server that told me exactly where the backend was and off from that point I could speak directly to the backend and just and just avoiding capsuleer entirely so although this isn't strictly a vulnerability in encapsulator it's still probably something they might want to think about fixing these vulnerabilities aren't just caused by misconfigurations what we've got here is some code that New Relic had on their main on their main official web site and well it probably looks absolutely fine to you it does tomato to be honest it just takes the user supplied llamó and it over writes the host and the port specified in that URL with a hard-coded one of the internal server that they want to root your request to unfortunately for New Relic they were using the Apache HTTP components library for their server and this server fails to require that paths start with a forward slash so that means if you send a malformed illegal HTTP request like that then their code rewrites it like that and once again they're accessing a server of my choice with a username of back-end server so this got me access to new relics internal network which had some amazing stuff on it for a start it had some incredible developer in jokes such as this page which was blasting out music and had marquees and everything they also had some administration panels with no authentication on them which was cool now unfortunately New Relic don't pay cash bounties but to their credit they patch this issue really quite fast on a public holiday and they also reported this problem with this problem back to apache HTTP components where it's now been fixed so if you're using that library then you don't need to be panicking right now as long as you're using the latest version of fortunately for me this technique also works on 17 different Yahoo servers so I got another $8,000 now that made a total of of 33,000 which is how much I enter in bounties during this research and you might be wondering what happened to that money now when I started this research I had to deal with my company that any bounties I owned would get spent on beer however we were fairly small company in spending thirty two thousand dollars on beer was looking like it was going to be quite challenging so we gave the majority to charity and spent a small amount of it on beer so possibly the strangest behavior that I saw during this research was courtesy of our website called called global eeks which is a bit like WikiLeaks except actually legitimate and so what I found these guys was if I sent them the following HTTP request which is malformed because it doesn't start with a forward slash then I got about 15 DNS lookups all in mixed case coming from different IP addresses which is definitely not what I expected to happen now eventually due to the nature of the site and the fact that all the IP addresses the lookups were coming from were different I had an idea as to what the cause of this behavior might be because this is a whistleblowing website they want to hide the physical location of their back-end server to stop like governments from raiding it in that kind of stuff so they connect to it as a tor hidden service so what I've got is server side request forgery through talk which is quite interesting from an exploitation perspective so it going through tor is the reason that all the IP addresses of the lookups are different they're coming from different exit nodes and also the mixed case DNS lookups are the result of a fairly obscure mechanism that tor users to try and increase the entropy in DNS by making the requests a mixed case so the impact of this is hard to qualify because I can't access the internal network it's definitely server side request forgery but I'm accessing whatever I try and access through tor what I can do though is get a decent expansion of attack surface because I can make their client their talk line to connect directly to my server and if I've got a vulnerability for a tall client then that could be quite useful also I can potentially use it to obscure and attack on a target because I can use them as a hop and make them route my payload through tor to my target and that means even if the attack gets traced backwards through tor they'll just end up looking at this highly suspicious global links website that probably doesn't keep any logs and won't be able to figure out that it was me right now let's talk about exploiting helper systems unlike miss routing attacks with helper systems causing pink backs is often really easy but exploiting the systems in a meaningful way it can be quite hard that's because a server-side request forgery we found in back-end systems is normally blind which means we can't see the result from the internal requests we've triggered which means we can't adapt our attacks based on what we see this research started on a really old website that had an amazing sentence on it it said the extract profile header should contain a URL pointing to an XML document that specifies the features of a mobile device so it specifies the specification gives you two amazingly 5s pieces of functionality one you've got to fetch a user supplied URL - you've got a pause the resulting untrusted XML file and I immediately try this out on a bunch of websites but it didn't work on any of them sadly probably cuz it's so old so I just tweeted it and then I got a ping back from Facebook it turns out Facebook does support this but they fetched the URL you supply about 26 hours after you send the request unfortunately their implementation of this and their XML parsing seems to be secure as far as I can tell although the fact there was a 26 hour time like that between each attack made it really tedious so I might miss something so if you want to try and hack the hat feel free fortunately there are many other useful ways to trigger pingbacks from helper systems that are actually effective are widely supported through a fervor header is the most popular one a huge number of websites you will not believe how many websites do this will fetch whatever URL you specify in the refer header I'm not hundred percent sure why they're doing it by assume it's for some kind of analytics purpose so that's probably the most effective way of tricking pingbacks and back-end systems but also you'll be familiar with the x-forwarded-for header you've probably used it to spoof your IP it also supports host names and if you specify a host name in there then you can use the fact that you did or didn't receive a DNS lookup for that host name to work out whether they're trusting this header and therefore whether it's worth using exploits that try and take advantage of this and similarly the slightly more obscure variants to client IP and excellent ex via IP can be used in exactly the same way also for some reason capsular will fetch any URL that you specify provided that you specify it with the same parameter name twice I have no idea why they're doing that I only found it by accident because a bug in my code meant that URL famis has got specified twice and I don't know if it's exploitable because they don't have a bug bounty program so I'm not allowed to actually try and find out but there you go so say that a site is stretching the URL specified in them afirma header I so what what can you do well one option is to try an off-the-shelf exploit for example you can make them connect to your server and run responder on your server which is a wonderful piece of code that tries to trick connecting clients into linking credentials to your server I out on all of my targets it didn't work on any of them but while I was trying it out some random guy with the vulnerability scanner hit my server and did get exploited so I still count that as a kind of win you can also trow a pacemaker which is and which is a Python the fake as a cell server that tries the lesser-used client hardly an attack on connecting clients and I did work on one of my targets so honest I thought I had blind server side request forgery on I was able to make them connect to my server and rida memory from their back-end which was quite cool also you can do you can use tools like tough to do tcp/ip fingerprinting and they're like but that's a bit boring why off-the-shelf exploits only get you so far what else can you do well you can do more Oh asked so you will have found this behavior using a pingback technique but that doesn't mean you have to stop using those techniques you can take the latest struts to remote code execution the week and revite the exploit so it triggers a ping back and then make their afirma caller spray that payload across their own internal network and maybe you'll get some shouts even better some of these clients that fetch the referrer vendor the page that they fetch using phantom Jes or the like and that means that we can make them spray a cross-site scripting payload across their own internal network and if that works then we can inject a beef hook onto that site and we've got full access like persistent access to an internal website which is pretty nice so I've decided to dub this blind reflected server-side XSS also depending on how they implement cross protocol access restrictions in this thick line that they've been doing pages with you can potentially get XSS in local files like Fox elf environment that can mean if you can pull that off that can mean that you can potentially use javascript in a local file like that to read files from their file system on their server which is once again pretty nice in fact if they're rendering there are loads of interesting things and loads of questions that it rates its for example do they even enforce the same origin policy because some of them don't and that means you can basically use them as a permanent proxy with the right JavaScript code also maybe you can open a pop-up that subsequently won't get closed giving yourself persistent JavaScript execution on their server and you know what plugins do they support that could be interesting to answer these questions my colleague Gareth Hayes wrote a tool called hack ability this is a website that you can connect you in a browser or anything that will render a webpage and it will perform tests to try and answer these questions for you it will show you the answers visually and it will also trigger requests to the server so even if this is a blind server side request forgery vulnerability that you've got you can just look in your server logs and see what the results of these tests are with this particular example I've pointed parity at this which is the second most popular Ethan client most notable because last week someone hacked it and stole 30 million dollars worth of beef earring using it and it integrates into a web browser and what hack ability has spotted here is some interesting objects in the JavaScript environment so these are objects that are not present in a normal browser environment which strongly suggests that parity itself has injected them and sure enough using those you can do things like you can get the current uses he theorem wallet my ID and potentially see what balance they have in that wallet and also initiate transactions and other kinds of interesting stuff ok it's time for one final exploit this one's my favorite I've got the best the last here I sent that payload that I showed you right at the start but the request they didn't get Miss routed it got routed correctly but several seconds after I sent it I received some attempts to request certain resources for my server and I confirmed if I try to load a history of blimps page on this military website and on why is this slyly then the server would try to grab a picture of a blimp from my server which is pretty weird I wonder if we can exploit that it's obvious that well the only explanation for this is that there's some kind of reverse proxy some kind of caching reverse proxy that's scanning the sponsors from the application looking for resource import statements like image source equals and is then fetching those presumably so it can cache it so maybe I can send a request to the application that triggers a response to me that makes the reverse proxy fetch an internal URL that I don't have access to and cache the response and then I can just grab it out the cache hopefully so I found some some normal reflected XSS in the target and I used it to inject the following the spots so from the proxies point of view this is definitely a static image import I'm using the image source equals state and the foil name ends in a dot jpg but from the backend the server's point of view this is a request to the root of a PHP application so the proxy saw that response that I injected through XSS they fetch that euro and they cashed it and then I was able to grab that out of the cache so the key problem here is that we've just got a foxy that's really enthusiastic it will cache anything it sees regardless of what the main it's on and it has no concept of things that should be internally accessible and things they should not okay looks like it's time for a brief demo I'm going to demo collaborate it everywhere so I'm just gonna enable that okay it works good so you you can see here it's worked out what my IP address is that's because sometimes when you're browsing your browser will cause interactions and if you don't realize that Zuko's and them you can get very excited before you found out found out that you haven't really achieved anything whatsoever so now I'm gonna load Firefox and it's gonna ping open a bunch of websites please no I'm not demonstrating vulnerabilities in these websites I'm just demonstrating interesting behavior in these websites as far as I know none of these issues that I'm none of these websites have exploitable issues I mentioned Facebook but that one's gonna happen in 26 hours times so you're not actually gonna see that one so if we look in burp then you can see that's the normal request that the browser sent but collaborator everywhere has rewritten it and it's injected a lot of payloads it's called collaborate everywhere because it just injects payloads everywhere and if we look at the target then we can see that we've got some interactions so for example here strike after two seconds has fetched the euro specified in the referer header over there and we can see that they using Ruby and the next thing to do would be to point that attack ability and work out how how to exploit it but also here's wonderful Netflix I triggered this earlier because there's a nine hour and 30 minute time gap in between you send you send in the payload and them getting the response yeah interestingly here they claim that they using an iPhone but they also claim to be using an x86 CPU so yeah I know which one I believe also we can see some people using the true client IP header which is less well known these guys fetch it after quite a few hours and interestingly so these two payloads both come from Starbucks but they come from completely different servers after a different length of time so this has given you a point as to a back-end system so as well as being useful information that they support this header you now know what back in the analytic system they're using and maybe you can just go find their website and exploit that if you're a proper hacker and similarly loads of guys use X for it for okay all right so as far as replicating these issues goes you can like you can replicate them all of them are using burp of course so I wouldn't found them as of today there's an update to burp that will make it scanner or to automatically find all of them all of the vulnerabilities are found about now you could replicate these issues using this app if it wasn't for issue one three one eight which I'm imported to them a few years ago which means that if you change the host header in zap does that will send that request to the wrong place so if you want to use an open-source tool I'd recommend using MIT M proxy it's extremely late looking so now if you want to help your clients replicate this issues they might not be familiar with any of these tools so you probably want to give them some kind of shell commands you can use curl to replicate some of these attacks but the more mount the ones with in a more malformed the more advanced attacks can't be done using curl so you'll have to use end cap and then just pipe that your so you have to use echo and then pipe that into end cap or open SSL as appropriate also you may need to use a server name Drive active with open SSL to set the server name indicator field to make sure that it gets routed to the right place so how do you prevent these attacks cool as far as the reverse proxy attacks go I think you just have to acknowledge that reverse proxies are designed to proxy traffic so they're going to proxy traffic and only takes a tiny bug to make them proxy traffic to the wrong place as such they should be put in inside a demilitarized zone where they don't have access to anything sensitive where they don't have access to an or thinking unauthenticated administration panels as for callers it may help to think of them as employees with really old web browsers who click on every link that you give them on the brighter side unlike employees they won't complain very much if you stick them in a sandbox so once again that's what I recommend as for research is what I recommend welcoming researchers if you've got a bug bounty program that's public and allow us automated testing I've probably already tested your site so you can have a little bit of peace of mind so I see a lot of bug bounty programs that forbid automated testing and I understand they're probably doing that because that otherwise they get flooded with traffic by people scanning them without genetics and burp millions of times so what I recommend doing is saying please don't use off-the-shelf tools on our website but still allowing the use of custom tools so the three key takeaways are the bug bounties enable white hat research its scale load balancers our VPNs for the public and coolers our employees who click I'll take five minutes of questions now and if you have any more after that feel free to come and speak to me at the back or semi and email don't forget to follow me on Twitter thank you for listening [Applause] [Music] [Applause]

Channel: Black Hat

Views: 46,694

Rating: 4.9260778 out of 5

Keywords: DoD, Black Hat USA 2017, Burp Extension, Information Security, Black Hat, Black Hat USA, Black Hat 2017, Web AppSec, BHUSA, InfoSec

Id: zP4b3pw94s0

Length: 44min 6sec (2646 seconds)

Published: Tue Nov 07 2017