Ethical Hacking

Dr Bishwajeet Pandey, SMIEEE

Associate Professor-Jain University, India

PhD (Gran Sasso Science Institute, L'Aquila, Italy)

Visiting Professor at
Institute of Computer Science and Digital Innovation,
UCSI UNIVERSITY-Malaysia
ABOUT ME

• PhD from Gran Sasso Science Institute, Italy

• PhD Supervisor Prof Paolo Prinetto from Politecnico Di Torino, World Rank 13 in
Electrical Engineering
• MTech from Indian Institute of Information Technology, Gwalior
• Visited 41 Countries Across The Globe
• Written 200+ Research paper with 193 Researcher from 63 Universities
• Scopus Profile: https://www.scopus.com/authid/detail.uri?authorId=57203239026
• Google Scholar: https://scholar.google.com/citations?user=UZ_8yAMAAAAJ&hl=hi
• IBM Certified Solution Designer
• EC-Council Certified Ethical Hacker
• Qualified GATE 4 times
• Email: [email protected]
 Syllabus of Ethical Hacking

• UNIT 1: Introduction to Ethical Hacking(9 Hours)

• UNIT 2: System Hacking (9 Hours)
• UNIT 3: Web Server Hacking (9 Hours)
• UNIT 4: Wireless Attacks (9 Hours)
• UNIT 5: Report Writing and Mitigation (9 Hours)
• 12 Lab Experiments
Syllabus of Ethical Hacking
 OUTLINE OF LECTURE 15
• Buffer overflow attacks.

• Client-side browser exploits

• Exploiting Windows Access Control Model for Local

Elevation Privilege

• Exploiting vulnerabilities in Mobile Application

• Use of Trojans, session hijacking and injection attacks.

 Buffer Overflow
• A buffer overflow, or buffer overrun, occurs when more data is put
into a fixed-length buffer than the buffer can handle.

• This overflow usually results in a system crash, but it also creates the
opportunity for an attacker to run arbitrary code or manipulate the
coding errors to prompt malicious actions.

• Cybercriminals exploit buffer overflow problems to alter the execution

path of the application by overwriting parts of its memory.

• Hacker techniques that exploit a buffer overflow vulnerability vary per

architecture and operating system.
 Buffer Overflow
• In the code below, the correct password grants the user root privileges. If the password is incorrect, the program will
not grant the user privileges.
• printf ("\n Correct Password \n");
• pass = 1;
• }
• if(pass)
• {
• /* Now Give root or admin rights to user*/
• printf ("\n Root privileges given to the user \n");
• }
• return 0;
 Buffer Overflow
• Here is an example of what an attacker could do with this
coding error:
• $ ./bfrovrflw
• Enter the password :
• hhhhhhhhhhhhhhhhhhhh
• Wrong Password
• Root privileges given to the user
• In this case, the attacker supplied an input with a length greater
than the buffer can hold, creating buffer overflow, which
overwrote the memory of integer “pass.” Therefore, despite the
incorrect password, the value of “pass” became non zero, and
the attacker receives root privileges.
 Buffer Overflow
• Is Python vulnerable to buffer overflow?

• Writing outside the bounds of a block of allocated memory

can corrupt data, crash the program, or cause the
execution of malicious code.

• Python, like Java, makes an effort to avoid buffer

overflow by checking the bounds of a buffer (like an
array) and preventing any access beyond those bounds.
 Buffer Overflow
• Is buffer overflow a DoS attack?

• Popular flood attacks include: Buffer overflow attacks –

the most common DoS attack.

• The concept is to send more traffic to a network address

than the programmers have built the system to handle.
 Buffer Overflow
• When did buffer overflow attacks start?
• 1988
• The first buffer overflow attack occurred in November of
1988 with catastrophic effects. Known as “The Morris
Worm,” the rogue program crashed 10% of all computers
with internet connectivity in a single day.
 Buffer Overflow
• Is buffer overflow a DoS attack?

• Popular flood attacks include: Buffer overflow attacks –

the most common DoS attack.

• The concept is to send more traffic to a network address

than the programmers have built the system to handle.
 Client Side Exploitation
• Nowadays Server side is getting strong day by day but
there are still vulnerabilities present on the client-side and
this leads to client-side exploitation.

• If you are performing penetration testing on any

application to test is there any client-side exploitation is
possible or not you must have an understanding of
possible attack scenarios to find and prevent the Client-
Side Exploitation on your application.
 Client Side Exploitation
• Attack Scenarios In Client-Side Exploitation:
• EMails with Malicious Attachments-
• Malware Loaded on USB Sticks-
• E-Mails Leading to Malicious Links
• Browser Exploitation
EMails with Malicious Attachments
• In this particular attack scenario, the attacker will send the
malicious files such as PDF, exe, or mp3 in the hope that the victim
would click on the link and download and execute the attachment.
• Upon execution, the attacker has a Meterpreter session opened on
the victim’s machine.
• This attack can be a bit difficult to accomplish, as the attacker
needs to convince the victim to execute their .exe file.
• Another major hurdle would be the victim’s antivirus, which you
need to bypass.
 Malware Loaded on USB Sticks
• This method can be used by an attacker when he/she have
physical access to the victim’s machine.
• The attacker loads up a malicious PDF file or a malicious
executable payload via a USB stick.
• Once the USB stick is inserted, malicious code will
automatically be executed and the attacker would get a
meterpreter session opened on the victim’s machine.
• Teensy USB is a device that has the capability to emulate a
mouse and keyboard.
E-Mails Leading to Malicious Links
• An attacker can set up a fake log-in page of any particular website, for
example, facebook.com, and ask the victim to log in to the fake log-in
page actually located at facebookfake.com

• If the attacker is on the same network as the victim, he can launch a

DNS spoofing attack, where we can replace the IP of example.com
with that of the attacker’s fake log-in page, and as soon as the victim
visits example.com, he would log in to our fake page instead

• An attacker can also perform DNS spoofing, where instead of the fake
log-in page we can redirect the victim to our malicious webserver that
would use relevant browser exploits to compromise the victim’s
browser.
 Browser Exploitation
• Browser-based exploits are one of the most important forms of client-
side exploits.
• Imagine a scenario where you are pen-testing against an
organization.
• If it’s an internal pentest, you would already own a box on the LAN.
• If it’s an external pentest you need to somehow gain access to a
system.
• You can set up a malicious web server and ask the victim to visit the
server.
• As soon as he clicks your link, he gets compromised.
 Browser Exploitation
• Most of the employees of an organization frequently browse on social
networking websites like Facebook and Linkedin.

• We, as penetration testers, can take advantage of this and send malicious
links to the employees and compromise them.

• On an internal network, the attacker could simply use a DNS poisoning

attack to redirect victims to his malicious webserver.

• To sum up, there is a whole lot of attack surface when it comes to browser
exploitation.
Steps against Client Side Exploitation
• In client-side exploitation, attackers take advantage of the weakest link that is clients.
• To protect yourself from client-side attacks you have to be alert during your everyday
Internet surfing.
• Don’t open any link coming from a malicious or unknown person.
• After opening any email attachment always make sure that the mail is coming from an
authorized source.
• Avoid downloading .exe attachments of a mail.
• Always check the confidentiality of the domain of the website after filling in confidential
information like username, password, card number, bank account number, etc.
Exploiting Windows Access Control Model for Local Elevation Privilege

• Privilege escalation happens when a malicious user exploits a bug, design

flaw, or configuration error in an application or operating system to gain
elevated access to resources that should normally be unavailable to them.

• The attacker can use the newly obtained privileges to steal confidential
data, run administrative commands or deploy malware – and potentially
do serious damage to your operating system, server applications,
organization, and reputation.

• This post examines typical privilege escalation scenarios and shows how
to protect user accounts in your systems and web applications to maintain
a solid cybersecurity posture.
Exploiting Windows Access Control Model for Local Elevation Privilege

• Microsoft Windows determines the ownership of a running process

using access tokens.

• The access token mechanism can be targeted by attackers to

tamper with access tokens, bypass user account control (UAC), and
assume the process rights of another user, but in Windows 10 and
Windows Server 2016 you can set an audit event to detect any such
changes.

• When you enable the Audit Token Right Adjusted event, the system
will generate 4703 events for audit token modifications that may
signal privilege escalation attempts.
Exploiting Windows Access Control Model for Local Elevation Privilege

To enable this audit event, open the Group Policy Management Editor and
under Advanced Audit Policy Configuration > Audit Policies > Detailed
Tracking set the Audit Token Right Adjusted event to Success and Failure.

• Now you will receive a 4703 event every time a token right is modified,
resulting in a flood of legitimate events from system processes.
• Use your event monitoring software to narrow this down by searching
only for 4703 events related to potentially suspicious changes.
• One common target for attackers is SeDebugPrivilege – a system
privilege that grants a user full debugging access to a process. If this
gets set when nobody is doing any debugging, you can be pretty certain
something is up.
Exploiting vulnerabilities in Mobile Application
• Mobile application security encompasses different
aspects:
• the security of the mobile applications themselves (iOS
or Android version),
• the security of the APIs and the security of the servers.

• Back-end security (APIs and servers) is usually more

critical than front-end security (iOS / Android apps), but
this depends on the technical and functional context of the
application itself.
Exploiting vulnerabilities in Mobile Application
• In general, the more data flows through mobile applications,
the higher the possibility of attacks and compromises.

• Attackers take advantage of different types of vulnerabilities:

weak server-side controls, insecure data storage, insecure
data exchange, use of vulnerable third-party components,
etc.

• To strengthen the security of your mobile applications, it

is important to investigate and fix vulnerabilities both on the
server side and on the application layer (at least the APIs,
but in some cases also the mobile apps themselves).
Exploiting Vulnerabilities in Mobile Application
• Examples of vulnerabilities in mobile applications (OWASP Top 10 Mobile):
• Improper platform usage
• Insecure data storage
• Insecure communication
• Insecure authentication
• Insufficient cryptography
• Insecure authorisation
• Client code quality
• Code tampering
• Reverse engineering
• Extraneous functionality
• Trojans Attacks

• A Trojan horse, or Trojan, is a type of malicious code or software that looks legitimate
but can take control of your computer. A Trojan is designed to damage, disrupt, steal,
or in general inflict some other harmful action on your data or network.

• A Trojan acts like a bona fide application or file to trick you. It seeks to deceive you
into loading and executing the malware on your device. Once installed, a Trojan can
perform the action it was designed for.

• A Trojan is sometimes called a Trojan virus or a Trojan horse virus, but that’s a
misnomer. Viruses can execute and replicate themselves. A Trojan cannot. A user
has to execute Trojans.
• Trojans Attacks

• Backdoor Trojan
• This Trojan can create a “backdoor” on your computer. It lets an attacker
access your computer and control it. Your data can be downloaded by a third
party and stolen. Or more malware can be uploaded to your device.
• Distributed Denial of Service (DDoS) attack Trojan
• This Trojan performs DDoS attacks. The idea is to take down a network by
flooding it with traffic. That traffic comes from your infected computer and
others.
• Downloader Trojan
• This Trojan targets your already-infected computer. It downloads and installs
new versions of malicious programs. These can include Trojans and adware.
• Trojans Attacks

• Fake AV Trojan
• This Trojan behaves like antivirus software, but demands
money from you to detect and remove threats, whether they’re
real or fake.
• Game-thief Trojan
• The losers here may be online gamers. This Trojan seeks to
steal their account information.
• Infostealer Trojan
• As it sounds, this Trojan is after data on your infected computer.
Trojans Attacks
• Mailfinder Trojan
• This Trojan seeks to steal the email addresses you’ve accumulated on
your device.
• Ransom Trojan
• This Trojan seeks a ransom to undo damage it has done to your
computer. This can include blocking your data or impairing your
computer’s performance.
• Remote Access Trojan
• This Trojan can give an attacker full control over your computer via a
remote network connection. Its uses include stealing your information
or spying on you.
Trojans Attacks
• Rootkit Trojan
• A rootkit aims to hide or obscure an object on your
infected computer. The idea? To extend the time a
malicious program runs on your device.

• SMS Trojan
• This type of Trojan infects your mobile device and can
send and intercept text messages. Texts to premium-rate
numbers can drive up your phone costs.
Trojans Attacks
• Trojan banker
• This Trojan takes aim at your financial accounts. It’s
designed to steal your account information for all the
things you do online. That includes banking, credit card,
and bill pay data.

• Trojan IM
• This Trojan targets instant messaging. It steals your logins
and passwords on IM platforms.
Trojans Attacks
• Rakhni Trojan.This malware has been around since 2013. More recently, it
can deliver ransomware or a cryptojacker (allowing criminals to use your
device to mine for cryptocurrency) to infected computers. “The growth in coin
mining in the final months of 2017 was immense,” the 2018 Internet Security
Threat Report notes. “Overall coin-mining activity increased by 34,000 percent
over the course of the year.”

• ZeuS/Zbot.This banking Trojan is another oldie but baddie. ZeuS/Zbot source

code was first released in 2011. It uses keystroke logging — recording your
keystrokes as you log into your bank account, for instance — to steal your
credentials and perhaps your account balance as well.
Session Hijacking Attacks
• In the Session Sniffing, as we can
see, first the attacker uses a
sniffer to capture a valid token
session called “Session ID”, then
they use the valid token session to
gain unauthorized access to the
Web Server.
Session Hijacking Attacks
• Cross-site script attack
• The attacker can compromise the
session token by using malicious
code or programs running at the
client-side.
• The example shows how the
attacker could use an XSS attack
to steal the session token.
• If an attacker sends a crafted link
to the victim with the malicious
JavaScript, when the victim clicks
on the link, the JavaScript will run
and complete the instructions
Session Hijacking Attacks
• Cross-site script attack
• The example in figure uses an XSS
attack to show the cookie value of
the current session; using the
same technique it’s possible to
create a specific JavaScript code
that will send the cookie to the
attacker.
• <SCRIPT>
• alert(document.cookie);

• </SCRIPT>
 Injection Attacks
• During an injection attack, an attacker can provide malicious input to a web
application (inject it) and change the operation of the application by forcing it to
execute certain commands.

• An injection attack can expose or damage data, lead to a denial of service or a

full webserver compromise.

• Injection attacks are one of the most common and dangerous web attacks.
Injection vulnerability is ranked at #1 in the
OWASP Top Ten Web Application Security Risks.

• Several injection attacks are also featured in the Common Weakness Enumeration
(CWE) Top 25 Most Dangerous Software Weaknesses.
 Types of Injection Attacks
• While SQL and Cross-Site Scripting injection attacks
are the most common types, there is a host of such
attacks, all of which have different aims and means to
achieving them.

• The main types of injection attacks that your

application may be vulnerable to are:
• SQL Injection (SQLi)
• Cross-Site Scripting (XSS)
• Code Injection
• Command Injection
• CCS Injection
• SMTP/IMAP Command Injection
• Host Header injection
• LDAP Injection
• CRLF Injection
 SQL Injection (SQLi)
• SQL is a query language to communicate with a database. It can be used
to perform actions to retrieve, delete and save data in the database.

• An attacker will try to manipulate the SQL query used in the web
application and gain direct access to your data during an SQL injection
(SQLi) attack.

• This is typically done through a web form input field, comment fields, or
other ways which are freely accessible to users.

• Such malicious SQL statements will seek to exploit a vulnerability in the

authentication and authorization procedures of the application.
 Cross-Site Scripting (XSS)
• A text containing malicious code (typically in JavaScript) is inserted
into a web page during a Cross-Site Scripting attack. When an
unsuspecting user visits that web page, the code is executed.

• For example, a string of text may be added to the URL. If the

application fails to validate it and allows it to pass, a user’s browser
will execute the code leading to a breach.

• An XSS attack can be used to steal cookie details, change user

settings, hijack user sessions, and more. This can open the door to
impersonation and defacement.
 Code Injection
• Code typically employs a code injection technique via multiple input
fields, including text input, HTTP GET/POST/PUT/DELETE parameters,
headers, cookies, etc.

• Once inside the target application, the attacker may force the
webserver to do what they want by gaining greater privileges.

• A code injection may impact an application anywhere, from gaining

access to data to fully compromising the system. Therefore, a
vulnerability to a code injection is of great concern.
 Command Injection
• Sometimes web applications need to call a system command on the
webserver that is running them. In such instances, if user input is not
validated and restricted, a command injection can occur.

• Unlike code injections, command injections only require the attacker to

know the operating system used. Then, the attacker inserts a command
into the system, using the user privileges. The inserted command then
executes in the host system.

• A command injection can compromise that application and its data and
the entire system, connected servers, systems, and other infrastructure.
 CCS Injection
• A CCS injection exploits a vulnerability found in the
ChangeCipherSpec processing in some versions of OpenSSL.

• During such an attack, invalid signals are sent by attackers in

the handshake session between servers and clients.

• This allows them to seize encryption key materials, access

the communication between server and client, and possibly
perform identity theft.
 SMTP/IMAP Command Injection
• Apart from the above, there are several other types of injection attacks
that are also used. Unfortunately, these are currently not covered by the
Crashtest Security Suite.

• Also known as an Email Header injection, this is a form of mail command

injection that targets mail servers.

• This is done by inserting additional headers into a message that contains

commands to the SMTP server.

• Unfortunately, most mail servers don’t have a strong level of protection

against attacks on IMAP and SMTP.
 Host Header injection
• When a server hosts many websites, the server eventually needs a
host header.

• The host header’s value specifies which website or web application

must respond to an HTTP request.

• Manipulation of such a host header creates a form of attack that can

lead to password resets.

• In addition, host header injections can also lead to web cache

poisoning.
 LDAP injection
• Lightweight Directory Access Protocol (LDAP) is
designed to search resources (devices, files, other
users) in a network.

• It is beneficial for intranets, and when used as part

of a single sign-on system, it can store usernames
and passwords.

• An unvalidated LDAP statement is injected that

directs a server to perform a certain command
during such an attack.
 CRLF injection
• “Carriage Return” and “Line Feed” (CRLF), or \r and
\n, are elements that are used in HTTP headers to
terminate a line.

• In addition, they are used to split text streams,

such as HTTP headers, into separate parts.

• A CRLF injection occurs when an attacker manages

to introduce a CRLF sequence into an application.

• Typically this is done by introducing it into an HTTP

header which is then called HTTP Response