Easy Ways to Bypass Antivirus Systems

thanks to everybody for organizing besides London I'm glad to be here to talk to you and I'm going to be talking a bit about what I do as a security researcher for trip wi vert so uh this talk is primarily focused around the ideas of being able to do um security focused quality assurance testing so if you haven't had any exposure into pen testing before and you have a product that you need to start finding vul this is going to give you all the tools that you need if you are a pen tester already it might teach you something you don't know already um but more or less its approaches to manual fuzz testing to

find vulnerabilities so using these techniques I found quite a few vulnerabilities back in February when I had put these slides together these were the CVS that I had assigned already this year um so like I said we're going to be talking about identif vulnerabilities the processes that I use the tools that I use and I'm going to reinforce this with some Hands-On so some applications which I've identified over time as having various vulnerabilities and then we'll talk a little bit about what we've talked about so before you begin any kind of pentest or application pentest you need to consider what kind of Target are we dealing with are we if we're dealing with a web application versus an

embedded device versus just a raw Network protocol all of these different things are going to have different approaches and you also have to be considerate of what kind of platforms you're running on top of so is it Linux is it Windows is it running various server side scripting languages like ASP or PHP and of course database is underlying different security vulnerabilities and different semantics for your testing so I've set up um what I like to refer to as a security testing tool belt and in this we have your Hammer which is your fuzz testing where you're basically just banging away at something until you get it to break uh static analysis which is kind of more like your magnifying

glass you're taking a closer look at the binaries themselves seeing what calls are made in them what you might be able to find that's unusual Source review this is your microscope of your tool belt this is uh where you're going to actually look through source code whenever available and look for patterns of vulnerable code that you can inspect further and of course firmware analysis uh applying mostly towards embedded systems of course so to start out by talking about fuzz testing everybody should more or less be aware of this but the general idea is that you're going to take some input that is expected for an application you're going to manipulate that input so that it is not well formed

anymore you're going to execute your target process you're going to look to to see did it crash did it do something else unexpected any of those results get recorded and then you go back into your Loop of manipulating the input running your process etc etc and then at the end of the day you hopefully have a nice list of uh crash dumps and things like that which you can review for exploitability so with web vulnerabilities um I'm going to talk about four of the primary categories of vulnerabilities which are very common to find and sometimes very easy to find first on the list you've got cross-site scripting so this of course is whenever you have the ability

to inject client side code into a web page so that it's executing in the context of that domain gives you access to cookies things like that uh C surf on the top right here this is cross-site request forgery it's when a web application has requests which are ultimately predictable you're able to actually craft up a web page and make it so that your web page is going to send out messages to another web application that web application isn't going to be able to distinguish this request coming from your app versus a request coming from legitimate user because of some things that we'll talk about in how the browser Works injection um this is a category that covers a lot of different

things so you can have injection of operating system commands ml injection of course you have SQL injection elap injection and finally we'll look a little bit about file inclusion and so these are vulnerabilities where you can as an attacker do something to influence what code is actually going to be loaded on the server side so back to cross- site scripting in general cross-site scripting is going to be a failure to sanitize certain values which get interpreted as HTML so since you can use HTML to invoke JavaScript contexts then when this HTML gets rendered by a vulnerable application content is going to run as if it was legitimate content from that domain this tends to get introduced when

you have things like what we have up here um you have a format string which is being used to create an image tag if you imagine that that percent s is being replaced by the input that I've shown up here on the slide you end up with an image tag that has an invalid URL and an onerror attribute to load some JavaScript in this case just an alert popup with the message one now some of the things that we use to look for cross-site scripting um are called cross-site scripting locators naturally enough with these different formats they affect different browsers differently like for example the SVG onload this I've seen sporadically work in Chrome pretty much consistently work

in Firefox the image on airor tends to work very effectively although is more commonly filtered by basic cross-site scripting filters and then the last locator that I have here is one like from the previous slide where let's say the user has the ability to control the H or the source for or some image tag or anchor tag you can then if it's not being sanitized inject a string that's going to include an error Handler and launch your xss payload so on the bottom line there that xss equals alert 1337 you can imagine that's what you would put into all of the locators or something along those lines uh could be alert document.domain or document. cookie it's just an easy

way to recognize that your script is actually executed with OS injection um this is generally going to be a situation and an application where it needs to be able to run system commands and it needs to be able to do this based on user input so the use of eval functions system functions any of these that are taking user input without being sanitized they can all result obviously in unintended code execution so for example if you're using the Pearl e eval command and you have an eval command that simply takes one of the parameters from your url adds some parentheses to make it function call you can very easily exploit this by putting in a value with back ticks semicolons

things of that nature which are going to be expanded by the shell to run some commands in the context of whatever was running this Pearl script so some of the locators that I like to use for doing this um the first one up here is using the pipe command which of course in Linux is going to take the output of one command standard out and pipe it into standard in of another so it will trigger command execution if it's not filtered out uh you've got an another option of using back ticks with an echo and then actually providing into that Echo valid input if you run this and it works then it probably means that either they've got

some very nice casting going on that's finding the value that it's supposed to or you've actually executed that Echo command and things are working because you're injecting commands the last one here I call this ping injection because you find this on basically every Soho route or anything that's uh allowing you to do pings or Trace routes stuff like that in this particular example you'll see the IP address is invalid so if that gets passed into ping it's going to fail and when it fails your double pipes are going to say okay go ahead and run the other command you name so in this case if you plug this into a vulnerable ping function the output that you would get

would be output indicating the uname from the target system assuming it's a Unix system or Linux system now with SQL injection um this is going to be of course whenever your application needs to be able to access a database you have the possibility of having SQL injection this happens if you do not properly sanitize data going into your SQL queries common theme coming up here not sanitizing input leads to vulnerabilities and of course if somebody is able to insert new SQL into your SQL careers that your application is making they can basically take control of your whole database especially if you're happen to be logged in running the queries as a DBA so some of the places where these

types of problems come up um of course again when you're using format strings like if you see here we've got the percent s's that should be an immediate red flag of course it's possible that the inputs to these format strings could have already been sanitized but more often than not it's just direct user input and the proper thing that the developer should have been doing in this case would be to use a parameterized library where you're giving it percents and passing to it parameters and that way you're relying on the library to make sure that nothing unexpected is going to happen um in this example that I've given here if you plugged in that input

for password the x or x equals x you're going to be able to log in as any user simply because it's a very very poorly designed system usually passwords of course would be hashed but uh this is just a basic example so some of the locators that we use for this um the first one here on our list is the x or xal X the reason that this works is because you're giving it a Boolean alternative so if there is a check that's saying is username equal to whatever you're saying is the username equal to whatever or is x equal to X and the end quote is of course missing because you're assuming that the

application is going to fill that back in now with the other examples I have here for Locators first you've got a numeric injection type and this is ending with comment characters because of course you want to nullify the rest of the statement this can create problems if you're trying to inject into say a complex nested SQL query but more often than not it's helpful rather than hurtful and also the having one equals one is in here because if you're familiar with SQL you'll see that sometimes this is helpful for being being able to get an injection that's going to work later on in a query so the way that you're using these locators I felt this needed a special

note since I've received a lot of questions about it typically you're going to plug in one of your locators if you see different results than when you are not having the locator in there like for example if you see extra data coming out of something it's a good indicator that there could be SQL injection so then the next test that you run is to flip your Boolean logic so rather than doing X and xal X Change it to X and xal Y and if you're still getting output out then you had a false positive but if all of the sudden your output goes away you just found yourself a SQL injection point so now we're going to move into

the first case study is anybody in here has anybody used review board it's a popular application from or which Apache KDE various open source projects as well as corporations like trip and IBM use internally for facilitating the code review process so I did a little bit of analysis on this application I'm going to go through the steps that I used to find flaws in it so first um starting point was to scope out what we're looking at this is a web application it's python based uh it runs on a variety of HTP servers it runs with a variety of database backends and from this we can kind of compile a list of possible vulnerabilities which I've done so on

the right here so since it's a web app we're obviously going to look for cross-site scripting cross site request forgery since it uses databases we're going to look for some SQL injection we're also going to look for lfi and RFI is there your file inclusion vulnerabilities simply because it's a web app and there's a good chance that you might have some room to get some new code uploaded onto the server and of course OS injection is a possibility because this is a web application which integrates with tools like git and other RCS systems so there's the possibility that somebody could inject their own commands into that and own your server so let's start by doing some

fuzzing on this the first thing that you see when you log into review board is that at least under the default configuration it's set up so that if you don't have an account you can create an account um so that's what we're going to go ahead and do and in the account creation field you can see here that I've entered my name and a username and a password but for my real last name I've got this SVG onload tag which is is one of the the cross-site scripting locators that we talked about a little bit earlier and so right away by browsing through the web interface for this tool I found that when you go to the submitters list it

presents that full user's name without sanitization so you can see our popup 1337 yes you can read it on the slides that's good and then again I found that when you go and you want to assign a review to somebody you start typing in their name it has a nice little Auto complete widget this autocomplete widget of course renders the name without sanitization again so you got a popup so these were two CVS that were assigned the first one of course that submitters list not being sanitized the autocomplete not being sanitized and Christian Hammond of uh the reviewer board project was very good about implementing a fix wherein their underlying Library would now sanitize everything globally so realistically

there shouldn't be scripting vulnerabilities left so then if we talk about what kind of risks there are from not updating this or if you wanted to say show to your management or um in a professional engagement show to your customer that there are actual serious risks as a result of this vulner these cross-site scripting vulnerabilities being unpatched you can spark up Cal Linux load up backtrack or load back load uh beef rather or you can load beef on any other box and this is an excellent tool for just gives you a little script that you can in use in your crosslite scripting payload and then you can't really see it here so clearly but there's a little

screenshot showing what it looks like when you've put something on your meat hook in beef and from there you can do things like injecting um Metasploit exploits into a page you can start enumerating cookies look through what sites have been visited on the browser there's even the ability to do limited keystroke logging through it so what this all teaches us as developers we have to be expecting the unexpected you can have situations where you're going to trust output because it's coming from a system caller it's already in your database but really you need to think about has this data been sanitized some before you're getting and if the answer to that is no you treat it as tainted

and you sanitize it so when I looked at IBM websphere uh last year sometime I found that they were not doing this so system calls for enumerating the file system of course under Unix you can have file names which have greater than and less than tags these can be used for Cross or for HTML attributes HTML tags and in the websphere administrative console they have actually a little file browser where you can go through and you can see what files are on your server now if somebody happened to be able to create files on your server with special file names when the administrator goes to browse that they're going to have a cross-site scripting payload run um this

is actually a really common mistake I've seen this on more than one Google service it's paid out of bounty um I went back to review board and I looked at review board considering whether or not they might have the same type of problem so the text is kind of small up there but you can see I'm uploading an attachment to a review which has a name that's a cross-site scripting locator and the actual file name itself was or is a cross-site scripting locator with a PHP extension so upon uploading it we see that this was properly sanitized that's the output something like the output that you would want to see you don't have a popup you

see ersan LT although that's a little weird you should probably see angle brackets and the file name itself has been sanitized in such a way that we have underscores instead of spaces and our uh carrots are completely gone but when we actually click that file we have a webshell so this is a file inclusion or remote code execution vulnerability there's a bit of stuff that we could do from this console and attacker would be able to start running commands on your server browsing files uh creating connect back shells things of that nature so this vulnerability stems from the fact that Review Board gets installed by their re their install process their install process sets up uploads

directories and it doesn't bother to actually or didn't bother to actually set up permissions on these upload directories to prevent things like PHP handlers or other kind of server handlers from running there so also you could very easily upload HTML documents regardless of what kind of handlers are installed on the server and you have perfect ammunition for crosslite scripting attacks fishing attacks trying gain credentials and of course like I showed if there is a PHP Handler or mod ASP or something like that you would be able to get a webshell on the server and this is a problem that um just updating review board doesn't do anything to fix it updating review board um and then

reinstalling your site or reconfiguring your site is the only way that you could eliminate this flaw and they did that through adding specific content handlers and removing unnecessary content handlers or recommending that you use a Content delivery Network so we just talked about all this I'm not going to say that again but let's move on to wireless IP cameras has anybody in here considered or used a wireless IP camera for home or Office security few hands so I myself I had the same desire um I go on a lot of trips so I wanted to be able to monitor my home remotely so I bought a camera that looks kind of like that one on the top right there and I

thought Oh yay I'm going to be able to put this in my DMZ access it from wherever I want I don't have to bother going through my VPN and before I did that I de said all right we'll spend 15 minutes doing a Security review so first thing we see when we look at this it's got an HTTP interface for both um managing the device and viewing the camera feeds and on this HTP interface it's got a banner that I had never seen before the banner was netwave IP camera and throwing some basic options or options verbs add it things like that you doesn't seem to be like a fork of Apache or anything well known so there's

a good chance that it's a custom IP implementation I found out later it came from open IP cam so I decided that this would be the ripest target to look at that if it's custom HP implementation there's a good chance they made mistakes that people before them have made um there's also the very much likelihood that the web interface is going to have vulnerabilities because well most web interfaces have vulnerabilities so we'll start looking for low hanging fruit this is the management page I've got the Chrome developer tools loaded on the bottom um you can kind of read it here but this is the list of users configured on the device let's go ahead and send that

request and then in the Chrome development tools look at the request that came across now what you can see up here is that this is a get request and it's a get request that has in the URL parameters a list of every username every password every privilege and what's missing is a nons value so what happens if we have a web page that has an image tag on it and that image tag has the source referring to that the IP address of your IP camera and that set user CGI script with some parameters being selected to change your passwords well the browser is going to request the URL if your browser knows credentials for the site it's going to

automatically push those credentials out and the camera is going to treat this as an authenticated request as if you the legitimate user had gone in to change your username and password or add a new account and so the fixes for this type of problem um primarily you don't ever want to be able to change passwords without entering a password again forcing reauthentication and most importantly these types of requests should be treated with a nons value the reason for this is that if you have some unique value coming out in your page and submissions to that script are going to require that unique value to match you're not going to be able to do cross-site request forgery without

violating the same origin policy because you're not going you're going to be able to send requests you're not going to be able to read the responses unless you have some special situations so this is get based CA surf very trivial to um exploit and even if you had say some trusted websites that could be tricked into hosting an advertisement with the crafted URL or Forum pages with crafted URLs you could start exploiting this on a massive scale but this was the least of the problems with this device the next thing that I decided to look at was directory traversal and this is a bug straight out of the '90s and so I was really really very surprised and

disappointed that the camera that I just bought in 2013 would have this problem but lo and behold doing a curl for sl. doets resolve. comom shows me name server configuration from it so that's bad but let's see if it gets a little worse so when we put all the pieces together here we can see first of all there's resolve. on the system if resolve. comp is on the system then most likely this is a Linux or Unix box we're going to guess that it's probably a Linux box and in Linux we have the proc file system a lot of times proc file system is configured with mounts for M km whatever that are going to give you access to the system's

memory and in that memory you have passwords not just the password for logging into the system but also passwords for everything else that it's going to use so SMTP servers D DNS servers FTP servers that you want to load images to so I wrote a little script there's screenshot here just showing how easily you could parse out the recognizable pattern of the admin username and password this is of course actually the default credentials on the box but works just the same if you change the username and/or password you can look for things in memory that are going to precede this and easily identify that data so like I said you have the admin password being disclosed this way any

other services which are authenticated Services configured on the box their passwords are going to be disclosed so for example my Comcast mail password which was necessary for having the camera send out alerts to me during movement um that would get disclosed to anybody who knew the IP address of my camera without having knowledge of the password and in a straightforward and automated fashion and also of course you could probably Doss the device just by repeatedly requesting a dump of the memory on it it's not going to last very long so this gives a decent segue into firmware analysis in that particular case of the camera I didn't do any firmware analysis because the only way

to get the firmware for it at that time would have been to get it off of the chip uh there were no released firmware updates for it they have since given me a firmware update that they didn't post on the website for some reason but nonetheless um with other devices it's very helpful to take a firmware update like say for your dlink your neear router and Craig Hefner has a great tool out there called firmware mod kit this will allow you to it uses binwalk and walks through the file system for the update or for the file for the update looks for known file systems um extracts them mounts them and all of the data

that you get out of this you can use for static analysis and you can also use some information from it to find back doors like for example there have been cases where we've seen hardcoded user agent strings within HTTP binaries which allow you to bypass authentication and other similar vulnerabilities which I'll get to in a moment so so jumping ahead a bit because I want to kind of intermix these two topics static analysis is at least from my perspective the analysis of binaries without actually running them so this gives you a way to analyze potentially malicious code um it also prevents the process that you're examining from recognizing that you're examining it and there's lots of great tools out there for doing

this free tools you've got object dump you've got string spin walk um on the commercial side of things Ida is a great tool they also have a free version which is kind of old but still quite helpful now if we combine the static analysis approach and the dynamic analysis approach we can get some interesting power out of our firmware analysis so first we can say extract the firmware from a router when we extract the firmware from the router and mount the file systems that has we can actually see all of the files which are going to be in the public HTML directory for the web server adding on to that we have binaries on the system

like the HTP Damon we can dump strings out of that or do an OB dump of that and we can start to look for patterns of other things that look like they could be URLs or Uris buried within the code once that's found we can prepare a list and then having the device online and accessible we can iterate through this list and request every possible page that we think is on the device or handled internally through the web server and then keep notes of what data is being returned from each of them what return codes are coming out and what kind of sensitive data is in there so doing this approach on Soho routers we found that

37 of the top 50 routers on Amazon we by the way did not look at all 50 of the routers so it's quite possible that 50 out of 50 of them are having critical vulnerabilities but from the ones that we had available to us um there were vulnerabilities which were quite critical which were present on 37 of these top selling ones in the US so I'm going to do a little bit of a demonstration of some of the stuff that we found with this approach but because all of the routers are basically crap I'm just going to I've made a little masking proxy which does not reveal the strings that are being used to bypass

authentication here you can Google around for it you'll probably find it but you should just kind of think about this router as being every router because they're all about equally as vulnerable so on the top here you can see when we request the page directly we get an unauthorized message it's saying that you need credentials um on the bottom I have instead requested the page with this uh question mark replaced with magic which my proxy string behind the scenes is replacing that with some set of characters which I found to be common amongst all of the file or all of the server resources which were given to me without authentication and when I I make this

request you can see that one part of the page this uh little Navar on the side is actually being displayed and so that tells us that at least one of the requests was authenticated or was treated without needing authenication taking this a little bit further if we do a request directly to the backup CGI script on the device we can download the configuration for the router without having authentication this configuration file of course contains passwords for any services that are configured on it and of course the router administrative password so you basically own the box with without too much effort so what we did here we um assessed what files are actually on the device we went through and we attempted

to access each of the devices each of the files and what we came up with was a list of files that all were acceptable with 200 okay and some content potentially and then by looking across all of these uis that are being accepted patterns emerge and using those patterns we're able to see all right well when our request ends with such and such we're going to bypass the authentication checks and then after this was determined I opened up Ida and OB dump and started looking through the binary and realized yeah there's a check in here that's saying all right if you see certain file types you're going to treat them as not needing authentication because of course there are some things

that you need to be able to access on the system like that un off page that was up before which are going to need to be accessible without a username and password and that's essentially the root of this vulnerability that and the fact that they didn't actually enforce that the file name that they were grabbing was having this extension but rather just that the URL coming in ended with this extension so question marks could be used to fool it so what you could do with this vulnerability really the things that we've seen with like the moon worm and other vulnerability or other worms attacking routers and other Mass attacks against routers people are changing DNS settings so that they can

start hijacking sessions um you can actually upload a completely new firmware to the device which is going to prevent it from receiving future updates or giving any indication that it's been compromised and of course anything which initially would have been an authenticated vulnerability this is now exposed to you because you can bypass the authentication so some of the other things that came to light during this process um we found that error pages on one brand router in particular had a huge flaw in them in which there was client side code that was being used to determine whether or not the system was in a firsttime setup mode so the JavaScript would actually come out saying all right if admin equals and

then the server would replace the other part of the expression with the actual conf configured password uh then you're going to redirect to one page otherwise you're going to do something else that something else is irrelevant because now you have the password and also a bunch of other things like IP addresses and Mac addresses from the internal Network get revealed uh a lot of debugging information which would help you if you wanted to be able to in an automated fashion identify a router and determine what vulnerabilities you know about in it um so looking at source code review um the general idea here is that you're going to be looking for patterns within the code that are indicative of security

failings so for example the traditional memory corruption vulnerabilities came from s printf stir stir copy things like that SQL injection if you want to find this in a code base just start looking for places where you see different SQL verbs and perhaps augment that with looking for format string specifiers when you find these These are particularly suspicious and should have a second look at seeing whether or not they're exploitable and of course for OS injection depending on what language you're looking at there are a number of functions which you should be looking looking for usage in your code and verifying that it's being used safely so some tools for doing your source code review youve got grep of course um the

oos project has their laps tool which is more specific for web applications and Google is an EXC excellent resource the Google code search capabilities have turned up some vulnerabilities in the past so this is a piece of source code it's kind of C code H can anybody read it can anybody see what's wrong with this any hands what's wrong uh yes so no buffer overflow here well it's an SN printf so if you've got data being longer than buff it's not going to overflow anything it's only going to write the size of buff into there any other guesses

um yeah there could be something with that that's not actually uh the particular vulnerability that I've found in this so let me go ahead here this is actually a buffer overread in this situation uh SN printf if you have data that is longer than the size of that buffer that you're putting it into snrf isn't going to return the number of btes which were actually written into the buffer but rather the number of bites that would have been written into the buffer had it not been a bounded string function so on the next line when you go ahead and do a send and you're using the return value from SN print F this Len you're going to end up

sending more data than you expected to you're going to read off the end of the buffer because Len can be considerably larger than size of buff so properly written this code should only be sending at most size of buff so it should be size of buff with the turn operator and if size of buff is going to be less than the Lend value you only want to send size of buff bites um so what is a read o over buffer overread why is it important so this is cwe 126 um um in general it's whenever you're using a buffer and you're not paying attention to how long this buffer is and getting data Beyond the Edge of

the buffer and there's obvious reasons why you should care in case you hadn't noticed this month uh basically the internet got turned upside it on its head because of a buffer overread vulnerability in open SSL that we call heart bleed so it should be pretty clear why buffer over reads are important to understand now looking at mini UPN PD I found U Back some time ago a buffer overread this is a buffer overread in a network service because like that code sample that I had up on the screen there they were using the return value from snrf and weren't considering the possibility that that length could exceed the size of their buffer and so if you would send a crafted UPnP message

you could um cause a send that's going to come out and send you extra data from the Heap and that extra data in the Heap is going to be UPnP messages so you could actually use this from outside of a network to start fingerprinting and seeing what's inside the network what packets has this UPnP Damon been receiving and from there say okay I know there's a NZ server or a media player or whatever else that might be using UPnP on the inside of this network that I'm only on the outside of and I can get version information about it and use that in reconnaissance for future attack now there are other instances where you also have to worry about the

use of SN printf and other bounded string functions which are supposed to be safe so ready DLNA another media related product um from a N Gear developer they had fixed up some stack buffer overflows which had been um publicized and replaced them with a heat buffer overflow the reason that this happened is because they were using signed integers to calculate length Fields never use a signed integer to calculate a length field there's no reason that your length is ever going to be negative so in this particular case the user could send data which is going to make the signed buffer or signed integer roll over and you're going to have unexpected results and you can

actually crop the Heap this way and although it would take a bit of work in this particular context to get code execution at a bare minimum you have a denial of service attack from this so summary you've got vulnerabilities everywhere all of the systems that we deal with are vulnerable in different ways and when you start to train yourself to be able to look for these vulnerabilities you're going to find them and you're going to find lots of them and what I've found is that you can run a lot of animated or automated scanning tools and they're not going to find things as quickly as just one or two QA people going through and manually

putting in different vulnerability locators into every field of your application um so I also want to mention you shouldn't be using any of these tactics or techniques on systems that you don't own or don't have um a professional engagement to be testing you also you want to be careful about what you're disclosing um if you're going to disclose something publicly you have to understand that it can put a lot of people at risk so be patient with the vendors um they're not necessarily going to be as smart as you when it comes to security and they might need a little bit of hold handing handholding in order to figure out how to properly remediate the vulnerability so I spend a lot of my

time going back and forth with vendors and explaining to them why particular fixes are incomplete or what the proper way of doing things is so since I still have some people here we're going to go back to the router because I like to end presentations with more than just a little summary so I had mentioned that with the authentication bypass on the router we looked at earlier it exposes also vulnerabilities which generally would only be exposed to an authenticated user now this is one such vulnerability you can see maybe you can see um in this is the Ping six functionality of the router and if you give it an IP address that has back ticks in it it's not going to do

anything to take those out before it passes it on to the system call and so when we run uh backtick Echo and then the loop back address for IPv6 you end up getting output that looks like it's pinging the loop back address and so it's a good indication that there's command injection I actually verified this by doing some other things like um since we have the analysis of the firmware we know the file system layout I could issue an LS bin and send that output to a file in the web sharing directory and then when we go back and browse to that file we're going to have output from our commands and then of course on the bottom line we have a

semicolon utet D- p1337 any guesses what that's going to do so what we've done here we extracted the firmware we found that there was a hidden ping page on there uh we f the parameters very briefly um the way that I actually tested it the first time was just by doing back tick reboot back tick and found yep box reboots and it's a very common problem like I said even some routers you will find that um you can trigger like on some of the older Linkus routers you can trigger the Ping functionality with an injection without having any authentication just a post request to the script and it will ignore whatever credentials are sent so it it's

a pretty serious problem um something that could be very easily worm put into a worm to propagate so of course this is the what you get when you actually would run that utel net command there we've opened up a shell on Port 1337 and when we connect to it we can see that the router under the covers was using open wrt and we have a root shell and of course we have a root shell because as shown by PS you have the web server running his root because who wouldn't want to run their web server is root so here's some of the tools that I talked about um lots of good ones in there does

anybody have any questions all right thank you guys for your time