Ethereum Smart Contract Source Code Review

 Introduction 

As Crypto currency technologies are becoming more and more prevalent, as the time is passing by, and banks will soon start adopting them. Ethereum blockchain and other complex blockchain programs are relatively new and highly experimental. Therefore, we should expect constant changes in the security landscape, as new bugs and security risks are discovered, and new best practices are developed [1].This article is going to discuss how to perform a source code review in Ethereum Smart Contracts (SCs) and what to look for. More specifically we are going to focus in specific keywords and how to analyse them. 

The points analysed are going to be:

• User supplied input filtering, when interacting directly with SC
• Interfacing with external SCs
• Interfacing with DApp applications
• SC formal verification
• Wallet authentication in DApp

SC Programming Mindset

When designing an SC ecosystem (a group of SCs, constitutes an ecosystem) is it wise to have some specific concepts and security design principles in mind. SC programming requires a different engineering mindset than we may be used to. The cost of failure can be high, and change can be difficult, making it in some ways more similar to hardware programming or financial services programming than web or mobile development. 

When programming SCs we should be able to:

• Design carefully roll outs
• Keep contracts simple and modular
• Be fully aware of blockchain properties
• Prepare for failure

Key Security Concepts For SCs Systems

More specifically it is mandatory and the responsible thing to  is to take into consideration the following areas:

• SC ecosystem monitoring e.g. monitor for unusual transactions etc.
• SC ecosystem governance/admin e.g. by using proxy SC that follow best practices etc.
• SC formal verification of all the SCs interacting with
• SC modular/clean coding e.g. use comments and modular code etc. 
• SC ecosystem code auditing by an external independent 3rd party
• SC ecosystem system penetration testing by an external independent 3rd party  

Note: At this point we should point out that it is important that DApp smart contract interaction should also be reviewed.

SCs User Input Validation

Make sure you apply user input validation on a DApp and SC level. Remember that on-chain data are public and an adversary can interact with a SC directly, by simply visiting an Ethereum explorer in etherscan.io, the following screenshots demonstrate that.

Below we can see an example of a deployed contract:

Simple by clicking in the SC link we can interact with the contract:

Note:  Above we can see the upgrade function call and various other Admin functions. Of course is not that easy to interact with them.

It is also known that etherscan.io provides some experimental features to decompile the SC code:

 If we click the decompile code we get this screen below:

Below we can see how a DApp or wallet can interact with a SC:

There are five categories of Ethereum wallets that can interact with DApps:

• Browser built-in (e.g. Opera, Brave etc)
• Browser extension (e.g. MetaMask )
• Mobile wallets (e.g. Trust, Walleth, Pillar etc.)
• Account-based web wallets (e.g. Fortmatic, 3box etc.)
• Hardware wallets (e.g. Ledger, Trezor etc.)

Then there is a larger category of wallets that cannot integrate with DApps include generic wallet apps that lack the functionality to integrate with smart contracts. Different wallets have a different user experience to connect. For example, with MetaMask you get a Connect pop up. With mobile wallets, you scan a QR code. So phishing attacks take a different for e.g. an attacker can spoof a QR code, through online free QR generators etc. When assessing a DApp the architecture is of paramount importance. A user with a Metamask plugin can use it to connect to the DApp. The DApp automatically will associate the interaction with the user public key to run various tasks. 

For a Web based DApp we can use traditional filtering methods. But for SCs using Solidity we can use assert and require are as convenience functions that check for conditions (e.g. a user supplies input and the mentioned functions check if the conditions are met). In cases when conditions are not met, they throw exceptions, that we help us handle the errors.

These are the cases when Solidity creates assert-type of exceptions when we [3]:

• Invoke Solidity assert with an argument, showing false.
• Invoke a zero-initialized variable of an internal function type.
• Convert a large or negative value to enum.
• We divide or modulo by zero.
• We access an array in an index that is too big or negative.

The require Solidity function guarantees validity of conditions that cannot be detected before execution. It checks inputs, contract state variables and return values from calls to external contracts.

In the following cases, Solidity triggers a require-type of exception when [3]:

• We call require with arguments that result in false.
• A function called through a message does not end properly.
• We create a contract with new keyword and the process does not end properly.
• We target a codeless contract with an external function.
• We contract gets Ether through a public getter function.
• We .transfer() ends in failure.

Generally speaking when handling complex user input and run mathematical calculations it is mandatory to use external libraries from 3rd partyaudited code. A code project to look into would be SafeMath from OpenZeppelin. SafeMath is a wrapper over Solidity’s arithmetic operations with added overflow checks. Arithmetic operations in Solidity wrap on overflow. This can easily result in bugs, because programmers usually assume that an overflow raises an error, which is the standard behavior in high level programming languages. SafeMath restores this intuition by reverting the transaction when an operation overflows.

SC External Calls

Calls to untrusted 3rd party Smart Contracts can introduce several security issues. External calls may execute malicious code in that contract or any other contract that it depends upon. As such, every external call should be treated as a potential security risk.  Solidity's call function is a low-level interface for sending a message to an SC. It returns false if the subcall encounters an exception, otherwise it returns true. There is no notion of a legal call, if it compiles, it's valid Solidity.

Especially when the return value of a message call is not checked, execution will resume even if the called contract throws an exception. If the call fails accidentally or an attacker forces the call to fail, this may cause unexpected behavior in the subsequent program logic. Always make sure to handle the possibility that the call will fail by checking the return value of that function [4].

Reentrancy (Recursive Call Attack)

One of the major risks of calling external contracts is that they can take over the control flow. In the reentrancy attack (a.k.a. recursive call attack) calling external contracts can take over the control flow, and make changes to your data that the calling function wasn’t expecting. A reentrancy attack occurs when the attacker drains funds from the target contract by recursively calling the target’s withdraw function [4].

Below we can see a schematic representation:

Note: For more information on this type of attack please see [4]

SC Denial of Service Attacks

Each block has an upper bound on the amount of gas that can be spent, and thus the amount computation that can be done. This is the Block Gas Limit. If the gas spent exceeds this limit, the transaction will fail. 

This leads to a couple possible Denial of Service vectors:

• Gas Limit DoS on a Contract via Unbounded Operations
• Gas Limit DoS on the Network via Block Stuffing

Note: For more information on DoS attacks see consensys.github.io

Use Of Delegatecall/Callcode and Libraries

According the Solidity docs [7], there exists a special variant of a message call, named delegatecall which is identical to a message call apart from the fact that the code at the target address is executed in the context of the calling contract and msg.sender and msg.value do not change their values.

This means that a contract can dynamically load code from a different address at runtime. Storage, current address and balance still refer to the calling contract, only the code is taken from the called address. This makes it possible to implement the “library” feature in Solidity: Reusable library code that can be applied to a contract’s storage, e.g. in order to implement a complex data structure.

Improper security use of this function was the cause for the Parity Multisig Wallet hack in 2017. This function is very useful for granting our contract the ability to make calls on other contracts, as if that code were a part of our own contract. However, using delegatecall() causes all public functions from the called contract to be callable by anyone. Because this behavior was not recognized when Parity built its own custom libraries. 

Epilogue 

Writing secure smart code is a lot of work and can be very complex.

References:

• consensys.github.io [1]
• consensys.github.io [2]
• www.bitdegree.org [3]
• medium.com [4]
• ethereum.stackexchange.com [5]
• ethernaut.openzeppelin.com [6]
• docs.soliditylang.org [7]

SSRFing External Service Interaction and Out of Band Resource Load (Hacker's Edition)

External Service Interaction & Out-of-Band Resource Loads

Host Header Exploitation // SSRF Primitives // Infrastructure Pivoting

SSRF Host Header Injection CWE-918 OWASP A10:2021 Cache Poisoning Updated 2026

In the recent past we encountered two relatively new types of attacks: External Service Interaction (ESI) and Out-of-Band Resource Loads (OfBRL).

1. An ESI [1] occurs only when a web application allows interaction with an arbitrary external service.
2. OfBRL [6] arises when it is possible to induce an application to fetch content from an arbitrary external location, and incorporate that content into the application's own response(s).

Taxonomy Note (2026): Both ESI and OfBRL are now classified under OWASP A10:2021 — SSRF and map to CWE-918 (Server-Side Request Forgery). ESI also maps to CWE-441 (Unintentional Proxy or Intermediary).

The Problem with OfBRL

The ability to request and retrieve web content from other systems can allow the application server to be used as a two-way attack proxy (when OfBRL is applicable) or a one-way proxy (when ESI is applicable). By submitting suitable payloads, an attacker can cause the application server to attack, or retrieve content from, other systems that it can interact with. This may include public third-party systems, internal systems within the same organization, or services available on the local loopback adapter of the application server itself. Depending on the network architecture, this may expose highly vulnerable internal services that are not otherwise accessible to external attackers.

The Problem with ESI

External service interaction arises when it is possible to induce an application to interact with an arbitrary external service, such as a web or mail server. The ability to trigger arbitrary external service interactions does not constitute a vulnerability in its own right, and in some cases might even be the intended behavior of the application. However, in many cases, it can indicate a vulnerability with serious consequences.

Figure 1 — ESI (one-way) vs OfBRL (two-way) attack paths

The Verification

We do not have ESI or OfBRL when:

1. In Collaborator, the source IP is our browser IP (the server didn't make the request).
2. There is a 302 redirect from our host to the Collaborator (i.e. our source IP appears in the Collaborator logs, not the server's).

Below we can see the original configuration in the repeater, followed by the modified configuration for the test. In the original request, the Host header reflects the legitimate domain. In the test request, we replace it with our Collaborator payload or target host.

Original request

GET / HTTP/1.1 Host: our_vulnerableapp.com Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close

Malicious requests

GET / HTTP/1.1 Host: malicious.com Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close

GET / HTTP/1.1 Host: 127.0.0.1:8080 Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close

If the application is vulnerable to OfBRL, the reply is going to be processed by the vulnerable application, bounce back to the sender (the attacker) and potentially load in the context of the application. If the reply does not come back to the sender, then we might have an ESI, and further investigation is required.

The RFCs Updated

It usually is a platform issue and not an application one. In some scenarios when we have, for example, a CGI application, the HTTP headers are handled by the application (i.e. the app is dynamically manipulating the HTTP headers to run properly). This means that HTTP headers such as Location and Host are handled by the app and therefore a vulnerability might exist. It is recommended to run HTTP header integrity checks when you own a critical application that is running on your behalf.

For more information on the subject, read RFC 9110 (HTTP Semantics, June 2022) [2] and RFC 9112 (HTTP/1.1 Message Syntax and Routing) [2b], which supersede the obsolete RFC 2616. The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URI. The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on a single IP address.

RFC Update: RFC 2616 was obsoleted in 2014 by RFCs 7230–7235, which were themselves superseded by RFCs 9110–9112 in June 2022. All references in this article now point to the current standards.

When TLS is enforced throughout the whole application (even the root path /), an ESI or OfBRL is significantly harder to exploit, because TLS performs source origin authentication — as soon as a connection is established with an IP, the protocol guarantees that the connection will serve traffic only from the original certificate holder. More specifically, we are going to get an SNI error.

SNI prevents what's known as a "common name mismatch error": when a client device reaches the IP address of a vulnerable app, but the name on the TLS certificate doesn't match the name of the website. SNI was added to the IETF's Internet RFCs in June 2003 through RFC 3546, with the latest version in RFC 6066. The current TLS 1.3 specification is RFC 8446 [10].

ECH Warning (2025+): Encrypted Client Hello (ECH), specified in RFC 8744 and actively being deployed by major browsers and CDNs, encrypts the SNI field within the TLS handshake. This means that SNI-based filtering and inspection at network perimeters becomes ineffective when ECH is in use. Security teams should account for this when relying on SNI as a defensive control.

Figure 2 — TLS/SNI protection mechanism (and its ECH caveat)

The option to trigger an arbitrary external service interaction does not constitute a vulnerability in its own right, and in some cases it might be the intended behavior of the application. But we as hackers want to exploit it — what can we do with an ESI or an Out-of-Band Resource Load?

The Infrastructure

Well, it depends on the overall setup. The highest-value scenarios are the following:

1. The application is behind a WAF (with restrictive ACLs)
2. The application is behind a UTM (with restrictive ACLs)
3. The application is running multiple applications in a virtual environment
4. The application is running behind a NAT
5. The application runs in a cloud environment with metadata endpoints accessible from localhost
6. The application runs in a containerized environment (Docker/Kubernetes) with internal service discovery

In order to perform the attack, we simply inject our host value in the HTTP Host header (hostname including port).

Figure 3 — Host header injection pivoting through infrastructure (including cloud/container targets)

The Test

Burp Professional edition has a feature named Collaborator. Burp Collaborator is a network service that Burp Suite uses to help discover vulnerabilities such as ESI and OfBRL [3]. A typical example would be to use Burp Collaborator to test if ESI exists.

Burp Collaborator request

GET / HTTP/1.1 Host: edgfsdg2zjqjx5dwcbnngxm62pwykabg24r.burpcollaborator.net Pragma: no-cache Cache-Control: no-cache, no-transform Connection: keep-alive

Burp Collaborator response

HTTP/1.1 200 OK Server: Burp Collaborator https://burpcollaborator.net/ X-Collaborator-Version: 4 Content-Type: text/html Content-Length: 53 <html><body>drjsze8jr734dsxgsdfl2y18bm1g4zjjgz</body></html>

The Post Exploitation

As hacker-artists, we now think about how to exploit this. The scenarios are: [7] [8]

1. Attempt to load the local admin panels.
2. Attempt to load the admin panels of surrounding applications.
3. Attempt to interact with other services in the DMZ.
4. Attempt to port scan localhost.
5. Attempt to port scan DMZ hosts.
6. Use it to exploit IP trust and run a DoS attack against other systems.
7. Access cloud metadata endpoints to extract IAM credentials or instance identity tokens.
8. Probe Kubernetes API or container sidecar services (e.g. Envoy admin on localhost:15000).

A good tool for automating this is Burp Intruder [4]. Using Sniper mode, we can:

1. Rotate through different ports, using the vulnapp.com domain name.
2. Rotate through different ports, using the vulnapp.com external IP.
3. Rotate through different ports, using the vulnapp.com internal IP, if applicable.
4. Rotate through different internal IPs in the same domain, if applicable.
5. Rotate through different protocols (may not always work).
6. Brute-force directories on identified DMZ hosts.

Burp Intruder — scanning surrounding hosts

GET / HTTP/1.1 Host: 192.168.1.§§ Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close

Burp Intruder — port scanning surrounding hosts

GET / HTTP/1.1 Host: 192.168.1.1:§§ Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close

Burp Intruder — port scanning localhost

GET / HTTP/1.1 Host: 127.0.0.1:§§ Pragma: no-cache Cache-Control: no-cache, no-transform Connection: close

Modern Attack Vectors New 2026

Since the original publication of this article, several high-impact attack surfaces have emerged that directly exploit ESI/OfBRL primitives:

Cloud metadata endpoint exploitation

Cloud providers expose instance metadata via link-local addresses. When a vulnerable application can be coerced into making requests to these endpoints via Host header injection, an attacker can extract IAM credentials, service account tokens, instance identity documents, and network configuration details.

GET / HTTP/1.1 Host: 169.254.169.254 # AWS IMDSv1 — returns IAM role credentials GET / HTTP/1.1 Host: metadata.google.internal # GCP — returns service account tokens GET / HTTP/1.1 Host: 169.254.169.254 Metadata: true # Azure — requires Metadata header (may not work via Host injection alone)

Mitigation: AWS IMDSv2 mitigates this by requiring a PUT request with a TTL-bounded token (hop limit = 1). GCP Compute VMs support a similar metadata concealment mechanism. Ensure your cloud instances enforce these protections.

Container and Kubernetes exploitation

In containerized environments, the application server often has network access to internal Kubernetes services that are never meant to be internet-facing:

GET / HTTP/1.1 Host: kubernetes.default.svc:443 # K8s API server — may leak secrets, pod specs, RBAC config GET / HTTP/1.1 Host: 127.0.0.1:15000 # Envoy sidecar admin — config dump, cluster endpoints, stats GET / HTTP/1.1 Host: 127.0.0.1:9090 # Prometheus metrics — may expose internal service topology

Practical cache poisoning (Kettle, 2018)

James Kettle's 2018 PortSwigger research on practical web cache poisoning significantly expanded the attack surface understanding for Host header injection. His work demonstrated that unkeyed HTTP headers (including Host, X-Forwarded-Host, and X-Forwarded-Scheme) can be used to poison shared caches (CDNs, reverse proxies) at scale, affecting all users served by the poisoned cache entry. This research formalized the technique that was previously theoretical into a repeatable, high-impact attack chain.

Figure 4 — Cache poisoning via Host header injection

What Can You Do

The full exploitation analysis — this vulnerability can be used in the following ways:

1. Bypass restrictive UTM ACLs
2. Bypass restrictive WAF rules
3. Bypass restrictive firewall ACLs
4. Perform cache poisoning
5. Fingerprint internal infrastructure
6. Perform DoS exploiting IP trust
7. Exploit applications hosted on the same machine (multiple app loads)
8. Extract cloud IAM credentials via metadata endpoints
9. Map Kubernetes cluster topology via internal service discovery
10. Exfiltrate data through DNS-based out-of-band channels

The impact of a maliciously constructed response can be magnified if it is cached either by a shared web cache or the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers or CDNs, then all users of that cache will continue to receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, that user will continue to receive the malicious content until the cache entry expires [5].

What Can't You Do

You cannot perform XSS or CSRF exploiting this vulnerability, unless certain conditions apply (e.g. the poisoned response injects attacker-controlled JavaScript into a cached page, or the application reflects the Host header value into HTML output without encoding).

The Fix Updated

If the ability to trigger arbitrary ESI or OfBRL is not intended behavior, then you should implement a whitelist of permitted URLs, and block requests to URLs that do not appear on this whitelist [6]. Running host integrity checks is also recommended.

Review the purpose and intended use of the relevant application functionality, and determine whether the ability to trigger arbitrary external service interactions is intended behavior. If so, be aware of the types of attacks that can be performed via this behavior and take appropriate measures. These measures might include blocking network access from the application server to other internal systems, and hardening the application server itself to remove any services available on the local loopback adapter.

More specifically, we can:

1. Apply egress filtering on the DMZ
2. Apply egress filtering on the host (iptables/nftables rules, or cloud security group outbound rules)
3. Apply whitelist IP restrictions in the application
4. Apply blacklist restrictions in the application (not recommended — incomplete by nature)
5. Validate and normalize the Host header at the reverse proxy layer before it reaches the application (e.g. Nginx server_name directive with explicit hostnames, reject requests with unknown Host values)
6. Use X-Forwarded-Host with strict allowlisting rather than trusting the raw Host header — and ensure the reverse proxy strips any client-supplied X-Forwarded-* headers before adding its own
7. Enforce IMDSv2 on cloud instances (hop limit = 1, PUT-based token acquisition) to block Host header SSRF to metadata endpoints
8. Apply Kubernetes NetworkPolicies to restrict pod-to-pod and pod-to-service communication to only what's necessary
9. Deploy egress proxies for any application that legitimately needs to make outbound HTTP requests — force all outbound traffic through a proxy with domain allowlisting

---

References

1. portswigger.net — External Service Interaction (DNS)
2. RFC 9110 — HTTP Semantics (June 2022) — supersedes RFC 2616
3. RFC 9112 — HTTP/1.1 Message Syntax and Routing (June 2022)
4. portswigger.net — Burp Collaborator
5. portswigger.net — Burp Intruder
6. owasp.org — Cache Poisoning
7. portswigger.net — Out-of-Band Resource Load (HTTP)
8. CWE-918: Server-Side Request Forgery (SSRF)
9. CWE-406: Insufficient Control of Network Message Volume
10. CWE-441: Unintentional Proxy or Intermediary
11. RFC 8446 — TLS 1.3 (August 2018)
12. RFC 6066 — TLS Extensions (January 2011) — SNI
13. cloudflare.com — What is SNI?
14. portswigger.net — Practical Web Cache Poisoning (Kettle, 2018)
15. OWASP Top 10 2021 — A10: SSRF

Hacker’s Elusive Thoughts The Web

Introduction

The reason for this blog post is to advertise my book. First of all I would like to thank all the readers of my blog for the support and feedback on making my articles better. After 12+ years in the penetration testing industry, the time has come for me to publish my book and tranfer my knowledge to all the intersted people that like hacking and want to learn as much as possible. Also at the end of the blog you will find a sample chapter.

About The Author

Gerasimos is a security consultant holding a MSc in Information Security, a CREST (CRT), a CISSP, an ITILv3, a GIAC GPEN and a GIAC GAWPT accreditation. Working alongside diverse and highly skilled teams Gerasi- mos has been involved in countless comprehensive security tests and web application secure development engagements for global web applications and network platforms, counting more than 14 years in the web application and application security architecture.

Gerasimos further progressing in his career has participated in vari- ous projects providing leadership and accountability for assigned IT security projects, security assurance activities, technical security reviews and assess- ments and conducted validations and technical security testing against pre- production systems as part of overall validations.

Where From You Can Buy The Book

This book can be bought from leanbup. Leanpub is a unique publishing platform that provides a way in the world to write, publish and sell in-progress and completed ebooks. Anyone can sign up for free and use Leanpub's writing and publishing tools to produce a book and put it up for sale in our bookstore with one click. Authors are paid a royalty of 90% minus 50 cents per transaction with no constraints: they own their work and can sell it elsewhere for any price.

Authors and publishers can also upload books they have created using their own preferred book production processes and then sell them in the Leanpub bookstore, taking advantage of our high royalty rates and our in-progress publishing features.

Please for more information about bying the book see link: https://leanpub.com/hackerselusivethoughtstheweb

Why I Wrote This Book

I wrote this book to share my knowledge with anyone that wants to learn about Web Application security, understand how to formalize a Web Appli- cation penetration test and build a Web Application penetration test team.

The main goal of the book is to: 

Brainstorm you with some interesting ideas and help you build a com- prehensive penetration testing framework, which you can easily use for your specific needs. Help you understand why you need to write your own tools. Gain a better understanding of some not so well documented attack techniques.

The main goal of the book is not to:

 
Provide you with a tool kit to perform Web Application penetration tests. Provide you with complex attacks that you will not be able to under- stand. Provide you with up to date information on latest attacks.

Who This Book Is For 

This book is written to help hacking enthusiasts to become better and stan- dardize their hacking methodologies and techniques so as to know clearly what to do and why when testing Web Applications. This book will also be very helpful to the following professionals:

1. Web Application developers.
2. Professional Penetration Testers.
3. Web Application Security Analysts.
4. Information Security professionals.
5. Hiring Application Security Managers.
6. Managing Information Security Consultants.

How This Book Is Organised  

Almost all chapters are written in such a way so as to not require you to read the chapters sequentially, in order to understand the concepts presented, although it is recommended to do so. The following section is going to give you an overview of the book:

Chapter 1: Formalising Web Application Penetration Tests -

This chapter is a gentle introduction to the world of penetration testing, and attempt to give a realistic view on the current landscape. More specifically it attempt to provide you information on how to compose a Pen- etration Testing team and make the team as ecient as possible and why writing tools and choosing the proper tools is important.

Chapter 2: Scanning With Class -

The second chapter focuses on helping you understand the dierence between automated and manual scanning from the tester’s perspective. It will show you how to write custom scanning tools with the use of Python. This part of the book also contains Python chunks of code demonstrating on how to write tools and design your own scanner.

Chapter 3: Payload Management -

This chapter focuses on explaining two things a) What is a Web payload from security perspective, b) Why is it important to obfuscated your payloads.

Chapter 4: Infiltrating Corporate Networks Using XXE -

This chapter focuses on explaining how to exploit and elevate an External Entity (XXE) Injection vulnerability. The main purpose of this chapter is not to show you how to exploit an XXE vulnerability, but to broaden your mind on how you can combine multiple vulnerabilities together to infiltrate your target using an XXE vulnerability as an example.

Chapter 5: Phishing Like A Boss -

This chapter focuses on explaining how to perform phishing attacks using social engineering and Web vulnerabilities. The main purpose of this chapter is to help you broaden your mind on how to combine multiple security issues, to perform phishing attacks.

Chapter 6: SQL Injection Fuzzing For Fun And Profit -

This chapter focuses on explaining how to perform and automate SQL injection attacks through obfuscation using Python. It also explains why SQL injection attacks happen and what is the risk of having them in your web applications.


Sample Chapter Download

From the following link you will be able to download a sample chapter from my book:

Sample Book Download

Symetric Denial of Service Testing - Aka 1 on 1

Intro

This post is going to explain how to test a Denial of Service Vulnerability without crashing the actual service. More specifically we will focus on two vulnerabilities a) the slowris vulnerability (also known as Apache Partial HTTP Request Denial of Service Vulnerability) and b) the TLS Renegotiation and Denial of Service Attacks.

Apache Partial HTTP Request Denial of Service Vulnerability

The target application Apache Server is vulnerable to a denial of service named Slow-DoS attack, due to holding a connection open for partial HTTP requests. Both Apache Versions 1.x and 2.x are vulnerable. Slow HTTP attacks are denial-of-service (DoS) attacks in which the attacker sends HTTP requests in pieces slowly, one at a time to a Web server. If an HTTP request is not complete, or if the transfer rate is very low, the server keeps its resources busy waiting for the rest of the data. When the server’s concurrent connection pool reaches its maximum, this creates a DoS. Slow HTTP attacks are easy to execute because they require only minimal resources from the attacker.

Business Impact

A remote attacker can cause a denial of service against the Web server which would prevent legitimate users from accessing the site.

Remediation

There are no vendor-supplied patches available at this time.  Upgrade to the latest version.

Example

Slowloris tool output:

./slowloris.pl -dns xxx.xxx.xxx -port 80 -timeout 2000 -num 100 -tcpto 5

CCCCCCCCCCOOCCOOOOO888@8@8888OOOOCCOOO888888888@@@@@@@@@8@8@@@@888OOCooocccc::::

CCCCCCCCCCCCCCCOO888@888888OOOCCCOOOO888888888888@88888@@@@@@@888@8OOCCoococc:::

CCCCCCCCCCCCCCOO88@@888888OOOOOOOOOO8888888O88888888O8O8OOO8888@88@@8OOCOOOCoc::

…[omitted]…

Welcome to Slowloris - the low bandwidth, yet greedy and poisonous HTTP client

Multithreading enabled.

Connecting to xxx.xxx.xxx:80 every 2000 seconds with 100 sockets:

                Building sockets.

                Building sockets.

                Sending data.

Current stats:  Slowloris has now sent 446 packets successfully.

This thread now sleeping for 2000 seconds...

                Sending data.

Current stats:  Slowloris has now sent 500 packets successfully.

This thread now sleeping for 2000 seconds...

Hping3 output

 hping3 -T -p 80  xxx.xxx.xxx

HPING xxx.xxx.xxx (eth1 xxx.xxx.xxx): NO FLAGS are set, 40 headers + 0 data bytes
hop=1 TTL 0 during transit from ip=xxx.xxx.xx. name=xxx
hop=1 hoprtt=0.6 ms
...[omitted]...
--- 192.168.0.2 hping statistic ---
10 packets transmitted, 21 packets received, 0% packet loss

Explanation 

In this scenario we send a low bust of packages using Slowloris and then launched Hping3 in port 80 (the same port as Slowloris) and saw that because the Slowloris open too many connections start receiving more packages than send.

TLS Protocol Session Renegotiation Security Vulnerability

TLS protocol is prone to a security vulnerability that allows for man-in-the-middle attacks and Denial of Service attacks. This issue does not allow attackers to decrypt encrypted data. More specifically, the issue exists in a way applications handle the session renegotiation process and may allow attackers to inject arbitrary plaintext into the beginning of application protocol stream.

• In case of the HTTP protocol used with the vulnerable TLS implementation, this attack is carried out by intercepting 'Client Hello' requests and then forcing session renegotiation. An unauthorized attacker can then cause the webserver to process arbitrary requests that would otherwise require valid client side certificate for authorization. The attacker will not be able to gain direct access to the server response.
•  Denial of Service attack is also be feasible. This attack further exploits the SSL secure Renegotiation feature to trigger thousands of renegotiation via single TCP connection and crush the service.

Business Impact

An adversary can potentially exploit the vulnerability and cause compromise of the confidentiality and availability of the vulnerable service.

Remediation

Man In The Middle Attack:

• OpenSSL workaround- OpenSSL has provided a version (0.9.8l) that has a workaround. Please refer to OpenSSL Change Log (Changes between 0.9.8k and 0.9.8l Section).
•  Microsoft workaround - Enable SSLAlwaysNegoClientCert on IIS 6 and above: Web servers running IIS 6 and later that are affected because they require mutual authentication by requesting a client certificate, can be hardened by enabling the SSLAlwaysNegoClientCert setting. This will cause IIS to prompt the client for a certificate upon the initial connection, and does not require a server-initiated renegotiation.

 For Denial of Service Attack –  No real solutions exists. The following steps can mitigate (but not solve) the problem:

• Disable SSL-Renegotiation
• Install SSL Accelerator

Example

host:xxx.xxx.xxx

Handshakes 0 [0.00 h/s], 1 Conn, 0 Err

Handshakes 44 [43.48 h/s], 16 Conn, 0 Err

Handshakes 118 [71.32 h/s], 25 Conn, 0 Err

Handshakes 193 [76.69 h/s], 32 Conn, 0 Err

Handshakes 290 [99.53 h/s], 38 Conn, 0 Err

Handshakes 371 [79.16 h/s], 43 Conn, 0 Err

Handshakes 459 [89.97 h/s], 48 Conn, 0 Err

Handshakes 545 [87.55 h/s], 52 Conn, 0 Err

Handshakes 632 [84.57 h/s], 56 Conn, 0 Err

Handshakes 728 [96.96 h/s], 60 Conn, 0 Err

Handshakes 819 [91.05 h/s], 63 Conn, 0 Err

Handshakes 913 [95.76 h/s], 66 Conn, 0 Err

Handshakes 989 [76.02 h/s], 70 Conn, 0 Err

Handshakes 1086 [96.98 h/s], 73 Conn, 0 Err

Handshakes 1165 [78.37 h/s], 77 Conn, 0 Err

Handshakes 1264 [97.87 h/s], 81 Conn, 0 Err

…[omitted]…

Handshakes 3642 [89.20 h/s], 144 Conn, 0 Err

Handshakes 3738 [92.35 h/s], 146 Conn, 0 Err

Handshakes 3828 [92.36 h/s], 148 Conn, 0 Err

Handshakes 3919 [93.75 h/s], 149 Conn, 0 Err

Handshakes 4003 [83.73 h/s], 151 Conn, 0 Err

Handshakes 4099 [90.18 h/s], 153 Conn, 0 Err

Handshakes 4197 [105.10 h/s], 155 Conn, 0 Err

Handshakes 4288 [90.83 h/s], 157 Conn, 0 Err

Handshakes 4379 [88.02 h/s], 159 Conn, 0 Err

Handshakes 4468 [88.77 h/s], 160 Conn, 0 Err

Handshakes 4568 [95.30 h/s], 162 Conn, 0 Err

Handshakes 4649 [87.94 h/s], 164 Conn, 0 Err

Handshakes 4743 [89.97 h/s], 166 Conn, 0 Err

Handshakes 4844 [106.67 h/s], 167 Conn, 0 Err

Handshakes 4930 [81.71 h/s], 169 Conn, 0 Err

Hping3 output

 hping3 -T -p 443 xxx.xxx.xxx

HPING xxx.xxx.xxx (eth1 xxx.xxx.xxx): NO FLAGS are set, 40 headers + 0 data bytes
hop=1 TTL 0 during transit from ip=xxx.xxx.xx. name=xxx
hop=1 hoprtt=0.6 ms
...[omitted]...
--- xxx.xxx.xxx hping statistic ---
10 packets transmitted, 15 packets received, 0% packet loss
Conclusion

Running point and click hacking tools for testing for Symmetric  DoS vulnerabilities should not be a taboo. If this is done then there zero doubt that this specific vulnerability can be exploited e.g. the sys admin can use stress test tools to record the performance of the server etc.  

References:

• https://www.thc.org/
• https://tools.ietf.org/html/rfc5746
• http://stackoverflow.com/questions/16909409/how-can-i-solve-the-qualys-apache-partial-http-request-denial-of-service-vulnera