Pages

Thursday, January 24, 2013

Responsible Disclosure : XSS in UBM

Last year, I reported an XSS issue in the ubminformation.com which was used by UBM organization. I revealed the details to Trey Ford, and the result is as expected. The issue has been patched :). The domain is no longer valid as it redirects all the traffic to the primary website ubm.com.

This issue was result of an outcome of open research. The good point is that, the vulnerability got noticed and patched.

XSS - 1 
and ...


XSS - 2

Sunday, January 20, 2013

(Pentest Apache #2) - The Beauty of "%3F" and Apache's Inability | Wordpress | Mod Security

Tested Apache Version: Apache 1.3.37(Unix) (with different modules)

I was doing an open research and came across an interesting issue which helps a penetration tester to gather more information about the files present (directory listing) on the web server (specific web folder). I tested only one version of Apache for this. Let's understand this issue. The problem is present in Apache's ability to process the encoded value of "?" which is "%3F". 

Testing: During the validation, I found that wordpress was running on Apache 1.3.37(unix). Due to misconfiguration, it was possible to access the /wp-includes/  folder, which resulted in directory listing as shown below:



So, when I accessed the /wp-admin/ directory, it redirected me to the login page as presented below:



Tthe above presented screenshot shows the correct behavior of the wordpress or the Apache server when /wp-admin/ directory is accessed. Now, when I accessed the http://www.example.com/blog/ , the web server displayed the contents of wordpress blog such as posts and entries. 

Question : Is it possible to get the directory listing on accessing the /blog/ directory?
Answer : Yes, It can be done in some web servers such as Apache.

Question : How can it be possible?
Answer : I exploited the behavior of Apache in processing the encoded "?" character whose value is
"%3F". Amazingly, it worked. I constructed the payload as:   http://www.example.com/blog/%3Fpage_id=34. [One can use any id number or parameter]

Other examples:

When I used the above stated payload, I got the response as follows:



This allowed me to get the listing of the /blog/ directory which really helped me to understand the presence of different files on the remote web server. But, If I used the payload as: http://www.example.com/blog/?page_id=34 without encoding, it did not work. So the encoding of "?" character resulted in failure of processing the request as desired by the Apache web server thereby resulting in directory listing.

Let's have a look at the HTTP response headers:

(Status-Line)      HTTP/1.1 200 OK
Date      Sun, 20 Jan 2013 19:22:59 GMT
Server   VHFFS / Apache/1.3.34 (Unix) mod_lo/1.0 PHP/4.4.4 with Hardening-Patch mod_ssl/2.8.25 OpenSSL/0.9.8b mod_chroot/0.5
Content-Type    text/html; charset=ISO-8859-1
Transfer-Encoding           chunked

(Status-Line)      HTTP/1.1 200 OK
Date      Sun, 20 Jan 2013 19:23:48 GMT
Server   VHFFS / Apache/1.3.34 (Unix) mod_lo/1.0 PHP/4.4.4 with Hardening-Patch mod_ssl/2.8.25 OpenSSL/0.9.8b mod_chroot/0.5
X-Powered-By  PHP/5.1.5 with Hardening-Patch
Content-Type    text/html; charset=ISO-8859-1
Transfer-Encoding           chunked


In the request 2, the response contains X-Powered-By as compared to the first request. So, the PHP preprocessor plays a part in it.

Constraint: In this technique, one can only get the directory listing but will no be able to access those files
until unless there is misconfiguration issue.

Background: I forced Google to provide me with related information and I got the related links as follows:


Solution: Configure appropriate rewrite rules using mod_rewrite to prevent these types of vulnerabilities.
Check [1] for this

Note: If any reader has a specific view on this, please respond back. 

DEFCON 20 Talk : Botnets Die Hard : Owned and Operated Video

Wednesday, October 31, 2012

(Pentest Apache #1) Exposed Apache Axis - SOAP Objects

Recently, I was doing some open research. On compromising the Tomcat Apache Manager component, I came across Apache Axis.

Apache Axis2™ is a Web Services / SOAP / WSDL engine, the successor to the widely used Apache Axis SOAP stack. There are two implementations of the Apache Axis2 Web services engine - Apache Axis2/Java and Apache Axis2/C

Fore more information about Apache Axis, refer here :


It is highly advised that while conducting penetration tests (web + network), one should dig deeper to find exposed Apache Axis objects on the target servers. Primarily, misconfigured Apache web servers (Tomcat) results in exposed SOAP objects used for implementing Apache Axis services engine.

What to look for?

1. Default happyaxis.jsp: This file provides plethora of information about the configured web services on the target server. It leverages configuration as follows:

  • Examining web application configuration (Needed + Optional Configuration)
  • Examining application server
  • Examining system properties



2. Axis Servlet (/servlet/AxisServlet): It leverages information about the deployed web services on the
target server.


3. Echo Headers (/EchoHeaders.jws): This component calls the local endpoints to reveal HTTP headers.

3.1 If method name is not specified (EchoHeaders.jws?method=), it results in exception as follows:

3.2 If method name is specified (EchoHeaders.jws?method=list), it provides results as follows:


3.3 Call WSDL directory (EchoHeaders.jws?wsdl) it provides results as follows:



4. Traverse the exposed WSDL Endpoints listed by the Axis Servlet (/servlet/AxisServlet).


By default, Administer Axis and SOAP Monitor component is disabled. But, the above presented information still helps the attacker to get the configuration of the target server.

So use Google Dorks, analyze manually by provided information in this blog to detect exposed Apache Axis SOAP objects.

Enjoy!

Sunday, July 01, 2012

Art of InfoJacking Talk at Source Seattle - 2011



My talk at Source Seattle 2011.

LayerOne 2012 Talk - Mangling with Botnets


My talk at LayerOne 2012 conference.

Sunday, June 03, 2012

FreeBSD Jails - Routing Issues and Nmap Scanning - NPT

Recently I was using FreeBSD system for Network Penetration Testing (NPT). For better control, jails are implemented in FreeBSD. Jails are nothing but a replacement of chroot environment. For better understanding of Jails in FreeBSD, read  here - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-intro.html.

Target -  9.0-RELEASE FreeBSD 9.0-RELEASE #0:  amd64

When you are performing NPT using FreeBSD, you might encounter the something similar that I am discussing below

1. FreeBSD fails to provide routing information. Commands such as "netstat -r" | "netstat -rn" fails.

john# netstat -r
netstat: kvm not available: /dev/mem: No such file or directory
Routing tables
rt_tables: symbol not in namelist

john# netstat -rn
netstat: kvm not available: /dev/mem: No such file or directory
Routing tables
rt_tables: symbol not in namelist


 2. Traceroute command works perfectly fine and provides desired results.

 john# traceroute google.com
traceroute: Warning: google.com has multiple addresses; using 74.125.224.226
traceroute to google.com (74.125.224.226), 64 hops max, 52 byte packets
 1  206.125.172.17 (206.125.172.17)  2.733 ms  0.958 ms  0.864 ms
 2  ge0-15.as01.lax07.mzima.net (67.199.135.101)  5.611 ms  0.684 ms  1.295 ms
 3  google.com.any2ix.coresite.com (206.223.143.41)  0.728 ms  0.702 ms  0.652 m
 4  72.14.234.47 (72.14.234.47)  0.716 ms
    64.233.174.41 (64.233.174.41)  0.747 ms  0.774 ms
 5  216.239.43.76 (216.239.43.76)  0.976 ms  1.042 ms  0.959 ms
 6  lax04s08-in-f2.1e100.net (74.125.224.226)  0.745 ms  0.652 ms  0.726 ms


3. Dig works fine and DNS names are resolved.

john# dig google.com +nocmd +short
74.125.224.232
74.125.224.224
74.125.224.226
74.125.224.228
74.125.224.238
74.125.224.231
74.125.224.227
74.125.224.229
74.125.224.230
74.125.224.225
74.125.224.233


3. Nmap does not trigger several set of scans on FreeBSD due to jails implementation. Primarily, in
    my case Syn scan fails.

The overall problem is present in the support for raw sockets in FreeBSD when jails are implemented. By default, the support for raw sockets is not provided in jails because of security issues. The configuration parameter "security.jail.allow_raw_sockets" in sysctl.conf is the controlling agent. If the value is changed to "1", the raw sockets support is allowed.

I encountered errors related to "devfs" system. The jails, from where I was executing the scans did not support /dev/mem or /dev/kmem. Typically, I found that jail failed to find kvm. The solution is to provide access to critical sections of the memory to that specific jail. This can be done by making modifications in "/etc/devfs.rules". It means inside the jail, the user can access the all the sections of memory ( bypassing jail restrictions). Being an administrator, no body prefers to do that as it is not a best practice to grant users the root level access to control all sections of memory. This kind of scenarios lead to some management issues though for administrators.

Now the question is, if certain set of Nmap scans wont work what to do. No doubt, running scans in jail environment restricts some of the features of Nmap but we can still use (-sT) TCP connect scan to initiate scanning. Though it is time consuming as it is full three way handshake as compared to (-sS) which is two way but it works without any hassles. You have to make the (-sT) scan minimal which means even this scan does not work with other options in Nmap. You have to run it more simple way as discussed in some examples below.


john# nmap -Pn -vv -n -sT -O -A xxx.xxx.xxx.xxx -oA first_subnet
Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-01 21:53 UTC
NSE: Loaded 93 scripts for scanning.
NSE: Script Pre-scanning.
NSE: Starting runlevel 1 (of 2) scan.
NSE: Starting runlevel 2 (of 2) scan.
nexthost: failed to determine route to xxx.xxx.xxx.xxx QUITTING!

john# nmap -Pn -vv -n -sT -O -A xxx.xxx.xxx.xxx
Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-01 21:53 UTC
NSE: Loaded 93 scripts for scanning.
NSE: Script Pre-scanning.
NSE: Starting runlevel 1 (of 2) scan.
NSE: Starting runlevel 2 (of 2) scan.
nexthost: failed to determine route to xxx.xxx.xxx.xxx QUITTING!

So what works in this case is as follows

john# nmap -Pn -sT -sV google.com -p 80

Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-04 00:23 UTC
Nmap scan report for google.com (74.125.224.229)
Host is up (0.00080s latency).
Other addresses for google.com (not scanned): 74.125.224.228 74.125.224.232 74.125.224.231 74.125.224.233 74.125.224.230 74.125.224.224 74.125.224.238 74.125.224.227
 74.125.224.225 74.125.224.226
rDNS record for 74.125.224.229: lax04s08-in-f5.1e100.net
PORT   STATE SERVICE VERSION
80/tcp open  http    Google httpd 2.0 (GFE)
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

So the point to be considered while doing penetration testing is to take care for these situations. Even though there is restricted environment but we can still achieve what we want.

Hope it helps.


Wednesday, May 30, 2012

Traversing Trace.axd and Miconfiguration Glitch

Recently, I was going through attack research's blog post on trace.axd. Refer here http://carnal0wnage.attackresearch.com/2012/05/from-low-to-pwned-12-traceaxd.html. The information present in trace files is always important and sometimes reap additional benefits from pen tester's perspective. There is some additional info I want to add because of misconfiguration in web server setup. Some simple information but worth while.

During my testing, I have seen that redirection misconfiguration of port 80  to port 443 including path entries can cause serious implications. I am taking a simple example of trace.axd. Triggering a google dork as (inurl:trace filetype:axd site:com),  results in several targets. Here is an interesting case study.

1. On accessing through browsers, the target results in following information


The response headers are:

(Status-Line)    HTTP/1.1 403 Forbidden
Cache-Control    private
Content-Type    text/html; charset=utf-8
Server    Microsoft-IIS/7.5
X-AspNet-Version    2.0.50727
X-Powered-By    ASP.NET
Date    Wed, 30 May 2012 18:41:24 GMT
Content-Length    2062


 The metasploit  produces the similar result.

2. This is not an end. Due to inappropriate configuration, the server can be accessed over HTTPS. Really, let's see.


The response headers for this request are

(Status-Line)    HTTP/1.1 200 OK
Cache-Control    private
Content-Type    text/html; charset=utf-8
Content-Encoding    gzip
Vary    Accept-Encoding
Server    Microsoft-IIS/7.5
X-AspNet-Version    2.0.50727
X-Powered-By    ASP.NET
Date    Wed, 30 May 2012 18:40:59 GMT
Content-Length    1322


In reality, the misconfiguration results in different results. By default, the content should not be allowed over both ports or similar error message should be displayed.

Use metasploit auxiliary module to extract all information or surf directly through browser.

The overall aim is to check all the entry points while doing penetration testing. 

Enjoy !

Thursday, May 24, 2012

Responsible Disclosure - XSS in ZScaler Gateway Application

Updated: I mentioned this issue to the Securityweek's author Steve Regan after reading his story here: http://www.securityweek.com/zscaler-accused-throwing-stones-glass-house-over-xss-vulnerability. He
quoted this blog past as an addition to the story.

Some of the XSS bugs were responsibly disclosed to the security team at ZScaler. Thanks to Michael Sutton for responding quickly. The vulnerability is patched now.

Proof of Concept is here:




We stick to responsible disclosure to build the community more secure.

Enjoy !

Sunday, May 20, 2012

McAfee or is it Mcaf.ee - Interesting !

Update: Seems like a legitimate service by McAfee. The geek-mode functionality  raised a suspicion. Thanks to anonymous for pointing this out.

I was looking for some interesting malware samples and came across with hilarious but rogue domain using McAfee name. It is actually a URL shortening service hosted on this domain. If you want to try, do it here by clicking this http://mcaf.ee.


Typically, the shortening and expansion process work as presented below

mcaf.ee~>  s http://www.google.com
> The shortened url is >> http://mcaf.ee/f1cd29 << [Copy]
mcaf.ee~> e http://mcaf.ee/f1cd29 > The expanded url is >> http://www.google.com << [Copy]
mcaf.ee~>

   
Following URL's are accessed by this service for primary actions.

[1] hxxp://mcaf.ee/api/shorten?callback=jsonp1337557363223&input_url=http%3A%2F%2Fwww.google.com

[2] hxxpp://mcaf.ee/assets/ZeroClipboard10.swf

The analysis of ZeroClipboard10.swf is present here : http://jsunpack.jeek.org/?report=5c4bf5f21ec4870d16e89e9d8f32bee124a8344b

Other interesting links are as follows:

hxxp://mcaf.ee/config?geekmode=1
hxxp://mcaf.ee/js/geek.js

The domain still up as for now. You might want to take a look :)

Monday, April 16, 2012

Fun Hacking - Story of WiFi Airbox Cellular Routers


I am always curious to know more about the new network devices such WiFi routers. So I started hitting at it. Basically, mobile WiFi provides default access to internet connection. I pushed my device to be in the network.

1. A quick IP lookup provided me with the IP address of the mobile WiFi router present in the

2. The very basic thing is to surf the web admin console which by default provides the basic HTTP authentication prompt. At this point, I got to have the details of the mobile WiFi router. So I quickly issued [ echo "GET / HTTP/1.0" | nc 192.168.100.1] to extract the HTTP response from the running web server that was used for administration. Unfortunately, it was not giving any reply. That's fine.

3. A quick scan leveraged that port 81 was opened. So I fired the web browser to see if something was there for me on port 81.The port displayed the following web page

Yeah, that's more than the information I wanted. The mobile WiFi router was AIRBOX cellular designed by waav.com. Additionally, port 53 was also opened for DNS querying but that was not the target point.

4. So, the next step was to download the manual of this WiFi router. I did and carefully read it. As common, the airbox router use to have  default credentials. Look at the excerpt from the AIRBOX manual :http://waav.com/AirBox_Manual_V2.5.pdf.

5. Based on this information, I build the password list and also used the standard password lists to brute force the account. Within a few seconds. I got the admin interface password. If you are lucky, you will find default credentials present on these routers. Security is always creepy for these devices. I always look for the DHCP leases to find out the number of devices that are connected to the router. As said, I did the same


 So the lesson is, we need to delve more into security.