Search

Friday, May 13, 2016

BURP Suite for Penetration Testing : Introduction

Intro

Environment

Ubuntu 14.04, PHP7.0, Apache

Objective

Manually do penetration test on web app using Burb Suite

Components

NOWASP Mutillidae

NOWASP Mutiliadae is a purposely vulnerable web application containing more than 40 vulnerabilities. It includes all of the OWASP top 10 vulnerabilities. NOWASP will be used as target for penetration test.

Burp Suite

This is an interception proxy tool that interacts between the client (a browser application, e.g., Firefox or Chrome) and the website or server. It will be running on my local machine and it will intercept inbound and outbound traffic between the browser and the target host. BURP Suite available in free and premium edition.

Preparation

Download & Install NOWASP

Download & Install BURP Suite

Set BURP Suite as Network Proxy

To enable BURP to intercept our web request, set your network proxy to http://127.0.0.1:8080.

Intercept with Burb

Forward or Drop

Go to Proxy > Intercept tab. Make sure Intercept is on (on button). Once request get intercepted, you may click Forward or Drop the request by clicking the corresponding button.

Examine Request / Response Parameters

Examine the parameters for both request and response.

Edit Request Parameters

Change GET request to POST request

Reference

  1. http://resources.infosecinstitute.com/manual-web-application-penetration-testing-introduction/

Thursday, May 12, 2016

OWASP Mutillidae 2

OWASP Mutillidae 2

Introduction

The Open Web Application Security Project (OWASP) is a worldwide not-for-profit charitable organization focused on improving the security of software. Operating as a community of like-minded professionals, OWASP issues software tools and knowledge-based documentation on application security. Read more about OWASP on www.owasp.org

OWASP Mutillidae II is a free, open source, deliberately vulnerable web-application providing a target for web-security enthusiest. Mutillidae can be installed on Linux and Windows using LAMP, WAMP, and XAMMP. It is pre-installed on SamuraiWTF, Rapid7 Metasploitable-2, and OWASP BWA. The existing version can be updated on these platforms. With dozens of vulns and hints to help the user; this is an easy-to-use web hacking environment designed for labs, security enthusiast, classrooms, CTF, and vulnerability assessment tool targets. Mutillidae has been used in graduate security courses, corporate web sec training courses, and as an "assess the assessor" target for vulnerability assessment software.

Installation

Environment : Ubuntu 14.04 TLS, Apache, PHP 7.0.5-2+deb.sury.org~trusty+1 (cli) ( NTS ).

  1. Download latest version at sourceforge.
  2. Extract and Move to your web directory
  3. Set permission on mutillidae folder

Problems found

Call to undefined function mb_convert_encoding()
Server returns 500 Internal Server Error, with error log : Call to undefined function mb_convert_encoding().
Install mbstring module & reload Apache
sudo apt-get install php7.0-mbstring
sudo service apache2 reload
The database server at localhost appears to be offline
Mutillidae local web page shows message : The database server at localhost appears to be offline. The solution is to change db configuration in /mutillidae/classes/MySQLHandler.php. Then click link to reset DB. This will create database named nowasp (default).

Reference

Monday, May 9, 2016

Base 64 encoding, what is it used for?

Motivation

Problem

Some system only expect string data. Example: url, mail, ...

Related to legacy system ?

Base64

The idea is to safely transport data by encode the data to safely data, i.e.:string, transfer over the network in form of bits, then redo the process backward of the recipient end.

How to it works

  • Each 3 bytes of data are concatenated.
  • The concatenated data then split to groups of 6 bits data (2^6=64,hence it's called base64)
  • Encode the bits using base64 lookup table. Yielded in a string of alphanumeric, +, and / characters.
  • Add padding characters
  • Send the data over the network. The data will be encoded to bits (using ASCII encoding ?). Since the data only contain safe characters (alphanumeric, +, /) it willsafely received on the destination. The receiving end will repeat the process backward.

Example 1: send text

Let's say we want to transfer data :
Hello
world!
It will be sent as ASCII (or UTF-8) as like this :
72 101 108 108 111 10 119 111 114 108 100 33
The byte 10 is corrupted in some systems so we can base 64 encode these bytes as a Base64 string:
SGVsbG8sCndvcmxkIQ==
Which when encoded using ASCII looks like this:
83 71 86 115 98 71 56 115 67 110 100 118 99 109 120 107 73 61 61
All the bytes here are known safe bytes, so there is very little chance that any system will corrupt this message. I can send this instead of my original message and let the receiver reverse the process to recover the original message.

Drawback

It will increase the size of data to 4 [n/3]

Reffs

  • en.wikipedia.org/wiki/Base64
  • stackoverflow.com/questions/3538021/why-do-we-use-base64

Thursday, April 28, 2016

Chrome's settings, configuration, and all

Chome (Web Browser) internal setting, configuration, and everything else


Clear / flush DNS cache

Navigate to chrome://net-internals/#dns and press the "Clear host cache" button.

WiFi Authentication Attack

Gaining WiFi access with password dictionary attach

Post status : on going


Deauth with airreplay-ng

airmon-ng : Unable to start interface with specific channel

solution: stop the wireless card, then airmon-ng start

root@local:/# airmon-ng stop wlan0
. . .
root@local: airmon-ng start wlan0

Wednesday, April 27, 2016

DNS Spoofing and Man-in-the-Middle Attack on WiFi

Steps of DNS Spoofing and MITM Attack on WiFi. Problems and solutions found are included


ARP

view or alter the contents of the kernel's ARP tables, for example when you suspect a duplicate Internet address is the cause for some intermittent network problem.
# arp -a IP address HW type HW address 172.16.1.3 10Mbps Ethernet 00:00:C0:5A:42:C1 172.16.1.2 10Mbps Ethernet 00:00:C0:90:B3:42 172.16.2.4 10Mbps Ethernet 00:00:C0:04:69:AA

DNS Spoofing

ARP Spoof

Install dsniff to run arpspoof

root@local:/# apt-get install dsniff

arpspoof: couldn't arp for host 192.168.1.121

Error found when arpspoof

root@local:/# arpspoof -i wlan0 -t 192.168.1.121 192.168.1.1
arpspoof: couldn't arp for host 192.168.1.121

Solution add -i <wireless interface> parameter

root@local:/# arpspoof -t 192.168.1.121 192.168.1.1
arpspoof: couldn't arp for host 192.168.1.121

dnsspoof: eth0: no IPv4 address assigned

Error found below

root@local:/# dnsspoof -f /home/hosts-spoff.txt host 192.168.1.121 and udp port 53
dnsspoof: eth0: no IPv4 address assigned
dnsspoof: couldn't initialize sniffing

Solution: add -i <wireless interface> parameter

root@local:/# dnsspoof -i wlan0 -f /home/hosts-spoff.txt host 192.168.1.121 and udp port 53

Scanning connected devices

Scan connected devices in the network to obtain IP and MAC address

root@local:/# nmap -sP 192.168.1.0/24

Tuesday, April 19, 2016

Learning Nginx (2) : Add & enable new virtual hosts

Objective
Add and enable new virtual hosts
Environment
Ubuntu 14.04 TLS

Default

Default configuration file
cat /etc/nginx/sites-available/default

The server block configuration are : listen 80, server_name localhost. The location handler mechanism : try to handle request as file, then as directory, then fall back displaying 404 file (try_files $uri $uri/ =404)

Reference :

Monday, April 18, 2016

Learning Nginx (1) : Understanding Nginx Server and Location Block Selection Algorithms

Objective : Understanding Nginx Server and Location Block Selection Algorithms with Examples.
Environment : Ubuntu 14.04 LTS.

Installation

Open terminal, type :
$ sudo apt-get update
$ sudo apt-get install nginx

Nginx Configuration Blocks

Nginx logically divides the configurations meant to serve different content into blocks, which live in a hierarchical structure. The main blocks that we will be discussing are the server block and the location block

A server block is a subset of Nginx's configuration that defines a virtual server used to handle requests of a defined type. Often based on the requested domain name, port, and IP address.

A location block lives within a server block and is used to define how Nginx should handle requests for different resources and URIs for the parent server. Extremely flexible model.

Server Block

Server Block Selection Algorithm

Nginx allows to define multiple server blocks that function as separate virtual web server instances, through a defined system of checks that are used to find the best possible match.

To decide which server block will handle the request Nginx will parse listen Directive first then server_name Directive (only if needed).

Parsing the "listen" Directive to Find Possible Matches

Nginx default value is 0.0.0.0:80 (or 0.0.0.0:8080)

The listen directive typically defines which IP address & port that the server block will respond to. Listen directive can be set to :

  1. An IP address/port combo, e.g.: 192.168.0.11:8080
  2. A lone IP address, e.g.:192.168.0.11
  3. A lone port which will listen to every interface on that port, e.g.:*:8080
  4. The path to a Unix socket(generally only have implications when passing requests between different servers).

To determine which server block to send a request to, Nginx will first try to decide based on the specificity of the listen directive using the following rules:

  1. Nginx translates all "incomplete" listen directives by substituting missing values with their default values so that each block can be evaluated by its IP address and port, e.q. : A block with no listen directive uses the value 0.0.0.0:80.
  2. Nginx then attempts to collect a list of the server blocks that match the request most specifically based on the IP address and port. Block that is functionally using 0.0.0.0 as its IP address (to match any interface), will not be selected if there are matching blocks that list a specific IP address.
  3. If there is only one most specific match, that server block will be used to serve the request. If there are multiple server blocks with the samex level of specificity matching -> begin to evaluate the server_name directive of each server block.
Nginx will only evaluate the server_name directive, if server blocks has same level of specificity of listen directive.

Parsing the "server_name" Directive to Choose a Match

To evaluate requests that have equally specific listen directives, Nginx checks the request's "Host" header. This value holds the domain or IP address that the client was actually trying to reach.

Nginx will find best match of server_name directive within each selected server blocks with following rules in order :

  1. If multiple exact matches of server_name(s) are found, the first one is used.
  2. If no match found, Nginx find a server block with a server_name that matches using a leading wildcard (indicated by a * at the beginning of the name in the config).
  3. If no match is found, Nginx uses a trailing wildcard.
  4. If no match is found, uses regular expressions (indicated by a ~ before the name)
  5. If none are able to satisfy the request, the request will be passed to the default server for the matching IP address and port.

Example :
server {
    listen 80;
    server_name example.com;
    . . .
}

Location Block

Location Block Syntax

Location blocks live within server blocks (or other location blocks), used to decide how to process the request URI (the part of the request that comes after the domain name or IP address/port).

The location_match in the example below defines what Nginx should check the request URI against :

location optional_modifier location_match {
	...
}

Location Block Selection Algorithm

  • (none) : Prefix matching.If no modifiers are present, the location is interpreted as a prefix match. This means that the location given will be matched against the beginning of the request URI to determine a match. Example: location block below may be selected to respond for request URIs : /site, /site/page1/index.html, or /site/index.html
    location /site {
        . . .
    }
  • = : Exact matching. If an equal sign is used, this block will be considered a match if the request URI exactly matches the location given. Example : block below will always be used to respond to : /page1. Will not be used to respond : /page1/index.html request URI. Keep in mind that if this block is selected and the request is fulfilled using an index page, an internal redirect will take place to another location that will be the actual handler of the request.
    location = /page1 {
        . . .
    }
  • ~ : Case-sensitive regex matching, if a tilde modifier is present. Block below could be used to handle requests for /tortoise.jpg, but not for /FLOWER.PNG.
    location ~ \.(jpe?g|png|gif|ico)$ {
        . . .
    }
  • ~* : Case-insensitive regex matching, if a tilde and asterisk modifier is used. Both /tortoise.jpg and /FLOWER.PNG could be handled by this block :
    location ~* \.(jpe?g|png|gif|ico)$ {
        . . .
    }
  • ^~: If a carat and tilde modifier is present, and if this block is selected as the best non-regular expression match, regular expression matching will not take place.

Source :