This is a just a post to test an app
Internal Beef
Burp
Find Me Online
Websites
Twitter feed
Error fetching feeds. Please verify the twitter settings in the widget.
This is a just a post to test an app
Internal Beef
Burp
Comments Off on test post for links
Posted in Random
According to WordPress, version 3.6 is affected by a URL Redirect Restriction Bypass issue that allows an attacker to craft a URL in such a way that, should it be clicked, would take the victim to a site of the attacker’s choice via the Location: tag in a 302 Redirect. Current descriptions of the WordPress issue may be found at WordPress (1, 2), Mitre and OSVDB.
I can confirm that this issue exists in versions 3.1 and 3.6. Due to the range of versions, I assume that it exists in all releases in between but I have not confirmed it. If running an outdated version of WordPress please upgrade to the latest version, which is 3.6.1 at the time of this writing. The current 3.6.1 release fixes four additional issues (1, 2, 3, 4) as well.
There are two attack vectors: the first is a full URL redirect; the second is a partial redirect, as the victim is automatically taken to a WordPress error page with the attacker’s link embedded in a prominently displayed tag.
In order for either exploit to work (assuming the victim clicks on the link) two conditions must be true: first, the victim must be logged into the site (wp-admin); and second, they must have permission to the editing page (edit-tags.php or edit-comments.php). If either of these two conditions are false the vulnerable code will not be reached.
Exploit 1: edit-tags.php Full URL Direct
1 |
[vulnerable site]/wp-admin/edit-tags.php?action=delete&_wp_http_referer=http://securitymaverick.com?edit-tags.php |
The above exploit URL will do a full redirect when the link is clicked on by the victim. It is important to note that in order for the exploit to work the string ‘edit-tags.php’ must be present in the _wp_http_referer parameter. For example:
1 |
_wp_http_referer=http://securitymaverick.com?edit-tags.php |
In this case I chose to put it after a ‘?’ and by doing so I create a dummy parameter so that any valid URL before the ‘?’ executes on the attacker’s server. Under normal circumstances servers such as Apache and IIS will not view web application parameters (the stuff after the ‘?’) as pointing to valid server files to execute. On the application side, WordPress should discard the extra parameter.
Alternatively an attacker may create a URL such as:
1 |
_wp_http_referer=http://securitymaverick.com/edit-tags.php |
This URL has a ‘/’ instead of a ‘?’. This means that the attacker would need to create a valid page named ‘edit-tags.php’ on the attacker’s server in order to have their code run.
The normal WordPress login code prevents access to any page under wp-admin if the user has not authenticated. After authentication, the code in edit-tags.php below prevents users without permission from accessing the page:
1 2 |
if ( ! current_user_can( $tax->cap->manage_terms ) ) wp_die( __( 'Cheatin’ uh?' ) ); |
Exploit 2: edit-comments.php Embedded Link Partial Redirect
1 |
[vulnerable site]/wp-admin/edit-comments.php?action=bulk-comments&_wp_http_referer=http://securitymaverick.com&_wpnonce=1 |
The above exploit URL will embed the attackers link in the error page of WordPress with the text “Please try again” as seen in the image below.
Similar to Exploit 1, the normal WordPress login code prevents access to any page under wp-admin if the user has not authenticated. After authentication, the code in edit-comments.php below prevents users without permission from accessing the page:
1 2 |
if ( !current_user_can('edit_posts') ) wp_die(__('Cheatin’ uh?')); |
Posted in Vulnerabilities
Tagged articles, bugs, ethical hacking, hacking, software analysis, wordpress
“If you don’t hack your systems, someone else will.” The latest data breach statistics (IBM / Verizon / OSFDB) prove the conventional wisdom is still valid. The AT&T “hacking” case of Andrew “Weev” Auernheimer made me revisit my 2007 views on hacking and responsible disclosure, especially in light of the changes in the field since my article was published.
Weev’s case forces one to try to reconcile contradictory views: on one hand, the greater good was served because AT&T fixed a hole that easily exposed much sensitive personal information of their iPad users. On the other hand, after inspection of his code on Git, there is no reason to think it’s not a case of parameter tampering and clearly illegal.
In the broader picture, society needs people who can and are willing to expose information security issues that clearly hurt individuals (or groups of people) either physically or in regards to their privacy. We need a way to give people who have the technical prowess the ability to legally search and report what they find thereby improving and strengthening society.
With the disclosure that Nation-States continuously hack computer infrastructures and the development of industry bug bounty programs offered by Facebook, Microsoft and Google it seems to me it’s time — and society is ready — to legalize hacking. Legalization does not mean we should give just anyone free reign to research another’s online infrastructure property. While I’m not looking to lay out an entire program in this short op-ed, I image such a program would be similar to Facebook’s bug bounty program: the researcher would most likely be required to register (or create a test account) and be looking for specific types of vulnerabilities in order to legitimately engage in the activity. Companies and government entities would be required to have procedures for receiving and fixing reported vulnerabilities disclosed to them through the “hacking” channel in a timely fashion.
“If you don’t hack your systems, someone else will.” That “someone else” already has, now we must. Legalize hacking now!
Posted in Thoughts
Tagged 0-day, bloginfosec.com, china, data, ethical hacking, hacking, privacy
On a recent web app pen test I ran into the following issue: the application would escape (that is, add backslashes) before single and double quotes but not filter other characters. Upon review of the source it was clear the developer knew that not escaping these quotes would lead to issues (such as SQL injection) but they did not appear the grasp the larger picture.
For those who wish to avoid the technical discussion below, here are the talking points:
What I hope to show is how an assumption about syntax could prove untrue since the following two statements are valid:
Below is a tutorial on basic malformed HTML in three parts. The first part shows how bad filtering can lead one to create valid (or semi-valid) HTML the developer did not intend. The examples will show that the browser will interpret partially malformed HTML as legitimate despite syntax errors. The second part shows that once the attacker creates “valid” HTML injecting attack code is made much easier by injecting additional malformed HTML. The third part is an exploit created from parts one and two.
The code below is a case of a developer dynamically building a string to pin/post to pinterest. The code has been rewritten to hide the source of the material but it is a true and formally live case of the logical errors described above.
My motivation for this basic tutorial is my response from another professional. While I was investigating this issue on-site another infosec professional said to me that if the quotes are escaped then the app can’t be exploited. It turns out this is the same incorrect assumption the developer made. Perhaps this will help explain this issue so that other professionals recognize instances of this issue.
Note: the syntax highlighting is not an accurate representation on how the browser will interpret the HTML. In fact, the syntax highlighting below is more strict.
Part 1 – Bad Filter, Bad HTML
The developer’s assumption was simply that if the attacker could not pass a single or double quote they could not create syntactically meaningful HTML or exploit the application. For example, the following valid HTML
1 |
<a href="http://somesite.com"> |
after being run through the filter would be turned into:
1 |
<a href=\"http://somesite.com\"> |
which, due to the backslashes, is meaningless to the browser.
Unfortunately simple cases of only filtering double quotes is an assumption since we can sometimes: first, end tags meaningfully despite the escape; and second, do not need double quotes in our HTML in order to get some invalid HTML to be “properly” interpreted as valid.
In this case I found the developer was building strings dynamically from values in the URL. The offending URL looked like this:
1 |
http://badurl.com/vulnscript.php?badparm=[filtered input] |
So putting “test” in the badparm as so:
1 |
http://badurl.com/vulnscript.php?badparm=test |
resulted in the following dynamic HTML
1 |
<a href="http://pinterest.com/pin/create/button/?url=http://badsite.com/dir//test&media=http://badsite.com/content/item1/" class="pin-it-button" ><img src="//assets.pinterest.com/images/PinExt.png" title="Pin It" alt="Pin It" style="margin-left:-27px;border:0;"/></a> |
So you’ll note that we have the ability to get our input — the string ‘test’ — into the middle of the dynamically built string. Given that this code is intended to be “pinned”, there are two forms of attack here. Once we can get our code to be injected via a URL if we can get it pinned on pinterest– either through us manually pinning it or through social engineering the end user — it will be stuck there. Quite interestingly, it’s possible for our reflected XSS injection attack to become a stored injection attack (as long as pinterest does not filter the characters in our URL). Then anyone who clicks on the pinterest link will run the code when it comes back to badsite.com. The other way is to simply leave our attack as a reflected attack and inject our code into badsite.com through a URL on which we get an end user to click. In either attack, to be successful, we will need to end (or close) the tag otherwise our code will remain as part of the URL and not as code to be parsed and interpreted in the next block.
Let’s test out the filter. If we add a double quote to the end of badurl.com as such:
1 |
http://badurl.com/vulnscript.php?badparm=test" |
We have the following output (slightly abbreviated from the longer version above):
1 |
<a href="http://pinterest.com/pin/create/button/?url=http://badsite.com/dir//test\"&media=http://badsite.com/content/item1/" |
So far, the string is escaped properly. But what if we put in a > after as such:
1 |
http://badurl.com/vulnscript.php?badparm=test"> |
All of a sudden we get the following code:
1 |
<a href="http://pinterest.com/pin/create/button/?url=http://badsite.com/dir//test\">&media=http://badsite.com/content/item1/" class="pin-it-button" ><img src="//assets.pinterest.com/images/PinExt.png" title="Pin It" alt="Pin It" style="margin-left:-27px;border:0;"/></a> |
To be more explicit the following snippet from above is “valid” html:
1 |
<a href="http://pinterest.com/pin/create/button/?url=http://badsite.com/dir//test\"> |
Yes, despite the mangled \”> it is treated as a valid ending to HTML. The escape backslash added by the developer’s filter is not counted!
In all fairness, the two code snippets above is not valid but no matter. Since we’ve successfully closed the tag according to the browser we can now put our code after to be executed as a new tag.
Part 2 – Bad HTML, Bad Filter equals Good Exploit
In the prior section we learned about how escaping can be bypassed if the HTML end tag is seen as valid. In this case we will see how malformed HTML can be interpreted as valid.
Here is a valid image tag:
1 |
<img src="http://www.google.com/images/srpr/logo3w.png"/> |
But did you know the following is also interpreted as valid by the browser?
1 |
<img src=http://www.google.com/images/srpr/logo3w.png> |
That’s right. An image tag without double quotes! So, here’s the important point. If the image tag does not need double quotes, when we encounter filters that only filter the quotes we will bypass it. Who needs quotes anyway?
In this simple example I loaded Google’s homepage image via an img tag. I leave it to the reader as an exercise to understand how the img tag may be used to inject javascript and other malicious code. In short, if a researcher can inject the img tag into a dynamic URL displayed on a webpage (as shown above) they can do damage. So, pretend the Google image is really an exploit.
Part 3 – The Exploit!
If we go back to our bad url from Part 1:
1 |
http://badurl.com/vulnscript.php?badparm=[filtered input] |
and put a “> and then our malformed image tag without double quotes we get the following URL:
1 |
http://badurl.com/vulnscript.php?badparm="><img src=http://www.google.com/images/srpr/logo3w.png> |
If we execute the URL we get the following code as a result:
1 |
<a href="http://pinterest.com/pin/create/button/?url=http://badsite.com/dir//test\"><img src=http://www.google.com/images/srpr/logo3w.png>&media=http://badsite.com/content/item1/" class="pin-it-button" ><img src="//assets.pinterest.com/images/PinExt.png" title="Pin It" alt="Pin It" style="margin-left:-27px;border:0;"/></a> |
The browser will now run our mangled/malformed injected img code (without the dquotes) since we’ve closed off the HTML and our injected code is seen as the next tag for the browser to interpret.
To be more explicit, the following snippet parsed from the code quoted just above will be treated as valid HTML:
1 |
<a href="http://pinterest.com/pin/create/button/?url=http://badsite.com/dir//test\"><img src=http://www.google.com/images/srpr/logo3w.png> |
Lesson: filter out those extra characters!
WebCalendar versions 1.2.5 and 1.2.6 contain a Persistent XSS in the Category Name field. Version 1.2.5 was tested and then compared with 1.2.6 to determine that the vulnerability is in both versions. Please see screen shots below.
WebCalendar versions 1.2.5 and 1.2.6 allow an attacker to determine a valid user id on the system. After submitting an invalid ID the software, “Invalid Login: no such user.” Please see screen shot below.
My NYMISSA presentation on web app static code analysis and testing techniques received good reviews. The aspect of the presentation that received the most comments from the other web app pen test professions in attendance was on my technique for sandboxing and fuzzing the filter to test it independently. Based on this feedback I thought it might make for a good blog post for other professionals.
In a very high level description here’s how it works. Locate the GET/POST filters and the routines used within them. Copy and paste them to script that will run a variable through the filter and show the output. Open burp and run a manual request of the custom script with the web app filter. Send the request to Intruder in burp and then fuzz the parm. See what comes out the other side.
It’s a good technique to use when one has access to the source because it can help one figure out how to craft one’s injection code. From this technique you will find out what characters “normally” get through the filter by default.
I’ve posted the screen prints on the technique below. Within the page it appears that the steps remain in order. Once you click on the gallery the images seem to randomize. The general steps follow the image numbers from 1-16.
Since my presentation was for a PHP app, the demo script in slide 6 is one that I use in live testing. The simple PHP script takes a parameter from a get request and then passes it through the web app filter. Feel free to copy and use it but please credit me in reports!
As a bonus, here is a small library of characters and strings to use in combination with this testing technique that can be used in addition to the fuzzdb interesting-metacharacters.txt file from the demo below.
(Shameless plug: you can also follow me on twitter.)
Demo technique steps:
Here is a list of my publicly disclosed vulnerabilities from 2000 through 2006. I figure these should be added to my public OSVDB profile. (I actually have two!) It’s 2013. These were found a long time ago. Still, I did the work; why not receive the credit?
It should be emphasized that these are vulnerabilities that were publicly disclosed and not the totality of those that I’ve discovered between 2000-2006. If I can find additional ones I will update this as necessary. This page is more for historical accuracy and record keeping than anything else.
Posted in Vulnerabilities
Tagged bugs, ethical hacking, hacking, old stuff, zero-day
I recently retook and passed the CISSP again. I wrote an essay on it over at bloginfosec.com.
OrangeHRM 2.7.1 — the latest stable release as of this writing — suffers from a persistent XSS in the vacancy name variable. Steps:
1 |
http://[domain]/symfony/web/index.php/recruitment/viewJobVacancy |
Screen prints in the gallery below. The images should be self-explanatory.The direct URL to the list of vacancy page is below.
I contacted OrangeHRM but did not receive a reply.