Friday, May 29, 2009

HTTP Parameter Pollution


At the OWASP AppSec Europe, researchers demonstrated a very interesting otherwise underestimated issue. Although not a new attack category but quite dangerous if executed flawlessly.
It exploits the fact how does your application behaves when receives multiple parameters with same name in same URL.
For example, .../bank.php?action=view&accID=101&action=withdraw
In URL above two one parameter 'action' has multiple occurrences with same name in same URL.
What will the web application do? It can do one of the following depending on the environment it is using:
  • It may only take the data from the first parameter
  • It may take the data from the last parameter
  • It may take the data from all parameters and concatenate them together
Now we know that for the specific above URL the second action is quite dangerous!
Using this technique even WAF (Web Application Firewall) can be evaded, it won't filter the request.
Suppose a WAF is designed to detect and filter out attacks like SQL injection:
/index.aspx?q=select pass from table where id=101

The attacker now passes two parameters with same name 'q' then the query will be:

/index.aspx?q=select pass&q= from table where id=101

If a negative security filter is applying a regex that looks for say a SELECT followed by a FROM to each individual parameter value then it would miss this attack.

The best approach to this issue is to use automated learning/profiling of the web application to identify if multiple occurrences of parameters is normal or not. Most web application firewalls, for instance, gather basic meta-data characteristics of parameters such as the normal size of the payloads or the expected character sets used (digits only vs. alphanumeric, etc...). The top tier WAFs, however, also track if there are multiple occurrences. If an attacker then adds in duplicate parameter names, the WAF would be able to flag this anomaly and take appropriate action.



Thursday, May 28, 2009

Just an eyewash ?

Rediff gave an eyewash? Too early to comment. The main page search engine is not executing normal scripts now but not able to thwart encoded ones.
I think they are now rectifying the problem step by step.

Apart from this every second search module is suffering like Product search, Shopping, Matcmaker, Astrology, Jobs endless.

Wherever is search module..high chance of vulnerability.

They should visit XSSed.com for more information about the vulnerability on their site.


Wait is longer... they might have just started the process of rectifying the problem. Let's wait for few days more.

Tuesday, May 26, 2009

CSRF attack manipulates Times Poll


Again Time magazine has become a victim to CSRF attack. A person called Moot got the most votes not by the normal public bu by manipulating the poll process by Moot's supporters.
The supporters of Moot analysed the link that actually submit the user's vote to the application:

http://www.timepolls.com/contentpolls/Vote.do?pollName=time100_2009&id=1883924&rating=1
Then they created an auto Voter URL:http://fun.qinip.com/gen.php?id=1883924&rating=1&amount=1
The arguments the specified the ID of the person to be voted,the rating to be given to the person and how many times they are being voted.
With this information, the attackers could abuse the amount argument to vote more than one time:


http://fun.qinip.com/gen.php?id=1883924&rating=1&amount=200
Each time this URL was accessed, it was equivalent to 200 individual normal requests.
Time actually identified the manipulation and came with antiCSRF tokens that were MD5 hash of URL + salt value.

http://www.timepolls.com/hppolls/votejson.do?callback=processPoll&id=335&choice=1&key=a4f7d95082b03e99586729c5de257e7b
Moot's supporters even identified the mechanism hoe the application generating the token and used the same way to launch the their further attacks.


The URL http://fun.qinip.com contains the following code:
<html&gt


<html>
<head>
<title></title>
</head>
<body>
<img src="http://www.timepolls.com/hppolls/votejson.do?callback=processPoll&id=335&choice=1&key=a4f7d95082b03e99586729c5de257e7b" /><img src="http://www.timepolls.com/hppolls/votejson.do?callback=processPoll&id=335&choice=1&key=a4f7d95082b03e99586729c5de257e7b" />
...
</body>
</html>



I don't know what happened to this particular poll of Times but one thing is sure..don't just implement anti_CSRF token...implement *strong* anti-CSRF token.

More information:
http://www.xiom.com/whid/2009/38/time_poll_hacking

Friday, May 22, 2009

IE is really unsafe?

Is IE unsafe? I tend to conclude so, regarding my interactions with Giorgio on an issue of XSS in Paypal. This is because the flaw in IE that it doesn't encode the URL before sending it on the wire.
While interacting with Giorgio I came across something new to me: InputDecoding. As Giorgio says:
@Nilesh:
In the Paypal case, it’s not doing output encoding, it’s skipping input decoding (quite strangely).
The correct workflow should be:
  1. Input decoding (decodeURIComponent)
  2. Input validation
  3. Output with output-specific (HTML or JavaScript) encoding

This Paypal page was missing all the 3, and only by luck the fact browsers different by IE properly encode the URL saves them from XSS.

The InputDecoding as far as I can understand is the process of getting back the URLencoded input in original form so that application can understand it properly and exeute it. After executing the application once again must escpae the output in proper manner (HTML escape or Javascript escape).

Again, regarding IE Giorgio said:

@Nilesh:

>>IE doesn’t encode the URL?

No it doesn’t. Therefore an application which doesn’t encode its output is not protected even if it doesn’t decode the input.
You should always encode the output, and decode the input if it makes sense (almost always).

>>IS there any way to bypass this URL-encoding and execute XSS?

No (except in IE), unless the injection point is not quoted, because quotes in an URL are usually escaped by the browser (except in IE).

So, I became more susceptible towards IE. I know it since long back that IE is comparatively unsafe when I was testing script in file upload in Google Pages. The Firefox simply printed the URL back whereas IE executed the script. Other theories as well goes against the IE.

Even in case of above Paypal case , exploitation of this specific Paypal vulnerability requires the “double quotes” character to pass through with no encoding: therefore, while the vast majority of XSS exploits are cross-browser, this one affects exclusively IE.




Thursday, May 21, 2009

WASC Web Vulnerabilities classification schema

I came across another effort to systematically organize web application vulnerabilities, include six categories published by the Web Application Security Consortium (www.webappsec.org). They are very clearly and neatly organized.The following descriptions of web vulnerabilities are modeled on the WASC schema.

Authentication – stealing user account identities
-> Brute Force attack
-> Insufficient Authentication
-> Weak Password Recovery Validation

Authorization – illegal access to applications
-> Credential / Session Prediction
-> Insufficient Authorization
-> Insufficient Session Expiration
-> Session Fixation attacks

Client-side Attacks – illegal execution of foreign code
-> Content Spoofing
-> Cross-site Scripting

Command Execution – hijacks control of web application
-> Buffer Overflow attacks
-> Format String Attack
-> LDAP Injection attacks
-> OS Commanding
-> SQL Injection
-> SSI Injection
-> XPath Injection

Information Disclosure – shows sensitive data to attackers
-> Directory Indexing
-> Information Leakage
-> Path Traversal
-> Predictable Resource Location

Logical Attacks – interfere with application usage
-> Abuse of Functionality
-> Denial of Service
-> Insufficient Anti-automation
-> Insufficient Process Validation permits an attacker to

New Search Engine from Microsoft- Kumo!

A new Web Search Engine from Microsoft "Kumo"--a Japanese word for 'cloud' or 'spider'. It is being said that to compete with others search engines major like Google and Yahoo, Microsoft has actually developed it. However it's not available publicly on net but earlier this month Kumo was released for internal testing for MS employees.
Several screenshots have also surfaced over the Internet. It looks refreshing!

More info at :
http://blog.seattlepi.com/microsoft/archives/163312.asp

Monday, May 18, 2009

It pays to be patient, Rediff awakes!


A surprising series of events:

*Couple of months back I reported XSS and SQL Injection to Rediff. It was painstaking effort as I had to search for the person concerned for security incidents. I connected to him, he happily requested and accepted my advisory.

* No Update from them..the vulnerability still existent.

*No Update from them..the vulnerability still existent.

*.................

*No Update from them..the vulnerability still existent.

* Meanwhile I left the hope of feedback and saw somewhere on the net that there have been already reported XSS about their site. It proved their laxity and negligence. I ignored the issue.

* This month somebody discovered XSS again on Rediff ( like I had, few months ago).

* He posted it on Owasp Delhi Mailing List. I responded to the post and told them about my reporting.

* Nitin Saxena (Owasp Delhi Chapter Lead), urged me to send him the all the communications by me to Rediff and advisory as well. He was willing to take is matter to Rediff's higher authorities. I sent the required things.

*I was still not very much hopeful of any lead until I got a personal mail from Rediff head screwing up his staff to whom I had reported , cc to me and Nitin:

To: Omkar[omkars@rediff.co.in]

CC:Nilesh Kumar (India); nitins@cybermedia.co.in


Hi Omkar,

This news of a vulnerability (weakness) on Rediff site, has been doing rounds in the security fraternity and I am sure you'd like to have this addressed. Nilesh had reported this to Salil a couple of months back as well but it hasn't been corrected as of this morning as well. (see attached)


--
Regards, Sriram


At least my voice got heard!! :)



Thursday, May 14, 2009

Yes IE also susceptible

I got my queries satisfied from Giorgio about my previous post :

Nilesh says: May 13th, 2009 at 7:38 am
Hi Giorgio,
When I cleared the history of Mozilla FF, visiting on startpanic.com didn’t yield any result. The bug lifts information about visited website from the history. Isn’t it? Is IE also susceptible? My IE 7.0 gets hanged whenever I visit startpnaic.com and click Check. Why?

Giorgio says: May 13th, 2009 at 7:21 pm
@Nilesh:
>>The bug lifts information about visited website from the history. Isn’t it?
Yes. More precisely, attackers can tell if a certain URL is present in your history or not (they’re using a list of 100,000 to be impressive).
>>Is IE also susceptible?
Of course it is. Every modern browser susceptible.
>>My IE 7.0 gets hanged whenever I visit startpnaic.com and click Check. Why?
Because its JavaScript interpreter sucks?

Wednesday, May 13, 2009

Some one watching where you visited!


Yes... Mozilla has been susceptible to browser-history stealing java script code. Today, Giorgio posted some cool information about the exploit. Mozilla is already working on this. This bug has been reported. Actually they have set up a web site to show the proof-of-concept. Visit www.statrpanic.com in FF,Safari or Netscape and it will tell you which websites have you been already !

But I am not sure it will work in IE or not because my IE is not responding to the website.
Clearing history of visited website makes you safe to this attack. I mean this is one way..may be there are other ways to exploit this. But I have found this effective.

Try it yourself in FF and then in IE and see the results.

Saturday, May 2, 2009

Naughty ' or ''=' still works! ;)

Yes nothing new about this...I agree. This is one of the primary tools used by pen testers for detecting SQL injection flaws. So it's quite natural for any developer to have knowledge how to thwart this kind of attack from happening in their application, I mean ,very basic thing a developer can do in their application,the first line of defence against SQL injection attacks it is.
And they do, I have hardly come around this sort of negligence in any application I have audited.

But can you believe that one of the major website of an Airline is susceptible to this(sorry...I can't disclose)?? Even the site is very much live, used by customers, for doing transactions.
I was taken aback by this incident. Just supplied the query and voila! I had broken their authentication and clearly seeing the account of first customer. That's not single case..this happened at two different login sections ,one for customer account and another for Agent account.
Really surprising, this can't be treated as mistake..this is sheer negligence on the part of developers, on the part of Testers or on the part of authorities..I can't decide. You can understand the cases where a site's authentication mechanism is compromised by advanced methodologies, but this case is beyond any body's comprehension.
Even not this only...much of XSS are also there!
And even this is persistent flaw, every time you inject, you are through, with a very friendly advice popping up telling the logger to "USE STRONG PASSWORDS". :D

I think following might be reasons that a website security fails, as per Jeremiah's post:

1. No one at the organization understands or is responsible for maintaining the code.
2. Features are prioritized ahead of security fixes.
3. Affected code is owned by an unresponsive third-party vendor.
4. Website will be decommissioned replaced "soon".
5. Risk of exploitation is accepted.
6. Solution conflicts with business use case.
7. Compliance does not require it.
8.No one at the organization knows about, understands, or respects the issue.