PG - Attacking Drupal - Greg Foss

turn tell me tengo talento about great breakfast hello my body we're going to go and get started we have Greg false here with us today was going to go over attacking Drupal everyone well he said I'm a Greg Foss my senior security research engineer with a logarithm labs and so today I want to talk to you guys about how to hack Drupal applications so let's jump right in so as group why why do run a go after people so Drupal is open source content management framework written in PHP basically runs on our basic lamp stack really easy to use really easy to install and that's part of why there's such a large adoption of it so government agencies are using it

major companies are using it and it's very easy to use so it's just growing in popularity essentially so why is it a good target well this slide actually took little better this year we've been so this side I actually took a picture out of confidence a couple weeks ago and this is a Drupal presentation they're giving this is a government agency actually talking through the Drupal deployment process and so it's kind of funny up here legacy customer requests a site the provision the site forum then customer builds the content on the site they provision a production site from this content what team sinks the content from pre brother prod new sides live so it's the issue with this with this basic

sdlc diagram here there's no security at all it wasn't even thought and so I also know about this and what they said was that they rely on the Drupal security team and the community for security and so I was like really like that's your security plan he's a great run scans to let school run scans but scans against Drupal applications don't work all that well so if anyone hears ever tried to drown like AppScan or HP web inspect or something like that against a Drupal application you can run into issues we're safe they have a calendar or something like that it will actually end up scanning infinitely because it's thinks there's an infinite number of pages never

finishes and so you end up not getting any really good results from scanning so that's why you have to actually manually pen test these manually review code and do things like that so what I'm trying to do is automate some of this but still you know I have scanning be like more smart scanning so you're doing it intelligently fuzzing certain fields things like that as opposed to just blanket running a tool against something crossing your fingers and hoping it's going to work right so first thing you can do and I use this all the time so Drupal comes with a changelog txt file now Drupal teams who are developing sites they often collaborates they work

and you know they'll be like 520 people working on one side and they always use this this txt file to essentially document what changes they made to the site so you can visit this one file and find out you know versions of modules what modules are installed work version core is that you know all sorts of things like that without ever running a scan you can find out just by visiting one page which isn't going to trigger any alarms essentially on the organization you're targeting so if you're doing scanning I suggest these two tools thirties well the first one is CMS explorer and essentially what this does is it goes out and ask as a site

and it just looks for what modules are installed the cool thing is you can tie this into the OS BB and it checks those modules against the open source vulnerability database to see if I there any vulnerabilities for these modules out there the issue is that it doesn't tell you the version so you could say oh there's tons more abilities for these but they're probably for older versions of modules so that's where blind elephant comes into play so you can use behind elephant to essentially fingerprint the modules and also tell you the versions that they're running and then you can correlate that with open source vulnerability database so really really useful tool so the next

thing I like to do is use a source code so the neat thing about Drupal is just working my mic going out yes you may over here oh hello okay that's better alright so maybe household it yeah there we go it's bad alright so good yes hear me so okay cool so let's jump ahead here so with source code a lot of developers like to use github so anything about github is you can use awesome dynamic queries similar to google dorks to find neat snippets of code that people have posted even if they've removed as since then or updated the repo so one tool i like to I like to use to kind of automatically go through and scan this

is called our github hack so i'm doing here is i'm essentially looking for the drupal half salt strain within any PHP file and i'm just doing with the results in a file called DB text so late here i actually just ran this against github and all these sites are essentially exposing the backend mysql credentials to their databases and we'll talk about setting aside PHP file here a second so you can also scrape an internal github deployment with this same tool you just have to change this one string right here so settings dot PHP file essentially controls how the site interacts with the database and also controls authentication and so right here we can see by looking at this file

we got the database user the database username password the host and also the Drupal hash salt which will come in very handy later on so remediations simple for this you just have to essentially install a gig nor file so that's enough with source code because there's a lot out there on source code analysis especially with working with drupal and security so i talked about is actually breaking live applications and hacking drupal applications that are running so so we're essentially going to look at flaws and applications so bugs would be you know i'm sending this input and it's not being filtered properly resulting in no cross-site scripting or something like that like the characters are being

escaped whereas the thighs you configured the site wrong essentially and so we're going to look at some ways to exploit some of these so the first thing I like doing if you're an internal security guy and say you're auditing Drupal websites but the Drupal developers won't give you an admin account on the site to go and check permissions and those kind of things you can use this nifty little trick here so all you have to do is change directories to the doctor aid of the Drupal site and run the command dress uoy now this relies on the fact that they're using brush which most every group will developer uses rush because automates a lot of their processes so once you run

this it gives you a nice little link that you can visit which resets the admins password so a nifty little way to get in if you already have server to access so next thing I want to look at is authentication and enumerated user accounts so this is actually petitions whitehouse.gov and you can enumerate users very easily from this site and this is pretty much all Drupal sites have the same vulnerability by default so when you in the wrong username it tells you right his user account doesn't exist in the database now we near the right one says it's sent instructions instructions to your email address so pretty useful though this does flag because you're going to be saying email

to the admin of the site if that's the account you're targeting so there are other ways to do this you can also go through and just iterate through accounts by changing the number up here most all Drupal app developers don't change this setting also comments polls things like I all contain the user account name so once you have that we're right here you can actually do a simple for loop to essentially use curl and go through and scrape all this data so now you have every single user account in the site right so once we have this you have essentially half of the equation that you need to break into the site so what's the next logical step dictionary

attack right we're going to take those accounts we're going to try and brute force some of them so pretty easy anyone who use burp suite yeah fake tool especially for brute forcing Drupal 6 by default has no built-in protections against this so you can just run as many attempts as you want and essentially gain access to the accounts now one thing I like to do is using Hydra and using a word list in combination with the user names that you just scraped so then you can go after multiple accounts really good if someone needs a default password or something like that and they never login and change it unfortunately Drupal 7 they've added some default

security so if you if you try and do this against a Drupal 7 site by default or walk you out after five failed attempts so you know not all is lost though another way to get around this is just running three or four attempts against each account and this works all the time especially if you target a manager or something like that because oftentimes developer set up accounts for their bosses and their boss never actually logs in to the site to check it out but those requests an admin account see you something like change me or company 1234 or something like that works all the time so the problem though is if you keep doing this is it will

eventually ban your IP address and there's no way to get around this unless you want to wait 30 days to be unblocked so you know that's where tour and VPNs and stuff like that come in well one way to mitigate this there are lots of ways you know single sign-on 80 integration stuff like that but one way that's very popular to remediate ence this is captcha now there is a major issue with the implementation of captcha in Drupal now default a lot of times I've seen sites set up with the very bottom setting here that says I met challenges in all forms once the user successfully responds to any challenge on the site so you just

have to answer the question right one time and then go back to brute-forcing so pretty bad so you always want to make sure to always add a challenge if you're if you're using CAPTCHAs so the next thing is session handling so Drupal 6 by default has no security of their session tokens really so we can see the secure flights nuts not set and the HTTP only Flags not set so pretty bad you know secure flag keeps your your session from being transmitted when you're making HTTP requests whereas HTTP only protects your session token from JavaScript know then cross-site scripting kind of attacks Drupal 7 though actually does set the HTTP only flag by default so

that's pretty good and it's supposed to set the secure flag whatever the implementation of seeing has not actually set this flag and it's usually because they set them up in clustered environments they'll like 10 sites ring on one server and setting this cure flag for one site would break the other ones and vice versa so oftentimes you'll never see the secure flex set session handling we always want to encrypt all your traffic even internally a lot of developers sale its internal it's okay so I guess cool you're using ad credentials to log into your account and I just stole them it's like that's bad anyone in the company can do these kind of things so you want to encrypt your

traffic playing updates is another key thing the developers don't don't like to do it seems so in Drupal whatever you have missing updates it'll tell you on every single page that you have an update available you get this big red warning banner and they're also RSS feeds email lists all sorts of different ways to give notifications of updates so there's really no excuse for missing out on major security updates the next thing is application marketing so a lot of people bring in you know their apache logs or server logs those kind of those kind of logs and you know they think they're seeing the whole picture well with Drupal it actually uses what's called watchdog and it's a database

where it stores the logs so it actually gives you a whole better picture of what's actually happening on the Drupal site if you're able to tie in to the database and pull those logs and that's one of the things we do at logarithm is we have a module that goes out and it pulls this data for customers they can alert on unique events specific to Drupal and WordPress and you know similar applications and the key is pulling these logs off as long as you get these logs off the server so there's somewhere backed up and safe that you know the attacker can't easily get to then the attacker can't go in and do this clear your log messages with a

button it makes it super easy as a hacker Oh clear all evidence I just broke into your site essentially now authorization is the next piece I kind of want to touch on with the in regards to what permissions users have so users would often allowed to comment on articles and things like that on Drupal applications because they're want to be a community they want to be open they want to share information things like that so what they do oftentimes is set filtered HTML to allow people to comment but they want to have them be able to bold text and stuff like that that yeah I mean you really don't need in a comment field this one in particular is

from a real pen test I was doing and actually allowed I don't know if you can see it but the iframe tag so it's bad right you can do anything you want with an iframe tag and so essentially when I asked them about this they said they wanted people to be able to embed movies it's pretty bad and so this stuff's really common so it ends up with things like this you inject you know funny things in their site like I like doing the world pancake bunny it's pretty fun but cross-site scripting you can do a lot of nasty stuff with cross-site scripting and the sand is persistent too whereas themes can often result in

reflected cross-site scripting and reflect is not as much of a risk because yet a socially engineer someone into clicking link and stuff like that but persistent is everywhere injured patience and I'll show you some more attacks on persistent using persistent cross-site scripting here soon so the next thing is unrestricted file uploads so if you're allowing people to upload PHP files that's just bad in general on any application you know you can also upload PDFs or something like that if you want to attack users so a lot of people they don't want to mess with limiting the file extensions that are allowed so they'll often put the star there under permitted file extension so you can upload anything and if you can

upload it and access it so you upload a PHP file access that PHP file you have a shell essentially right so one of the things the Drupal security team did is they tried to fix it they tried to patch this just back in November of 2013 and what they did is they just put htaccess file that permits the execution of PHP files from VF day / files directory which essentially is the default directory that files are uploaded to when you when you configure file uploads on a Drupal application the issue is that custom applications often allow users to upload files to many different locations so say they aren't uploading to the files directory well now they

upload a PHP file and can execute it and get a shell so they didn't actually fix this issue they tried to but the only way to really fixes do is at the top level you know put it in the in the root of the site instead of just the files directory the best thing I want to talk about development modules and more specifically developers using these modules and leaving them enabled in production and how we can leather the leverage these to attack the application because these should always be removed prior to you know the site being promoted from dev to test production so the module we're picking on is devel so anyone here mess with Drupal and use

develop before it's a nifty module it essentially will show you every single database detail of what you're displaying within the application on the page so so you bring up a user account and it shows you all the database info it has on that user account and I'll show you here in a minute why that is so so bad so right here we're looking at the administrative users page same way where you're essentially intimating users earlier we're just looking at his account and you can see by pulling up the devel menu here and this is a real pen test they actually gave me a button they didn't even notice other users cracks access this when they logged in but essentially

you can see I'm looking at the admin account here and there's the password hash so disclose right there I mean it's it's as simple as you click on this button and then click another button and you have their password hash so I saw this so common when I was pen testing drupal applications that i ended up scripting the extraction of the usernames and the password hashes just because every single site i was testing had this still enabled and had it accessible to basic users which is really bad so once we get those password hashes how do we crack them alright so John the Ripper it actually still works plate it's an awesome tool for this so

it has a built-in permutation for Drupal 7 all we need to supply is the salt and it will actually still work and still crack password hashes even without the salt it's just a lot faster if you have to solve an Drupal 6 is just straight md5 so super easy to easy to crack really really simple so right here is just a screenshot showing dump essentially after running the script that i'm going to show you here a few minutes against the drupal site and so we have the email address and the password hash here and so we take this this list of users and passwords and read it through john the ripper and it goes and cracks all i'm pretty pretty

simple that's the thing that you can do with devel this is why it's my favorite module as you can execute PHP code directly from within the module on the server so once you can do that you can read files on the host you can you know get a show you can do whatever you want then it makes it very easy and it just gives you a nice little PHP code execution window to use and so if you don't see the window you can just go to / develop ehp and then you can execute PHP code and essentially right here this is another real pen test I was on and they have no idea that this was

even a feature of the bell and right here we're getting a reverse show out through an internal site or through an external site back to another server so what do I do now is kind of do a demonstration of actually hacking a live drupal application and so we'll just kind of walk through the whole process so first thing we need to do is register an account so now that will be an account registered we can go through and start enumerated users so we'll get logged in here and so we're just going to our account and we'll just change to user 10 see if it changes so and there are ways to disable this I'll show you

at the end there's a link to my github and I have a longer version of this talk that talks a lot more about remediation type stuff so here I'm just running this little script that essentially is going to go and and extract all or integrate all the users and they're just going to run a brute force attacked again some so we're just plugging in our session variables because it's going to use the session that we're already logged into the application with so it's going to just use our same existing account through plugging in parameters here Latos HDTV site so it's not a ssl enabled and so we're going after 10 accounts so right there we've already

enumerated 10 accounts and now we're just launching hybrid want to brute force attack against own so pretty quick for the demo I mean I just use the same passwords that are in the database ready just you know for speed reasons but in production I've had a lot of success running this especially against older sites the cool thing about Drupal 6 is these are going to be done for a long time because a lot of companies don't the money to upgrade to Drupal 7 and Drupal 8 still being worked on so there's the Drupal 6 is going to be around for a long time now you can do the same attack with Drupal 7 but it's a

little trickier so next how we were talking about persistent cross-site scripting so here I want to show some some nifty little costly scripting attacks you can do with a persistent XSS with in Drupal specifically because a lot of times you know you'll do a pen test and you just get the alert box and show that to developer but that really doesn't sink into them they're just like oh you showed me an alert box does that mean so I like doing is actually attacking users and actually attacking the site and really showing them how damaging this can be so the first attack I'm going to do here this is against a Drupal 6 site because it won't work

against Drupal 7 due to the HDP only flag what we're going to do is essentially steal the session token of the of the administrative user now one of funny things a lot of drupal weapons have told me he oh well you're here essentially i have to review comments before they're posted so you can't really attack users that way and it's like that's perfect because i'm getting the exact person i want to view this to click on it essentially so you don't need you know all the other users because that just causes congestion so it's even better when you have it limited like that so we just had our netcat listener up to catch the session

token essentially when it was sent back to us so here we're just going to change our own token in our you know attacker browser here so once we hit save and close we essentially now have the same permissions as the administrator so it's as simple as that very easy attack now next one's probably probably one of my favorite metasploit modules anyone use the JavaScript keylogger this one works really well so essentially we're just generating our or handler here and now we're logging in with our test users so essentially the attacker that we're going to be attacking the other admin with and so we're just adding a new comment you know same same kind of attack as before so now all we really

have to do is point our script to the new metasploit JavaScript keylogger that's been generated so we'll just copy this over here all right so now our code is embedded in there and you know again when they view it they don't see anything fishy unless they're looking at the source code so now we're back on our victims browser session and you can see we've hooked their browser once they've hit this page and whatever they type anywhere in this page is picked up by the medicine vidya javascript keylogger so it works really well especially in production is neat to see this populate you know as tons of people are hitting the site free fun the next attack kind

of demonstration is just to show how how unique you can get with with cross-site scripting I mean when you have a cross-site scripting vulnerability especially a persistent one you can essentially do anything you want you can even overwrite the page that you have cross-site scripting on so this is a nifty little attack it's just essentially emulating a last pass the last pass application so when they view this page is going to say your LastPass session expired so of course really ideas are going to go log back into lastpass right and I was surprised when when this actually did work when I was testing it so they see their last past session expired you login I'm so now they're on

the attack servers that are now they're on our server essentially entering their credentials and who stole their last pass credentials so right here we just capture and I like doing this where I capture like they hit the last pass they hit the login page and then they log on so you share the levels that people got to especially pentesting you can show how far the attack actually actually worked so next on a show devel and/or and essentially how to harvest this information so right here we're just looking at our user account so the test user and the password hash so now we're just verifying we can enumerate other users and we can access their accounts

with the develop module enable so right here we're just looking at the admin users password hash and you'd be surprised how often this thing is actually included in production sites so this script is essentially the same format as the one we saw before so we're going to plug in the URL that we're we're attacking and then we're going to grab our cookie and just set all the other parameters so we're going to go through 30 accounts this time so we're just going to go for all the accounts in the site then you can kind of determine how many are there just by enumerated through and so as quick as that we have all the user the emails and all the

password hashes so now we can take those and go crack on so this is my favorite part of the bell this is my favorite feature within the whole module so I have what you guys through essentially at this point we have admin access on the account will just say we've got in through one of the other means we want to actually execute PHP code now if you ways to do this this way I'm just going into the blocks and I'm moving an inactive block up to an active block so I'm taking the PHP code execution block and move it up to the footer so now down here and the footer we have the xq PHP

code block and so it gives us a nice little window to insert our exploit code essentially so first thing I like to do is just a test and make sure this thing really works and that I can actually access files on the systems and and execute PHP code so what i'm doing here is i'm just going to read the etsy password file just to see if it see if it's working see if I can read files so you just write PHP in this little window and you don't have to include the opening and closing brackets so so right here you can see the results of our of our script there so now let's check out

that setting stop PHP file either one we were looking at before that has the Drupal hash Saul MySQL credentials all that good stuff so read that file and grab out all the comments so we're just getting the actual usable data so right here we've got the database username password and the and the host along with the Drupal hash salt so essentially we have everything we need to take over the application and essentially crack all the passwords that are the password hashes that we already have obtained so next thing I like doing is generating a reverse shell so I'm just using metasploit payload and I'm encoding it using a base64 so this just generates a big chunk of base 64 encoded text

essentially and so all we have to do is just plug this in and we fire up our handler on the other side and as soon as it's execute so we get a reverse shell

and you can actually just ran netcat here I was just using the multi handler just to show kind of the exploit we're using and so once we find this you can see we have our shell now we're just checking to see you know who we are where we're at in the file system so simple is that pretty pretty fun little blue exploit so with that yeah I'm just a couple clothes and closing thoughts about Drupal and security the thing is you know do your research understand your organizational architecture understand your servers your applications and your log data so you want to make sure you're pulling the right data in so like if you have drupal

applications or other content management systems you want to make sure you're actually pulling in all the data so you get a full picture of your actual attack surface and pen test your apps you don't want to just run scans like scans are good they'll find you low hanging fruit sequel injection cross-site scripting kind of stuff not persistent cross-site scripting too often that's the tricky one for scanners to pick up what you want to you want to do full pen tests you want to actually test your code manually update early and often make sure apply updates and embed security within development from the beginning you want to actually work with developers and developers need to work

with you guys here the more you come together and actually know what each side is doing the more secure your company is going to be in the end and so in addition I have a much longer version of this that goes a lot deeper into remediation and that kind of stuff on my github page right here so that's all I have thank you guys for coming and I'm around all day if you guys have questions so

but we doing on time we might have time Oh nope