This is just a brief update on some of the things I've been working on the last few months. As some of you know, I've been super busy with a variety of projects both at work and outside of work. But I managed to get a little "play" in too.
Back in May I had decided to do my usual. Find a piece of software to hunt for bugs in, report the bugs to the vendor, and assist in anyway I could in fixing those bugs. I find it rewarding to do this and it benefits the world as a whole. Usually I look in software that's a little off to the way side. But this time I decided to look in the most downloaded Human Resources Management application on sourceforge. The application I looked into was: OrangeHRM.
It clocks in at about 2K downloads per week, which is significantly higher than my normal <= 100 downloads per week software I like to look in because there tends to be less researchers analyzing them it seems.
Even in my initial review of this software I could tell there was some proactive response to security concerns. First it appeared there were known vulnerabilities in the past which no longer existed, indicating they have a response team of developers ready to patch bugs. It was at this point I grew a bit concerned about my ability to find bugs in their system... but I tried anyway.
And I found some.
I gave them a list of the vulnerabilities I had found and it was very well received. A very positive response in fact. A reply came with a thank you, a note that they'll be actively pursuing fixes, and a request for my resume. Flattered, I indicated that I am happily employed and not actually seeking work. I merely enjoy bug hunting in what little time I have. None-the-less they managed to coax a resume out of me.
And then they made a request I was not expecting...
They asked if I had any interest in looking into their enterprise systems as well. Like a "thanks for hacking our software, would you like to do it more?" but not in those exact words.
My exact words were: "Um.... Heck Yeah!"
Okay... not my exact words, but close enough!
So I agreed to jiggle their door knobs and see what, if anything, would open up. I found enough vulnerabilities to provide real feedback (I'm not positive about the status of all these so sorry no in-depth right now, but keep an eye out for future posts!). And of course areas I found to be secure or very well done (which there are plenty) I could provide that as feedback as well.
One of the things I found particularly interesting about OrangeHRM is that it appears there must be code review in place for their core application. I say this because the core application seems to lack any SQL Injection or XSS.
Now when I say this, I don't mean there are *none,* just that the core lacks them. I did find some opportunities for these in the application, but I believe the risk for them is relatively low in general. In fact in their enterprise systems I believe they've managed to mitigate these issues entirely. It seems they've adopted a defense-in-depth approach as well.
First, they're being proactive in bringing in 3rd party auditors to assess their applications and environments (at least me, if not more).
Second they seem to employ some coding standards for things like SQL parameterization.
And third they've added PHP IDS as an additional layer atop their application. This is another Open Source application which may be used in order to identify, report, and block some potentially heinous actions by malicious users.
So really, I've had a lot of fun working with this company. Getting to expand out a bit into the penetration testing world. It's been absolutely a positive experience. They are highly receptive to feedback. If you're willing to work with them, they're quite receptive to concerns and have been markedly very solution oriented.
Hopefully I'll have the opportunity to work with them more in the future. And that's some of the recent stuff I've been working on!
Until next time, Hack Legal, Hack Safe, but most of all Hack fun!
Monday, October 28, 2013
Friday, August 23, 2013
Cross Site Scripting vs. ASP.Net EnableValidation="true"
A friend of mine recently told me about a debate he was participating in with a colleague of his. His colleague stated that the reason ASP.Net applications are so secure, is because when EnableEventValidation flag on a page is set to true it will catch any Cross Site Scripting (XSS) attempt and throw an error.
I'm here to say... his Colleague is absolutely correct!
Wait... that's not right. They are actually mistaken. And unfortunately I've met a number of individuals who carry this same belief erroneously.
This is a perfect example of the "Defender's Dilemma." Where-in a defensive posture must account for 100% of all attacks and vectors, which may be costly to the point of exhaustion, or accepting attacks as inevitable because the attacker need only be right one in a million attacks to perform a breach.
This said, yes, EnableEventValidation may present a thorn in an attacker's side. Particularly when all of the sweet sweet pwnage is so rife with opportunity because of that one field that is so obviously vulnerable. But then when you drop your <script> it's thwarted immediately and you immediately wish it was a PHP host you were attacking instead.
But reality is contrary to the surprisingly common misconception that the this flag prevents XSS attempts in all cases. It just doesn't. And there are good reasons why it doesn't. XSS has a huge key-space for potential vectors, arguably an insurmountable key-space. This is compounded by the fact that new methods can be evolved from previously benign unexpected vectors. A perfect example of this would by UTF-7 encoding attacks. A bug that affects only few browsers nowadays. Like I said the defender has to always be right and the attacker only has to be right once. Another issue is that some XSS is represented in manners which may easily represent real valid data. e.g. they may not contain tags at all.
Consider the following as a simple example.
The ASP.Net Page definition, simple example:
<%@Page ... EnableEventValidation="true" %>
...
<div style="<%= Request.QueryString["style"] %>">Welcome Home Marty</div>
Though this is obvious to any conscientious developer, this sort of code can slide into a code base if it is written by a less experienced coder and approved too hastily by an experienced coder. How the code gets into a code base is largely unimportant, what is important is assume you've got something like this, and maybe it's a good time to do a code review if you're relying entirely on the EnableEventValidation flag to protect you.
When exploiting this, and this is one of my favorite methods personally, try leveraging javascript events. For instance, use the onmouseover event to fire your arbitrary javascript when the affected user mouses over a particular object:
http://host/vulnerablePage.aspx?style="%20onmouseover="alert('xss');"
No tags, but the server will process the request and render the onmouseover event with the javascript payload. An important note when testing this is, you know it's worked because it passes by the EnableEventValidation - no exception thrown. However, if you attempt to exploit this against users of I.E. or Chrome you'll likely see little to no success (error towards no success). This is because these clients recognize that script that is executing was passed to the server by the client. This is not a feature of ASP.Net but instead of the client itself. So if you use Firefox without NoScript installed, it should be responsive to this attack.
Now in a similar situation where a client might get to set their choice of style by inserting into a database, this is a different story. This is the more troublesome persistent XSS attack and the vulnerable code may take the likeness of something such as:
<%@Page ... EnableEventValidation="true" %>
...
<div style="<%= myDataBaseObject.ChosenStyle %>">Welcome Home Marty</div>
In which case even I.E. and Chrome will not have a frame of reference for the XSS. The will not be able to distinguish the XSS from an attack or valid data and will render the page with the onmouseover event ready and willing to fire!
The solution to this is, encode your outputs in a context sensitive manner when dumping information to your clients. By all means EnableEventValidation, but do not rely on it as a replacement for secure programming practices!
And it should be noted, this flag does not provide any protection for other vectors like SQLi, CSRF, LFI, CR/LF, etc. It is really designed for anti-XSS.
So until next time... Hack legal, Hack safe, but most of all... Hack Fun!
I'm here to say... his Colleague is absolutely correct!
Wait... that's not right. They are actually mistaken. And unfortunately I've met a number of individuals who carry this same belief erroneously.
This is a perfect example of the "Defender's Dilemma." Where-in a defensive posture must account for 100% of all attacks and vectors, which may be costly to the point of exhaustion, or accepting attacks as inevitable because the attacker need only be right one in a million attacks to perform a breach.
This said, yes, EnableEventValidation may present a thorn in an attacker's side. Particularly when all of the sweet sweet pwnage is so rife with opportunity because of that one field that is so obviously vulnerable. But then when you drop your <script> it's thwarted immediately and you immediately wish it was a PHP host you were attacking instead.
But reality is contrary to the surprisingly common misconception that the this flag prevents XSS attempts in all cases. It just doesn't. And there are good reasons why it doesn't. XSS has a huge key-space for potential vectors, arguably an insurmountable key-space. This is compounded by the fact that new methods can be evolved from previously benign unexpected vectors. A perfect example of this would by UTF-7 encoding attacks. A bug that affects only few browsers nowadays. Like I said the defender has to always be right and the attacker only has to be right once. Another issue is that some XSS is represented in manners which may easily represent real valid data. e.g. they may not contain tags at all.
Consider the following as a simple example.
The ASP.Net Page definition, simple example:
<%@Page ... EnableEventValidation="true" %>
...
<div style="<%= Request.QueryString["style"] %>">Welcome Home Marty</div>
Though this is obvious to any conscientious developer, this sort of code can slide into a code base if it is written by a less experienced coder and approved too hastily by an experienced coder. How the code gets into a code base is largely unimportant, what is important is assume you've got something like this, and maybe it's a good time to do a code review if you're relying entirely on the EnableEventValidation flag to protect you.
When exploiting this, and this is one of my favorite methods personally, try leveraging javascript events. For instance, use the onmouseover event to fire your arbitrary javascript when the affected user mouses over a particular object:
http://host/vulnerablePage.aspx?style="%20onmouseover="alert('xss');"
No tags, but the server will process the request and render the onmouseover event with the javascript payload. An important note when testing this is, you know it's worked because it passes by the EnableEventValidation - no exception thrown. However, if you attempt to exploit this against users of I.E. or Chrome you'll likely see little to no success (error towards no success). This is because these clients recognize that script that is executing was passed to the server by the client. This is not a feature of ASP.Net but instead of the client itself. So if you use Firefox without NoScript installed, it should be responsive to this attack.
Now in a similar situation where a client might get to set their choice of style by inserting into a database, this is a different story. This is the more troublesome persistent XSS attack and the vulnerable code may take the likeness of something such as:
<%@Page ... EnableEventValidation="true" %>
...
<div style="<%= myDataBaseObject.ChosenStyle %>">Welcome Home Marty</div>
In which case even I.E. and Chrome will not have a frame of reference for the XSS. The will not be able to distinguish the XSS from an attack or valid data and will render the page with the onmouseover event ready and willing to fire!
The solution to this is, encode your outputs in a context sensitive manner when dumping information to your clients. By all means EnableEventValidation, but do not rely on it as a replacement for secure programming practices!
And it should be noted, this flag does not provide any protection for other vectors like SQLi, CSRF, LFI, CR/LF, etc. It is really designed for anti-XSS.
So until next time... Hack legal, Hack safe, but most of all... Hack Fun!
Monday, February 18, 2013
When Windows Hosts Files Stop Working
So, working on what should have been a quick PowerShell script today, I ran into quite the hiccup. Annoying as hell.
My Hosts file on my Windows 7 Machine stopped working!
This was a rage inducing issue for me. But luckily I think I've identified the "problem." And yes, it is technically PEBKAC - but I think Microsoft should carry a little of the blame too.
First let us set the stage with a very basic PowerShell script to setup the hosts file the way we'd like.
Note: This must be run with appropriate permissions to write to the hosts file!
Pretty straight forward, make an array, add two strings to it with formatted IP/domain pairs. Write the array out to the file. When this is all said and done you should have something which looks like the following:
This is what we would expect. A hosts file with two entries that says some.local.domain -> 192.168.0.1 and another entry that says www.somesite.com -> 127.0.0.1.
Looks correct to me - and if you're reading this yours probably looks correct to you too. But as you can see the ping commands are not resolving based on the IPs in the hosts file! This is certainly not the desired effect. As if the hosts file were being "skipped."
What's the deal?
The error that resides in the above script does not reveal itself when opening the hosts file in your text editor. And in fact in some text editors it'll exist all of the time. Why you ask?
Simple; Your text editor probably detects and allows you to edit Unicode files. Optionally your text editor only supports Unicode files.
Yep, the whole annoying as hell bug - is just a simple encoding problem.
Here's how I noticed it - I opened my hosts file in a hex editor (HxD in my case, cause it's free). Viewing the raw hex we see:
This thought occurred to me as a mere suspicion. I did what I've seen a number of sources say to do: open the hosts file, copy it's contents, remove the hosts file and then re-save the contents using just plain-ol'e notepad. This does work, but it's not a solution for automation in the case of scripts (like I need it to be).
Also remember notepad will save it with the extensions .txt and you'll need to rename it.
So this works, in theory, because when notepad saves the contents it saves them in ASCII and stripping the Unicode encoding. Which is seen when viewing the contents of the new hosts file in HxD:
So, how does one fix the PowerShell script to work too? You're in luck, it's an easy fix. Annoyingly easy after so many hours bashing your head against a keyboard over nothing.
Setup your array in the same way, when you're ready just pass your array to Out-File like so:
That's it, I hope this helps someone. So as usual....
Hack Legal, Hack Safe, buy most of all Hack Fun!
Until next time...
My Hosts file on my Windows 7 Machine stopped working!
This was a rage inducing issue for me. But luckily I think I've identified the "problem." And yes, it is technically PEBKAC - but I think Microsoft should carry a little of the blame too.
First let us set the stage with a very basic PowerShell script to setup the hosts file the way we'd like.
$hosts = @()
$hosts = $hosts + [String]::Format("{0} {1}", "192.168.0.1", "some.local.domain")
$hosts = $hosts + [String]::Format("{0} {1}", "127.0.0.1", "www.somesite.com")
$hosts > $env:windir\system32\drivers\etc\hosts
Note: This must be run with appropriate permissions to write to the hosts file!
Pretty straight forward, make an array, add two strings to it with formatted IP/domain pairs. Write the array out to the file. When this is all said and done you should have something which looks like the following:
Looks correct to me - and if you're reading this yours probably looks correct to you too. But as you can see the ping commands are not resolving based on the IPs in the hosts file! This is certainly not the desired effect. As if the hosts file were being "skipped."
What's the deal?
The error that resides in the above script does not reveal itself when opening the hosts file in your text editor. And in fact in some text editors it'll exist all of the time. Why you ask?
Simple; Your text editor probably detects and allows you to edit Unicode files. Optionally your text editor only supports Unicode files.
Yep, the whole annoying as hell bug - is just a simple encoding problem.
Here's how I noticed it - I opened my hosts file in a hex editor (HxD in my case, cause it's free). Viewing the raw hex we see:
Also remember notepad will save it with the extensions .txt and you'll need to rename it.
So this works, in theory, because when notepad saves the contents it saves them in ASCII and stripping the Unicode encoding. Which is seen when viewing the contents of the new hosts file in HxD:
So, how does one fix the PowerShell script to work too? You're in luck, it's an easy fix. Annoyingly easy after so many hours bashing your head against a keyboard over nothing.
Setup your array in the same way, when you're ready just pass your array to Out-File like so:
$hosts | Out-File -Encoding ASCII -FilePath $env:windir\system32\drivers\etc\hostsAnd now, you should have similar - but better - results! Notice how notepad looks exactly the same! But the pings resolve the correct names, etc. Thus confirming my hypothesis.
Hack Legal, Hack Safe, buy most of all Hack Fun!
Until next time...
Subscribe to:
Posts (Atom)