Security Thoughts
Monday, September 12, 2011, 16:48
Expression Language Injection
Think about implementing a web application that relies several secrets like anti CRSRF tokens, random seeds used for password generation and so on...
If the implementation is based on Spring MVC framework and security is important for you, then you should consider reading the paper Expression Language Injection which is the result of a joint research conducted by Stefano Di Paola of Minded Security and Arshan Dabirsiaghi of Aspect Security.
We tried to identify the security impact of a bug in Spring MVC which could lead to double evaluation of Expression Language if an untrusted input is used as the argument of particular attributes.
...
Continue readinng on Minded Security blog...
Wednesday, June 15, 2011, 09:54
[Security Song] Help Yourself to My Flaws
These days are quite eventful in the info security world. Several attacks which stole data from Sony, from Citybank and from a bitcoin user.
I was pretty shocked.
I use to listen to the radio while working, and I felt inspired listening to
Help Yourself to my Lips" performed by Tom Jones.
I thought: "It just seems like a big web application owner is offering its data to every attacker in the world...".
So I decided to rewrite a bit the song and - gh - perform by myself :P..
Enjoy
Update:
If you enjoyed this, have a look at the new
song
Saturday, April 30, 2011, 07:50
God Save The (Omniture) Quine
Some weeks ago, while testing a website hosted by a client of ours
with DOMinator, I found that an Omniture Catalyst plugin called
crossVisitParticipation used an eval on a cookie value.
It was a typical 'eval(cookieValue)' which is bad from a security
perspective, but there is something more interesting which made me think
to write a post about it, since the attack vector was kind of advanced
and the model here is different from "traditional" meshups.
In fact in the Omniture case, companies have to save an auto generated
JS and host it on their own websites.
This means updates are directly tied to a local site administration
policy, and no real time update is possible.
Continue reading on Minded Security Blog..
Monday, March 28, 2011, 16:08
Abusing Referrer on Explorer for Referrer based DOM Xss
I don't really know if this is actually known, but I thought it was worth writing.
In a few words:
While other browsers do not allow particular charaters in sub domains, IE does. Hence it's possible to abuse that behavior to exploit referrer based DOM Xss.
..continue reading on Minded Security
Thursday, October 21, 2010, 10:40
Java DSN Rebinding + Java Same IP Policy = The Internet Mayhem
This is a short blog post about what could have happened if a malicious user had exploited the issues I found.
If someone has read the post about Java DNS Rebinding and Java applet same IP Host Access probably has come
to the same conclusion of what I am going to describe in the next few lines which can be summarized like this:
Java applet implementation could really break the web.
Consider the following points:
* Java DNS Rebinding: an attacker can point a controlled host to any IP of the web.
* Java applet same IP Host access: an attacker can read the response of any host which points to the same IP
the applet originates.
..Continue reading here
Thursday, October 21, 2010, 10:38
Java Applet Same IP Host Access
Summary
Due to a design issue on the way Java considers Same Origin Policy, it is possible for an attacker controlling a host with the same IP of the victim host, to forge requests to victim host on behalf of a user and read the content of the response.
..Continue reading here
Wednesday, October 20, 2010, 15:03
DNS Rebinding on Java Applets
Summary
In 2007 it was discovered that Java Applets, in conjunction with LiveConnect plugin on Firefox, were vulnerable to DNS Rebinding and take advantage of Java features like TCP and UDP socket connections on unauthorized sites.
But the only browser which resulted vulnerable was Firefox.
During an assessment of Java VM source code (v. 6 update 21) it was found that the attack was still feasible, probably due to a regression issue and, more important, I found a way to extend the attack to every browser.
A fix should have been implemented in the new Java 6 update 22.
...Continue Reading here
Thursday, September 23, 2010, 11:34
A Twitter DomXss, a wrong fix and something more
It seems that twitter new site introduced some issue resulting in a worm exploiting a stored Xss.
They also added some new JavaScript in their pages which I casually saw while searching in the html for the worm payload.
The code was the following :
//<![CDATA[
(function(g){var a=location.href.split("#!")[1];if(a){g.location=g.HBR=a;}})(window);
//]]>
Do you spot the issue?
It search for "#!" in the Url and assign the content after that to the window.location object. And it is present in (almost?) every page on twitter.com main site.
...Continue the reading on Minded Security blog
Here
Thursday, September 23, 2010, 08:37
Chrome Cross-origin property pollution
Last week, while working on the new project about DomXss, I found that Chrome v. 6.0.472.59
had an issue similar to the opener object on IE7.
Specifically, this can be done in spite of the SOP by creating, from an attacker's page, an IFRAME
with the name of the object the other window is trying to access and the overwriting it using JavaScript.
It works on every window reference. An attacker can trigger a Browser Based DOM Xss which will result
in stealing sensitive data, overwrite SOP protected window objects or execute JavaScript in the context
of a legit page.
...Continue reading on Minded Security blog here
Wednesday, April 21, 2010, 16:16
Facebook application hole. A neverending story?
It was April 11th @ 9:00 AM,some days before my Campusparty talk, and I decided to have a quick look at Facebook apps howto implementations.
After some hours of trial and error I understood that an application has almost full access to user data by using REST-Ful APIs.
It seems that an application just needs a key called session_key representing the user.
How to get that? Redirecting the user to the facebook page (FacebookWiki):
http://www.facebook.com/tos.php?api_key=[AppKey]&moreParameters
Which, if user has already subscribed to the application, then it redirects to :
http://apps.facebook.com/appPage/?session={"session_key":"2.XXXXXXXXZzHYZaBMEA__.3600.XXXX-XXXXX","uid":XXXXXX,"expires":1271016000,"secret":"XXXXXX","base_domain":"domain.com","sig":"XXXXX"}
The url where the user is redirected can be set in the '
next' parameter (implied in moreParameters).
Now I had to better understand what I can do and went to my favourite FaceBook hacker-superhero The Harmony Guy.
Found
this:
It seems he already found something...and very big! :( Even if I don't know a thing about FBK, I was sooo near!
The good^N^N^N^NBad thing is that it took me a few hours to study the environment and think about that.
That's the explaination (from harmony guy link):
"...
But the first main component of the attack involved a slight modification to
the login page URI. By adding a 'next' parameter, once can specify an
alternate landing page for authorized users. Not all applications take
advantage of this parameter, but many do. The parameter would not work
for an arbitrary site, but Facebook previously did allow any URI that began
with apps.facebook.com. Thus one could craft a login page URI that
checked whether the user had authorized one application and then
forward the user to a second application. The next part of the attack came
from adding 'return_session=1' to the login page URI. This parameter
causes Facebook to append particular session variables for the authorized
application onto the URI of the landing page - in our case, the second
application given by the 'next' parameter. That application merely has to
check its address for the session data, which provides enough information
to execute API requests using the credentials of the already authorized
application.
..."
Now there's something I don't understand, and that's because I'm not a Facebook hacker and because the description is not technical.
They say it's fixed but if I try this request:
http://www.facebook.com/tos.php?api_key=80c6ec6628efd9a465dd223190a65bbc&connect_display=popup&v=1.0&next=../wisectest/&v=1.0&&return_session=true&session_key_only=true&canvas
using
farmville api_key with
next parameter set to my test application home page on apps.facebook.com, I get a redirect to:
http://apps.facebook.com/wisectest/?session={"session_key":"2.XXXXXXXXZzHYZaBMEA__.3600.XXXX-XXXXX","uid":XXXXXX,"expires":1271016000,"secret":"XXXXXX","base_domain":"farmville.com","sig":"XXXXX"}
After that the victim seems to be also added my fake test app transparently...
Maybe they fixed on login.php but missed some page?...:o
As usual the infamous question I asked myself a lot of times when a vuln is fixed but the technique has not been understood.
How come that after the "theharmonyguy" post no one @facebook got a deep analysis?
Maybe complexity is a bad dwarf when dealing with security, but what about applying Secure-SLDC, I mean, really.
Just for sake of user privacy protection, I'd suggest to use different Browsers or Firefox Plugins.
- Use Chrome for your every day browsing
- Use (at least) multiple profiles on Firefox for your favorite categories
- Firefox -P private
- Firefox -P banking
- Firefox -P pr0n
- Firefox -P whatever
and, of course use NoScript! ;)
Nota Bene:
I also found some site publishing Xss on facebook applications by simply searching on google...and they still work!
Hey Mr. Facebook would you care doing a Google search?
A hint: "facebook applications security bugs" on bigG.
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.
