EXPERT INSIGHT Adrian Pruteanu Becoming the Hacker The Playbook for Getting Inside the lta Ream w Natl PacktBecoming the Hacker The Playbook for Getting Inside the Mind of the Attacker Adrian Pruteanu Packt BIRMINGHAM - MUMBATBecoming the Hacker Copyright © 2019 Packt Publishing All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information. Acquisition Editors: Andrew Waldron, Frank Pohlmann, Suresh Jain Project Editor: Vero Content Development Editor: Joanne Lovell Technical Editor: Saby D'silva Proofreader: Salis Editing Indexer: Tejal Daruwale Soni Graphics: Sandip Tadge Production Coordinator: Pais ndip Tadge First published: February 2019 Production reference: 2070219 Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK. ISBN 978-1-78862-796-2 wow. [Link]svn Mapt mapt io Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website. Why subscribe? Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals + Learn better with Skill Plans built especially for you + Geta free eBook or video every month + Maptis fully searchable + Copy and paste, print, and bookmark content [Link] Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www. Packt comand as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at cust onercarewpacktpub. com for more details. At www Packt .com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.Contributors About the author Adrian Pruteamu is an accomplished security consultant and researcher working primarily in the offensive security space. In his career of over 10 years, he has gone through countless penetration testing engagements, red team exercises, and application security assessments. He routinely works with Fortune 500 companies, helping them secure their systems by identifying vulnerabil or reversing malware samples. Adrian likes to keep up with his certifications as well, and holds several of them, including CISSP, OSCE, OSCP, GXPN, GREM, and a bunch of Microsoft titles as well. As a certified trainer for Microsoft, he has also delivered custom training in the past to various clients. In his spare time, Adrian likes to develop new tools and software to aide with penetration testing efforts or just to keep users safe online. He may occasionally go after a bug bounty or two, and he likes to spend time researching and (responsibly) disclosing vulnerabilities. "T would like to thank my alwoays amazing wife, whose unwavering support and understanding helped zorite this book. Life fends to get busy when you're researching and writing on top of everything else, but her constant encouragement pushed me every day A special thank you to my family and friends for their support and mentorship, as well. also thank my parents, in particular, for bringing home that Siemens PC and showing me BASIC, igniting my love for computers at a young age. They've always nurtured my obsession with technology, and for that Iam forever grateful."About the reviewer Babak Esmaeili has been working in the cyber security field for more than 15 years. He started in this field from reverse engineering and continued his career in the penetration testing field. He has performed many penetration tests and consultancies for the IT infrastructure of many clients, After working as a senior penetration tester in a few companies, he started to research on combining steganography with cryptography. This research led him to develop a program with the ability to hide and encrypt infinite blockchained nodes of different files into one file. Babak has also written many articles about real-world practical penetration testing and software protection. Currently, he is working as a freelancer and researching, on developing an infrastructure versatile secure database with new technology for storing digital data, the idea of which he got from his software. He believes, that everyone must know about information technology as the new world is going to be digital. He also advises everyone to learn as much as they can about how to keep their data safe in this new digital world. "T want to thank everyone who helped in writing this book, and I'd like fo thank my beloved parents and dearest friends for their support.” Packt is searching for authors like you If you're interested in becoming an author for Packt, please visit authozs .packtpub. conand apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea,Table of Contents Preface vii Chapter 1: Introduction to Attacking Web Applications 1 Rules of engagement 3 Communication 3 Privacy considerations 5 Cleaning up 6 The tester's toolkit 7 Kali Linux 7 Kali Linux alternatives 8 The attack proxy 10 Burp Suite 10 Zed Attack Proxy 12 Cloud infrastructure 12 Resources 14 Exercises 15 Summary 15 Chapter 2: Efficient Discovery 17 Types of assessments 7 Target mapping 19 Masscan 21 WhatWeb 23 Nikto 24 CMS scanners 25 Efficient brute-forcing 26 Content discovery 28 Burp SuiteTable of Contents OWASP ZAP 30 Gobuster 30 Persistent content discovery 32 Payload processing 36 Polyglot payloads 49 Same payload, different context 55 Code obfuscation 56 Resources 59 Exercises 60 Summary 60 Chapter 3: Low-Hanging Fruit 61 Network assessment 61 Looking for a way in 64 Credential guessing 66 A better way to shell 73 Cleaning up 7 Resources 78 Summary 78 Chapter 4: Advanced Brute-forcing 79 Password spraying 80 Linkedin scraping 82 Metadata 85 The cluster bomb 87 Behind seven proxies 1 Torify 92 Proxy cannon 99 Summary 104 Chapter 5: File Inclusion Attacks 105 RFI 106 LFI 108 File inclusion to remote code execution n7 More file upload issues 119 Summary 124 Chapter 6: Out-of-Band Exploitation 125 A common scenario 126 Command and control 127 Let's Encrypt Communication 129 INet simulation 133 0Table of Contents The confirmation 138 Async data exfiltration 139 Data inference 142 Summary 143 Chapter 7: Automated Testing 145 Extending Burp 146 Authentication and authorization abuse 149 The Autorize flow 150 The Swiss Army knife 153 sqimap helper 154 Web shells 158 Obfuscating code 161 Burp Collaborator 163 Public Collaborator server 165 Service interaction 166 Burp Collaborator client 167 Private Collaborator server 171 Summary 17 Chapter 8: Bad Serialization 179 Abusing deserialization 180 Attacking custom protocols 187 Protocol analysis 188 Deserialization exploit 191 Summary 199 Chapter 9: Practical Client-Side Attacks 201 SOP 202 Cross-origin resource sharing 206 XxSS 207 Reflected XSS 207 Persistent XSS 209 DOM-based XSS 210 CSRF 213 BeEF 216 Hooking 220 Social engineering attacks 224 The keylogger 227 Persistence 233 Automatic exploitation 235 Tunneling traffic 240 Summary 242 tyTable of Contents Chapter 10: Practical Server-Side Attacks 243 Internal and external references 244 XXE attacks 246 Abillion laughs 246 Request forgery 248 ‘The port scanner 252 Information leak 255 Blind XXE 262 Remote code execution 267 Interactive shells 269 Summary 272 Chapter 11: Attacking APIs 275 ‘API communication protocols 276 SOAP 277 REST 280 API authentication 281 Basic authentication 281 API keys 282 Bearer authentication 283 JWTs 283 JWT quirks 285 Burp JWT support 287 Postman 289 Installation 291 Upstream proxy 293 The environment 295 Collections 296 Collection Runner 303 Attack considerations 305 Summary 306 Chapter 12: Attacking CMS 307 Application assessment 308 WPScan 308 sqimap 315 Droopescan 317 Arachni web scanner 318 Backdooring the code 322 Persistence 323 Credential exfiltration 334 Summary 344Table of Contents Chapter 13: Breaking Containers 345 Vulnerable Docker scenario 347 Foothold 349 Situational awareness 357 Container breakout 365 Summary 371 Other Books You May Enjoy 373 Index 379 (v)Preface Becoming the Hacker will teach you how to approach web penetration testing with an attacker's mindset. While testing web applications for performance is common, the ever-changing threat landscape makes security testing much more difficult for the defender. There are many web application tools that claim to provide a complete survey and defense against potential threats, but they must be analyzed in line with the security needs of each web application or service. We must understand how an attacker approaches a web application and the implications of breaching its defenses. Through the first part of the book, Adrian Pruteanu walks you through commonly encountered vulnerabilities and how to take advantage of them to achieve your goal. The latter part of the book shifts gears and puts the newly learned techniques into practice, going over scenarios where the target may be a popular content management system or a containerized application and its network Becoming the Hacker is a clear guide to web application security from an attacker's point of view, from which both sides can benefit. Who this book is for The reader should have basic security experience, for example, through running, a network or encountering security issues during application development. Formal education in security is useful, but not required. This title is suitable for people with at least two years of experience in development, network management, or DevOps, or with an established interest in security.Preface What this book covers Chapter 1, Introduction to Attacking Web Applications, introduces you to the tools, environments, and the bare minimum ROE we must follow during engagements. We also look at the penetration tester's toolkit and explore cloud as the emerging, tool for the web penetration tester. Chapter 2, Efficient Discovery, walks you through a journey of improving efficiency in terms of gathering information on a target. Chapter 3, Low-Hanging Fruit, clarifies, emphasizes, and exploits the fact that it is very difficult for defenders to get security right all the time, and many simple vulnerabilities often fall through the cracks. Chapter 4, Advanced Brute-forcing, discusses brute-forcing in detail, and also explores a couple of techniques for staying under the radar while conducting brute-force attacks during an engagement Chapter 5, File Inclusion Attacks, helps you explore the file inclusion vulnerabilities. We also look at several methods to use an application's underlying filesystem to our advantage. Chapter 6, Out-of-Band Exploitation, looks at out-of-band discovery, exploitation of application vulnerabilities, and setting up a command and control infrastructure in the cloud. Chapter 7, Automated Testing, helps you automate vulnerability exploitation, including leveraging Burp's Collaborator feature to make out-of-band discovery easier. Chapter 8, Bad Serialization, discusses deserialization attacks in detail. We dig deep into this vulnerability type and look at practical exploits. Chapter 9, Practical Client-Side Attacks, covers information relating to client-side attacks. We look at the three types of XSS: reflected, stored, and DOM, as well as CSRF, and chaining these attacks together. We also cover the SOP and how it affects loading third-party content or attack code onto the page. Chapter 10, Practical Server-Side Attacks, takes you through attacking the server by way of XML, as well as leveraging SSRF to chain attacks and reach further into the network, Chapter 11, Attacking APIs, focuses our attention on APIs and how to effectively test and attack them. All of the skills you have learned up to this point will come in handy. [vn]Preface Chapter 12, Attacking CMS, looks at attacking CMSs and exploring vulnerabilities with them. Chapter 13, Breaking Containers, helps you understand how to securely configure Docker containers before deployment with an example of how a compromised containerized CMS led to another container vulnerability that results in full compromise of the host. To get the most out of this book You should have a basic knowledge of operating systems, including Windows and Linux. We will be using Linux tools and the shell heavily throughout this book, and familiarity with the environment is ideal. * Some scripting knowledge will definitely help but it is not required. Python, JavaScript, and some PHP code will appear throughout this book. * We explore command and control servers in the cloud and it is highly, recommended that a free account on one of the major providers be set up in preparation of following along with the examples in the book. + A virtual machine or host running either Kali or your penetration testing, distribution of choice will help you hit the ground running when trying some of the scenarios in the book. + We routinely download code from open-source projects on GitHub, and while in-depth knowledge of Git will certainly help in this regard, it is not required. Download the example code files You can download the example code files for this book from your account at heep://[Link]. com, If you purchased this book elsewhere, you can visit ntep://[Link]/support and register to have the files emailed directly to you You can download the code files by following these steps: 1. Log in or register at http: //[Link] .com 2. Select the SUPPORT tab, 3. Click on Code Downloads & Errata. 4. Enter the name of the book in the Search box and follow the on-screen structions, Ux]Preface Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of: + WinRAR / 7-Zip for Windows + Zipeg / iZip / UnRarX for Mac + 7-Zip / PeaZip for Linux The code bundle for the book is also hosted on GitHub at hetps: //[Link]/ Packt Publ ish ing/Becoming-the-Hacker. In case there's an update to the code, it will be updated on the existing GitHub repository We also have other code bundles from our rich catalog of books and videos available at https: //github .com/ Packt Publishing/. Check them out! Download the color images We also provide a PDF file that has color images of the screenshots/ diagrams used in this book. You can download it here: Att pe: //[Link]/aites/ default /files/downloads/9781788627962_ColorTmages .pdf Conventions used There are a number of text conventions used throughout t book. codemrext: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. For example; "Mount the downloaded Webst orm-10* .dng disk image file as another disk in your system." A block of code is set as follows: [defauit] exten -> s,1,Dial (Zap/1|30) exten > 8,2, Voicemail (u100) exten => s,102, Voicemail (b100) exten => i,1,Voicemail (so) When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold: [default] exten => s,1,Dial (Zap/1|30) exten => 5,2,Voicemail (u100) exten => 5,102,Voicemail (b100) exten => i,1,Voicemail (so) [x]Preface Any command-line input or output is written as follows: # cp /usr/svc/asterisk-addons/contigs/cdr_mysql.conf sample /eve/asterisk/cdx_mysql.cont Bold: Indicates a new term, an important word, or words that you see on the screen, for example, in menus or dialog, boxes, also appear in the text like this. For example: "Select System info from the Administration panel. [ XX Warnings or important notes appeas like this. ] ‘ [ () Trsentetaarpar tie i ] Get in touch Feedback from our readers is always welcome. General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at customercarea packt pub. con. Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book we would be grateful if you would report this to us. Please visit, http: //[Link] .com/submit -errata, selecting your book, clicking on the Errata Submission Form link, and entering the details. Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at copyright epackt:. com with a link to the material. If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit http: //[Link] pub .com. La]Preface Reviews Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank yout For more information about Packt, please visit packt .com. [ayIntroduction to Attacking Web Applications Web applications are everywhere. They are part of the fabric of society and we depend on them in many aspects of our lives. Nowadays, they are easy to develop, quick to deploy, and accessible by anyone with an internet connection. The technology designed to help develop and deploy web applications has also boomed. New frameworks that enhance functionality and usability are released daily. Companies have shifted power to the developer, allowing them to be more agile and produce web applications quickly. The following figure gives a taste of the more popular development environments and frameworks that have taken the application development world by storm, Node,js has brought the browser client scripting language JavaScript to the server-side, complete with a massive library of modules to aid in fast application development. JavaScript, a once seldom-used scripting language for the browser, is supercharged on the client-side with React and Angular, and is even available for cross-platform development with the likes of Electron and Chromium: jquery 8 METESR Maus @ coe Figure 1.1: The world has changed since Netscape ruled online and this graphic shows buta taste of the fechnolagies that dominate the web today 4)Introduction fo Attacking Web Applications GitHub has become the one-stop shop for open-source libraries, applications, and anything a developer may want to share with the world. Anyone can upload anything they want and others can collaborate by pushing code changes or saving, a dying codebase, by forking it and continuing development locally. GitHub is, not alone, of course, as there are similar repositories for Nodejs, Python, and PHP modules. The developer's focus is always on getting the product shipped, whether it's a simple feature implementation in an internal web application used by the marketing department, or the latest and greatest web banking interface. The infrastructure required to support these applications has also evolved and developers struggle to integrate security into their workflow. It's not always ignorance that hurts secure application development, however. More often than not, time constraints and deadlines are to blame. The goal of this book is to showcase how attackers view web applications and how they take advantage of weaknesses in the application code and infrastructure. We will consider all the common mistakes made during the development process that are used to gain meaningful access. We will look at practical attacks and making the most of common application vulnerabilities. Some assumptions about your knowledge level are made. To get the most value out of reading this book, a basic knowledge of application security should be there. Readers do not have to be experts in the field of penetration testing or application security, but they should have an idea about what cross-site scripting (XSS) or SQL injection (SQL) attacks are. We will not devote a chapter to the standard lello World" example for XSS, but we will show the impact of exploiting such a vulnerability. The reader should also be familiar with the Linux command prompt and common console tools, such as curl, git, and wget. Some familiarity with programming will certainly help, but it is not a hard requirement. In this chapter, we will cover the following topics: + The typical rules of engagement when conducting a test + Thetester's toolkit * Attack proxies + How the cloud can help with engagements [2]Chapter 1 Rules of engagement Before moving forward with the fun stuff, itis important to always remember the rules of engagement (ROE) when conducting an attack. The ROE are typically written out in the pre-engagement statement of work (SoW) and all testers must adhere to them, They outline expectations of the tester and set some limits to what can be done during the engagement. While the goal of a typical penetration test is to simulate an actual attack and find weaknesses in the infrastructure or application, there are many limitations, and with good reason, We cannot go in guns blazing and cause more damage than an actual adversary. The target (client), be they a third party or an internal group, should feel comfortable letting professional hackers hammer away at their applications Communication Good communication is key to a successful engagement. Kickoff and close-out meetings are extremely valuable to both parties involved. The client should be well aware of who is performing the exercise, and how they can reach them, or a backup, in case of an emergency. The kickoff meeting is a chance to go over all aspects of the test, including reviewing the project scope, the criticality of the systems, any credentials that were provided, and contact information. With any luck, all of this information was included in the scoping document. This document's purpose is to clearly outline what parts of the infrastructure or applications are to be tested during the engagement. The scope can be a combination of IP ranges, applications, specific domains, or URLs. This document is usually written with the input of the client, well in advance of the test start date. Things can change, however, and the kickoff is a good time to go over everything one last lime. Useful questions to clarify during the kickoff meeting are as follows: + Has the scope changed list changed? Should certai \ce the document's last revision? Has the target parts of the application or network be avoided? ‘+ Is there a testing window to which you must adhere? + Are the target applications in production or in a development environment? ‘Are they customer-facing or internal only? + Are the emergency contacts still v + Ifcredentials were provided, are they still valid? Now is the time to check these again. + Is there an application firewall that may hinder testing? [3]Introduction fo Attacking Web Applications The goal is generally to test the application and not third-party defenses. Penetration testers have deadlines, while malicious actors do not. When testing an application for vulnerabilities, itis a good idea to ask the client to whitelist out IPs in any third-party web application firewalls (WAFs). WAFs inspect traffic reaching the protected application and will drop requests that match known attack signatures or patterns, Some clients will choose to keep the WAF in an enforcing mode, as their goal may be to simulate a real-world attack. This is when you should remind the clients that firewalls can introduce delays in assessing the actual application, as the tester may have to spend extra time attempting to evade defenses, Further, since there is a time limit to most engagements, the final report may not accurately reflect the security posture of the application, No manager wants to hear that their critical application may go offline during a test, but this does occasionally happen. Some applications cannot handle the increased workload of a simple scan and will failover. Certain, payloads can also break poorly-designed applications or infrastructure, and may bring productivity to a grinding halt. If, during.a test, an application becomes unresponsive, it's a good idea to call the primary contact, informing them of this as soon as possible, especially if the application isa critical production system. If the client, is unavailable by phone, then be sure to send an email alert at minimum. Close-out meetings or post-mortems are also very important. A particularly successful engagement with lots of critical findings may leave the tester feeling great, but the client could be mortified, as they must explain the results to their superiors. This is the time to meet with the client and go over every finding, and explain clearly how the security breach occurred and what could be done to fix it. Keep the audience in mind and convey the concerns in a common language, without assigning blame or ridiculing any parties involved. [4]Chapter 1 Privacy considerations Engagements that involve any kind of social engineering or human interaction, such as phishing exercises, should be carefully handled. A phishing attack attempts to trick a user into following an email link to a credential stealer, or opening a malicious attachment, and some employees may be uncomfortable being used in this manner. Before sending phishing emails, for example, testers should confirm that the client is comfortable with their employees unknowingly participating in the engagement. This should be recorded in writing, usually in the SoW. The kickoff meeting is a good place to synchronize with the client and their expectations Unless there is explicit written permission from the client, avoid the following: + Do not perform social engineering attacks that may be considered immoral, for example, using intelligence gathered about a target's family to entice them to click on a link + Donot exiiltrate medical records or sensitive user data + Do not capture screenshots of a user's machines + Donot replay credentials to a user's personal emails, social media, or other accounts Some web attacks, such as SQLi or XML External Entity (XXE), may 3p¢ lead to data leaks, in which case you should inform the client of the \4 > sulnerability as soon as possible and securely destroy anything already downloaded. While most tests are done under non-disclosure agreements (NDAs), handling, sensitive data should be avoided where possible. There is little reason to hold onto medical records or credit card information after an engagement. In fact, hoarding this data could put the client in breach of regulatory compliance and could also be illegal. This type of data does not usually provide any kind of leverage when attempting to exploit additional applications. When entering proof in the final report, extra care must be taken to ensure that the evidence is sanitized and that it contains only enough context to prove the finding. "Data is a toxic asset. We need to start thinking about if as such, and treat if as we would any other source of toxicity. To do anything else is to risk our security and privacy." ~ Bruce Schneier [5]Introduction fo Attacking Web Applications The preceding quote is generally aimed at companies with questionable practices when it comes to private user data, but it applies to testers as well. We often come across sensitive data in our adventures. Cleaning up A successful penetration test or application assessment will undoubtedly leave many traces of the activity behind. Log entries could show how the intrusion was possible and a shell history file can provide clues as to how the attacker moved laterally. There is a benefit in leaving breadcrumbs behind, however. The defenders, also referred to as the blue team, can analyze the activity during or post-engagement and evaluate the efficacy of their defenses. Log entries provide valuable information on how the attacker was able to bypass the system defenses and execute code, exfiltrate data, or otherwise breach the network. There are many tools to wipe logs post-exploitation, but unless the client has explicitly permitted these actions, this practice should be avoided. There are instances where the blue team may want to test the resilience of their security information and event monitoring (SIEM) infrastructure (a centralized log collection and analysis system), so wiping logs may be in scope, but this should be explicitly allowed in the engagement documents, That being said, there are certain artifacts that should almost always be completely removed from systems or application databases when the engagement has completed. The following artifacts can expose the client to unnecessary risk, even after they've patched the vulnerabilities: + Web shells providing access to the operating system (OS) + Malware droppers, reverse shells, and privilege escalation exploit payloads + Malware in the form of Java applets deployed via Tomcat + Modified or backdoored application or system components: ° Example: overwriting the password binary with a race condition root exploit and not restoring the backup before leaving the system + Stored XSS payloads: this can be more of a nuisance to users on production systems [6]Chapter 1 Not all malware introduced during the test can be removed by the tester. Cleanup requires reaching out to the client. yy Makea note of all malicious files, paths, and payloads used in the assessment. At the end of the engagement, attempt to remove as Q much as possible. If anything is left behind, inform the primary contact, providing details and stressing the importance of removing the artifacts. ss Tagging payloads with a unique keyword can help to identify U_Metelaithetheconepeon ores “Reserve any database records that contain the keyword: 2017Q3 TestXyZ123." A follow-up email confirming that the client has removed any lingering malware or artifacts serves as a reminder and is always appreciated. The tester's toolkit The penetration testing tools used vary from professional to professional. Tools and techniques evolve every day and you have to keep up. While it's nearly impossible to compile an exhaustive list of tools that will cover every scenario, there are some tried-and-true programs, techniques, and environments that will undoubtedly help any attacker to reach their goal. Kali Linux Previously known as BackTrack, Kali Linux has been the Linux distribution of choice for penetration testers for many years. It is hard to argue with its value, as it incorporates almost all of the tools required to do application and network assessments. The Kali Linux team also provides regular updates, keeping not only the OS but also the attack tools current. (7)Introduction to Attacking Web Applications Kali Linux is easy to deploy just about everywhere and it comes in many formats. There are 32-bit and 64-bit variants, portable virtual machine packages, and even a version that runs on the Android OS: Figure 1.2: fresh instance of the Kalt Linux sereen. Kali Linux alternatives One alternative or supplement to Kali Linux is the Penetration Testing Framework (PTF) from the TrustedSec team and it is written in Python. This is a modular framework that allows you to turn the Linux environment of your choice into a penetration testing toolset. There are hundreds of PTF modules. already available, and new ones can be quickly created. PTF can also be run on Kali to quickly organize existing tools in one location. [8]Chapter 1 Figure 1.3: The PTF interactive console Another well-established alternative to Kali Linux is Black Arch, a distribution based on Arch Linux that includes many of the tools bundled with other penetration testing distributions. BlackArch has many of the tools that testers are familiar with for network testing or application assessments, and it is regularly updated, much like Kali Linux. For Arch Linux fans, this is a welcome alternative to the Debian- based Kali distribution. [9]Introduction to Attacking Web Applications Figure 1: The main BlackaArch screen BlackArch is available in many formats on https: //blackarch. org. The attack proxy When testing applications, traffic manipulation and recording is invaluable. The major players in this market are also extendable, allowing the community of researchers to improve functionality with free add-ons. Well-built and supported proxies are powerful weapons in the attacker's arsenal Burp Suite Burp Suite is arguably the king when it comes to attack proxies. It allows you to intercept, change, replay, and record traffic out of the box. Burp Suite is highly extendable, with powerful community plugins that integrate with sqimap (the de facto SQLi exploitation tool), automatically test for privilege escalation, and offer other useful modules: [10]Chapter 1 + Proxy: Record, intercept, and modify requests on the fly * Spider: Content discovery with powerful crawling capabil + Decoder: Unscramble encoded data quickly + Intruder: A highly customizable brute-forcing module + Repeater: Allows the replay of any request previously recorded, with the ability to modify any part of the request itselt + Scanner (pro only): A vulnerability scanner that integrates with Burp Collaborator to find obscure vulnerabilities + Collaborator: Aids in the discovery of obscure vulnerabilities, which would normally be missed by traditional scanners There is a free version of Burp Suite, but the professional edition of the product is well worth the investment. W1 the free version is perfectly usable for quick tests, it does have some limitations. Notably, the Intruder module is time-throttled, making it useless for large payloads. The Scanner module is also only available in the professional version and it is worth the price. Scanner can quickly find low- hanging fruit and even automatically leverage Collaborator to find out-of-band vulnerabilities. The free version can still intercept, inspect, and replay requests, and it can also alert of any vulnerabilities it has passively detected. Burp Suite Free Eaton v7.28. Temporary Project eo0o Ee ee ee | (ee LET Rg [weber sing Ove ee (ees) z wel Peo let em reat FPL z| cceet-roumget omen ee3.2 Figure L5: The main Burp Suite Free Edition screen 1]Introduction fo Attacking Web Applications Zed Attack Proxy OWASP's Zed Attack Proxy (ZAP) is another really great attack proxy. It is extendable and easy to use. However, it lacks some of the features of Burp Suite; for example, ZAP does not have the extensive active vulnerability scanning capabilities of Burp Suite Pro, nor does it have an automated out-of-band vulnerability discovery system comparable to Collaborator. However, there is no time-throttling on ils version of the Intruder module and all of its features are available out of the box. ZAP is open-source and itis actively worked on by hundreds of volunteers. nile Sesion - OWASP ZAP 250 e008 be at Yow arabe weosre 15s ovina > Gmainee ) blim sg? CAS EGS ON a OF Okmmm w (@aea[+] —_ [Pauensine)= ques [reeme [+] eGea 4 [-ac,em | Welcome ta the OWASP Zed Attack Proxy (ZAP) j Brooan coro | 2a isan anys Lee Med peretatentestr toe fortnchy wwal ts hash apt eto. \ @ ster ease se anere tt you sou ory tack ala ons het ah spec 009 ave penis 3 ee, Pattod : f tonya 3e0en | aera [our | +] oO tem Fog Tmastare Netw URL REaSEN Fae $0505 Bu MANES Pe fle Tae al Ante BG NURS Ha Mapa ofenel Suetsan Gc So No Oe Bo po we Figure 1.6:'The main ZAP screen Cloud infrastructure When conducting assessments, it is common for an attacker to leverage command and control (C2) servers during a campaign. The purpose of most C2 servers is to issue commands to malware running inside the compromised environment. (12)Chapter 1 Attackers can instruct malware to exfiltrate data, start a keylogger, execute arbitrary commands or shellcode, and much more. In later chapters, we will primarily use the cloud C2 server to exfiltrate data and to discover vulnerabilities out-of-band. A C2 server, being accessible from anywhere, is versatile in any engagement. The cloud is the perfect location to host C2 infrastructure. It allows quick and programmable deployments that can be accessed from anywhere in the world. Some cloud providers will even support HTTPS, allowing for the quick spin up of a C2 without having to worry about purchasing and managing domains or certificates. The popular choice for penetration testers is Amazon Web Services (AWS), a leader in the cloud space. Its services are fairly inexpensive and it offers an introductory free tier option. Other viable cloud providers include the following + Microsoft Azure: https: //[Link] * Google Cloud Platform: https ://cloud [Link] + Digi + Linode: https: //[Link]..com IOcean: nt tps: / /[Link] Microsoft's Azure has a software as a service (SaaS) free tier feature that lets you deploy C2 automatically from a GitHub repository. It also provides HTTPS support out of the box, making it easier to hide C2 data from prying eyes and enabling it to blend in with normal user traffic. , Always get permission (in writing!) from the cloud provider before es conducting assessments using its infrastructure, even if it's something, as simple as hosting a malicious JavaScript file on a temporary virtual machine. Cloud internet service providers (ISPs) should have a form available for you to fill out that will detail an upcoming penetration test on their infrastructure. A testing window and contact information will likely need to be provided. (13)Introduction fo Attacking Web Applications Whether we are using the cloud to house a C2 for an engagement or attacking, applications hosted in the cloud, we should always notify the client of penetration testing - related activity. Contac (resi) Sutsripson x] sare Tessar Tenet DetedDescipionoffest_[Tsiza detled sanmmay ofthe pater an 000 races mal Actnoweagrent Et asept the tems an condtors Fm not arobot Figure 17: A typical penetration test notification form Resources Consult the following resources for more information on penetration testing tools and techniques: * Penetration Testers Framework (PTF): https: / /github .com/trustedsec/ pet +) BlackArch: nttps://blackarch org * Burp Suite: nt tps://[Link]/burp/ * OWASP ZAP: https: //[Link]/[Link]/OWASP_Zed Attack_ Proxy Project [14]Chapter 1 + Amazon Web Services: nt tps: //aws [Link] * Microsoft Azure: https: //[Link] + Google Cloud Platform: https : //cloud [Link] + DigitalOcean: https : //[Link]. com + Linode: https: //www.1inode. com Exercises Complete the following exercises to get better acquainted with the hacker toolset and the tools welll be using throughout this book: 1. Download and install your preferred penetration testing distribution: Kali or BlackArch, or play around with PTF 2. Use Burp Suite Free or ZAP to intercept, inspect, and modify traffic to your favorite site 3. Create a free account on the cloud computing provider of your choice and use its free tier to launch a Linux virtual machine instance Summary In this chapter, we looked at tools, environments, and the bare minimum ROE we must follow during engagements. We stressed how important communication is and how critical it is to consider client privacy while testing. We are not the bad guys and we cannot operate with impunity. We've also gone over the clean - up process and it is vital that we leave no artifacts, unless otherwise requested by the client. Our leftover shells should not be the feature of a future breach. We've also covered the penetration tester’s toolkit; an all-in-one Linux distribution, Kali; and a couple of its alternatives. The more important piece to a web application hacker's toolkit is arguably the attack proxy, two of which we've highlighted: Burp Suite and ZAP. Finally, we've mentioned the cloud as an emerging useful tool for the web application tester The attacker's job will always be easier than that of the defender. Any professional hacker with experience in the corporate world will attest to this. The attacker needs just one weak link in the chain — even if that weakness is temporary — to own the environment completely. (15)Introduction fo Attacking Web Applications Security is difficult to do right the first time and it is even more difficult to keep it close to the baseline as time passes. There are often resourcing issues, lack of knowledge, or wrong priorities, including simply making the organization profitable, Applications have to be useable — they must be available and provide feature enhancements to be useful. There never seems to be enough time to test the code properly, let alone to test it for security bugs. Staff turnover can also lead to inexperienced developers shipping insufficiently- tested code. The security team is often stretched thin with daily incidents, let alone having the time to be bothered with secure code reviews. There is no silver bullet for security testing applications and there is rarely enough money in the budget. There are many pieces to this puzzle and many factors that act against a completely secure application and underlying infrastructure. This is where the professional hacker, who understands these limitations, can shine. With shell access to a server, one can search for a potential privilege escalation exploit, try to get it working, and, after some trial and error, gain full access, Alternatively, one could take advantage of the fact that inter-server communication isa common sysadmin requirement. This means that connections between servers are either passwordless, or that the password is improperly stored somewhere close by. It's not uncommon to find unprotected private keys in globally-readable directories, allowing access to every other server in the infrastructure. Secure Shell (SSH) private keys, frequently used in automating SSH connections, are not password protected because password protecting a private key will break the automation script that is using it. In upcoming chapters, we will use these unfortunate truths about application development and deployment to our advantage. [16]Efficient Discovery Content discovery and information gathering are typically the first steps when attacking an application. The goal is to figure out as much as possible about the application in the quickest manner possible. Time is a luxury we don't have and we must make the most of our limited resources. Efficiency can also help us to remain a bit quieter when attacking applications. Smart wordlists will reduce the number of requests we make to the server and return results faster. This isn'ta silver bullet, but it’s a good place to start. In this chapter, we will cover the following topics: + The different types of penetration testing engagements + Target mapping with various network and web scanners + Efficient brute-forcing techniques + Polyglot payloads Types of assessments Depending on the agreement with the client prior to the engagement, you may have some of the information required, a lot of information, or no information whatsoever. White-box testing allows for a thorough examination of the application. In this, case, the attackers have essentially the same access as the developer. They not only have authenticated access to the application, but also its source code, any design documents, and anything else they'll need. 17)Efficient Discovery White-box testing is typically conducted by internal teams and it is fairly time- consuming. A tester is provided with any information they require to fully assess the application or infrastructure. The benefit of providing testers with this level of knowledge is that they will be able to look at every bit of an application and check for vulnerabilities. This is a luxury that external attackers do not have, but it does make efficient use of limited time and resources during an engagement. Gray-box scenarios are more common, as they provide just enough information to let the testers get right into probing the application. A client may provide credentials and a bit of information on the design of the infrastructure or application, but not much more, The idea here is that the client assumes that a malicious actor already has a certain level of access or knowledge, and the client needs to understand how much more damage can be done. Finally, black-box testing will simulate an attack from the perspective of an outsider without any knowledge of the application or infrastructure. Companies that expose applications to the internet are subjected to constant attack by external threats. While itis important to remember that not all malicious actors are external, as disgruntled employees can cause just as much damage, malicious black-box type attacks are fairly common and can be very damaging, The following is a breakdown of the three common types of application penetration tests: White-box Gray-box Black-box ‘Attacker has access to ‘Some information Zero knowledge. all information required. isavailable. Testing with the highest _| Testing from the perspective | Testing from the perspective privilege, that is, with of a threat that already has | of an external threat. developer knowledge. acertain level of access or knowledge. ‘Typical information Provides the attacker No information is provided available includes with some information: up-frontand the attacker the following; © User accounts must gather everything they * User accounts need through open-source * High-level intelligence (OSINT) or + Source code documentation vulnerabilities that lead + Infrastructure ‘The attacker will to information leakage. design documents usually not have access to the source code, or other sensitive information + Directory listing [18]Chapter 2 [ Target mapping The traditional nmap of the entire port range, with service discovery, is always a good place to start when gathering information on a target. Nmap is the network scanning tool of choice and has been for many years. It is still very powerful and very relevant. It is available on most platforms, including Kali, BlackArch, and even Windows. ~_ For the remainder of this book, we will approach our targets from ~ a more gray-box perspective, simulating the typical engagement. Metasploit Framework (MSF) is a penetration testing framework commonly used by security professionals. Besides being a fantastic collection of easy-to-deliver exploits, it can also help to organize engagements. For target mapping specifically, you can leverage the workspace feature and neatly store your Nmap scan results ina database. If the Kali Linux instance is fresh or Metasploit was recently installed, the database may need a kick to get it going. In the Kali console prompt, start the PostgreSQL service using the sezvice command. If successful, there should be no message returned. roct@kali:-# service postgresql start rootekali:-# Metasploit can then be started using the metconsole command, which will drop us into a sub-prompt, prefixed with met instead of the traditional bash prompt reotekali:~# msfconsole tea msf > db status [*] postgresql selected, no connection The preceding series of commands will start the PostgreSQL database service, which Metasploit uses for storage. The Metasploit console is launched and we can check the database status using MSF's db_status command. We can use the exit command to return to the bash terminal: mst > exit reotekali:~# (1s)Efficient Discovery We can now use the Metasploit ms£a> command to help us initialize (init) the database: rootékali:-# msfdb init Creating database user ‘msf! Enter password for new role Enter it again Creating databases 'msf' and 'msf_test' Creating configuration file in /usr /share/metasploi t- framework/config/databa: Creating initial database schema root@kali:~# The ms£d> command creates all of the necessary configuration files for Metasploit to be able to connect to the database. Once again, we can start the Metasploit console using the mefconsole command in the Linux prompt: rootakali:- mefconsole tea ‘The YML database configuration file, created with the msfab init command, can be passed to the db_connect Metasploit console command as with the -y switch: ms » db connect -y /usr/share/nmetasploit-framework/config/[Link] [*] Rebuilding the module cache in the background mst > db status [*] postgresql connected to maf We can now create a workspace for the target application, which will help us to organize results from various MSF modules, scans, or exploits: maf > workepace -a targetl [+] Added workspace: targeti msi > workspace default * targeti The workspace command without any parameters will list the available workspaces, marking the active one with an asterisk. At this point, we can start an Nmap scan from within MSE. The d_nnap MSF command is a wrapper for the Nmap scanning, tool. The difference is that the results of the scan are parsed and stored inside the Metasploit database for easy browsing. [20]Chapter 2 MSF's db_nmap takes the same switches as the normal anap. In the following example, we are scanning for common ports and interrogating running services. The target for this scan is an internal host, [Link], We are instructing Nmap to perform a service scan (-s¥) without pinging hosts (-P2), and using verbose output (-v) maf > db nmap -aV -Pn -v [Link] tea [*] Nmap: Scanning [Link] [1000 ports) [+] Nmap: Discovered open port 3389/tcp on [Link] [4] Nmap: Discovered open port $257/tep on [Link] [+] Nmap: completed SYN Stealth Scan at 19:50, 12.05s elapsed (1000 total ports) [+] Nmap: Initiating Service scan at 19:50 tea Once the scan completes, the results can be queried and filtered using the sexvices command. For example, we can look for all HTTP services discovered by using the h -s swi maf > services -s http Services port proto name state info [Link] 5357 tep http open Microsoft HTTPAPI httpd 2.0 SSDP/UPnP , Take note of the scope provided by the client, Some will specifically 2, (constrain application testing to one port, or sometimes even only 2 one subdomain or URL. The scoping call is where the client should bbe urged not to limit the attack surface available to the tester. Masscan Nmap is fully featured, with a ton of options and capabilities, but there is one problem: speed. For large network segments, Nmap can be very slow and sometimes can fail altogether. It's not unusual for clients to request a penetration test ona huge IP space with little time allotted for the mapping and scanning phase. [21]Efficient Discovery The claim to fame of masscan is that it can scan the internet IP space in about six minutes. This is an impressive feat and it is certainly one of the fastest port scanners out there. During an engagement, we may wish to target web applications first and masscan can quickly return all open web ports with just a couple of switches. The familiar ~p switch can be used to specify a series, or range, of ports to look for. The --banne ch will attempt to retrieve some information about any open ports that are discovered. For larger IP spaces, where time is of the essence, we can use the rate switch to specify a large packet per second number, such as a million or more: SSW ae ererrare rarer) Figure 21: A masscan of the 10.0.00/8 network We can see that the preceding scan was cancelled early with the Ctrl + C interrupt, and masscan saved its progress in a paused .conf file, allowing us to resume the scan at a later time. To p passing the paused. coné file as the parameter: k up where we left off, we can use the --resume switch, [22]Chapter 2 Figure 22: Resuming a masican session Masscan's results can then be fed into either Nmap for further processing, or a web scanner for more in-depth vulnerability discovery WhatWeb Once we've identified one or more web applications in the target environment with masscan or Nmap, we can start digging a bit deeper. WhatWeb is a simple, yet effective, tool that can look at a particular web application and identity what technologies have been used to develop and run it. Ithas more than 1,000 plugins, which can passively identify everything from what content management system (CMS) is running on the application, to what version of Apache or NGINX is powering the whole thing. The following diagram shows a more aggressive (-a 2) scan of bittherapy net with WhatWeb, The sea command shown will format the output to something a bit easier to read. Figure 23: Running WhatWeb and filtering the results [23]Efficient Discovery A level-3 aggression scan will perform several more requests to help to improve the accuracy of results. WhatWebis available on Kali Linux and most other penetration testing distributions. It can also be downloaded from https: //github .con/urbanadventurer /WhatWeb Nikto Nikto provides value during the initial phases of the engagement. It is fairly non-intrusive and with its built-in plugins, it can provide quick insight into the application. It also offers some more aggressive scanning features that may yield success on older applications or infrastructure If the engagement does not require the attackers to be particularly stealthy, it doesn't hurt to run through the noisier Nikto options as well. Nikto can guess subdomains, report on unusual headers, and check the robots .txct file for interesting information: Figure 24: A standard scan of the examplecom domain Nikto outputs information on the HTTPS certificate, the server banner, any security- related HTTP headers that may be missing, and any other information that may be of interest. It also noticed that the server banner had changed between requests, indicating that a WAF may be configured to protect the application [24]Chapter 2 Nikto can be downloaded from https : //github. com/sullo/nikte. Itis also available in most penetration testing-focused Linux distributions, such as Kali or BlackAreh. CMS scanners When the target is using a CMS, such as Joomla, Drupal, or WordPress, running an automated vulnerability testing tool should be your next step. WordPress is a popular CMS because it provides plugins for almost any type of site, making it very customizable and widely-adopted, but also complex, with a large attack surface. There are tons of vulnerable plugins, and users typically don't upgrade them frequently. Duringa test, you may find a remotely exploitable vulnerability in one of the plugins that provides a shell, but more often than not, WordPress is a treasure trove of information. Usernames can be enumerated, passwords are often weak and easily brute-forced, or directory indexing may be enabled. The WordPress content folder sometimes also contains sensitive documents uploaded "temporarily" by the administrator. In later chapters, we will see how an improperly configured WordPress instance can be leveraged to attack the application server and move laterally through the network WordPress is not alone in this space. Joomla and Drupal are also very popular and sport many of the same vulnerabilities and configuration issues that are seen in WordPress installations. There are a few scanners available for free that aim to test for low-hanging fruit in these CMSs: + WPSean (nttps: //upscan. org/): A powerful tool aimed at tesi WordPress installations ng * JoomScan (nt tps: //github .com/rezasp/joomscan): As the name implies, a CMS scanner specializing in Joomla testing + droopescan (at tps: / /github. com/droope /dzcopescan): A Drupal-specilic scanner with some support for Joomla + CMSmap (nttps: //[Link]/Dionach/Cusmap): A more generic scanner and brute-forcer supporting WordPress, Joomla, and Drupal [25]Efficient Discovery inside the engagement scope. Some CMS implementations will host the core site locally, but the plugins or content directories are on a separate content delivery network (CDN). These CDN hosts may be subject toa penetration testing notification form before they can be included Before proceeding with a WordPress scan, make sure that itis hosted ‘ in the test, We cover CMS assessment tools, such as WPScan, in more detail in later chapters. Efficient brute-forcing A brute-force attack typically involves a barrage of requests, or guesses, to gain access or reveal information that may be otherwise hidden. We may brute-force a login form on an administrative panel in order to look for commonly used passwords or usernames. We may also brute-force a web application's root directory looking for common misconfiguration and misplaced sensitive files. Many successful engagements were made so by weak credentials or application misconfiguration, Brute-forcing can help to reveal information that may have been obscured, or can grant access to a database because the developer forgot to change the default credentials. There are obvious challenges to brute-forcing. Primarily, it is time-consuming and ean be very noisy. Brute-forcing a web service, for example, with the infamous [Link] wordlist will no doubt wake up your friendly neighborhood security operations center (SOC) analyst and may put an end to your activities early. The rockyou. txt list has over 14 million entries and could eventually result in a successful credential guess, but it may be better to limit the flood of traffic to the target with a smaller, more efficient list One of the better collections of common keywords, credentials, directories, payloads, and even webshells is the SecLists repository: https: //[Link]/ danielniessler/SecLists. _ _Analterative, or supplement, to SecLists is FuzzDB. [tis a similar <4 collection of files containing various payloads that can help with >> brute-forcing, and it can also be downloaded from the GitHub repository at https: //[Link]/fuzzdb-project /fuzzdb, [26]Chapter 2 Grabbing the latest copy of SecLists is easy using git, a popular version control system tool. We can pull down the repository using the git. clone command: root@kali:~/toole# git clone httpa: //[Link]/danielmiessler/Sectists SecLists contains an ever-evolving database of compiled wordlists that can be used in discovery scans, brute-force attacks, and much more: SecList Wordlist Description Discovery Web content, DNS, and common Nmap ports Fuzaing FuzzDB, Brutelogic, Polyglot payloads, and more rocs Malware-related indicators of compromise Miscellaneous Various wordlists that may have obscure uses Passwords Large numbers of wordlists for common passwords, split into top-N files Pattern-Matching Wondlists for use when "grepping” for interesting, information Payloads Webshells for common languages, Windows Netcat, and an FICAR test file Usernames Lists of common names and login IDs The security community is a frequent contributor to SecLists, and it is good practice to pull the latest changes from GitHub before starting an engagement. Hopefully, target mapping has already provided a few key pieces of information that can help you to brute-force more efficiently. While Nikto and Nmap may not always find a quick and easy remote code execution vulnerability, they do return data that can be useful when deciding what wordlist to use for discovery. Useful information can include the following: + The webserver software: Apache, NGINX, or IIS + Server-side development language: [Link], PHP, or Java + Underlying operating system: Linux, Windows, or embedded + [Link] + Interesting response headers + WAF detection: F5 or Akamai (27)Efficient Discovery You can make assumptions about the application based on the very simple information shown in the preceding list. For example, an IIS web server is more likely to have an application developed in [Link] as opposed to PHP. While PHP is still available on Windows (via XAMPP), it is not as commonly encountered in production environments, In contrast, while there are Active Server Pages (ASP) processors on Linux systems, PHP or Nodejs are much more common these days. While brute-forcing for files, you can take this into account when attaching the extension to the payload: .asp and .aspx for Windows targets, and .php for Linux targets is a good start. The robots .txt file is generally interesting, as it can provide "hidden* directories or files, and can be a good starting point when brute-forcing for directories or files. The [Link] file essentially provides instructions for legitimate crawler bots on what they're allowed to index and what they should ignore. This is a convenient way to implement this protocol, but it has the implication that this file must be readable by anonymous users, including yourself. Assample robot [Link] file will look something like this: User-agent: * Disallow: /cgi-bin/ Disallow: /test/ Disallow: /-admin/ Google's crawlers will ignore the subdirectories, but you cannot. This is valuable information for the upcoming scans. Content discovery We have already mentioned two tools that are very useful for initial discovery scans: OWASP ZAP and Burp Suite. Burp's Intruder module is throttled in the free version but can still be useful for quick checks. Both of these attack proxies are available in Kali Linux and can be easily downloaded for other distributions. There are other command-line alternatives, such as Gobuster, which can be used to automate the process a bit more. Burp Suite As mentioned, Burp Suite comes bundled with the Intruder module, which allows us to easily perform content discovery. We can leverage it to look for hidden directories and files, and even guess credentials. It supports payload processing and encoding, which enables us to customize our scanning to better interface with the target application. [28]Chapter 2 In the Intruder module, you can leverage the same wordlists provided by SecLists and can even combine multiple lists into one attack. This is a powerful module with lots of features, including, but not limited to, the following: + Cluster bomb attack, which is well suited for multiple payloads, such as usernames and passwords, which we will showcase later + Payload processing for highly customized attacks + Allack throttling and variable delays for low and slow attacks + ...and much more! We will cover these and others in later chapters. [poston [rome Lene] sdsate dpe on te anc ype ned nb patenteer @ BB topeatcane 30, ovens (sin at BH temstcone 198, 2) Payload Options (simple ist] Tis ond pets eu cee asin otf tings that ese a ade Care) tenet Cena yeantane loa) wens ee fern) Ger) * Figure2.5: The Burp Suite Intruder module Payloads screen The free version of Burp Suite is readily available in Kali Linux but, as we've noted in the preceding chapter, it is a bit limited. There are some restrictions in the Intruder module, notably the time-throttling of attack connections. For large payload counts, this may become a hindrance. The professional version of Burp Suite is highly recommended for those who test applications regularly. Burp Suite is also valuable when reverse engineering applications or protocols. It is quite common for modern applications or malware to communicate with external servers via HTTP. Intercepting, modifying, and replaying this traffic can be valuable. [28]Efficient Discovery OWASP ZAP The free alternative to Burp Suite is ZAP, a powerful tool in its own right, and it provides some of the discovery capabilities of Burp Suite. The ZAP equivalent for Burp's Intruder is the Fuzzer module, and it has similar functionality, as show in the following figure: Funer ° [fraztvaione Loris | nasage newt] e00y Tug) Jad aoc | eccsivale sara seh 8 Paes. Le | Reset_( stat hase Figure 2.6: OWASP ZAP's Fuzzer module configuration. As ZAP is open-source, there arenousage restrictions. Ifthe goal is to perform a quick content discovery scan of credential brute-force, it may be a better alternative to the free version of Burp Sut. Gobuster Gobuster is an efficient command-line utility for content discovery. Gobuster does not come preinstalled on Kali Linux, but it is available on GitHub. As its name implies, Gobuster was written in the Go language and will require the golang compiler to be installed before it can be used for an attack. [30]Chapter 2 The steps to configure Gobuster are fairly easy on Kali Linux, We can start by issuing the following command: root@kali:-# apt-get install golang The preceding command will globally install the Go compiler. This is required to build the latest version of Gobuster. Next, you need to make sure that the CoPATH and COB IN environment variables are set properly. We will point CoPATE to a go directory in our home path and set coBIN to the newly defined cozarH value: root@kali:-# export GOPATH=-/go rootekali:-# export GOBIN=$GOPATE We can now pull the latest ver command: n of Gobuster from GitHub using the git clone rootekali:~/tools# git clone https: //[Link]/oJ/gobuster Cloning inte ‘gobuster' tel We can then get dependencies, and compile the Gobuster application. The go get and go build commands will generate the Gobuster binary in the local directory: roct@kali:~/tools/gobuster# go get && go build If the commands don't produce output, the tool was compiled and is ready for use: root@kali:~/tools/gobuster# ./gobuster Gobuster vi.3 03 Reeves (@TheCcolonial) [1] Wordiist (-w): Must be specified (1) Ur1/Domain (-u) Must be specified rootekali:~/tools/gobuster# Gobuster has many useful features, including attacking through a proxy (such asa local Burp Suite instance), outputting to a file for further processing, or even. brute-forcing subdirectories for a target domain. [31]Efficient Discovery The following figure shows Gobuster performing a discovery scan on the neep://[Link] using a common web content file from the SecLists repository: rE eee oe Sian CeeS? Enea 7: Sample Gobuster running on the [Link] server A command-line URL discovery tool may prove useful on systems where we cannot runa full-blown graphical user interface (GUI) application, such as Burp or ZAP. Persistent content discovery The results of a particular scan can reveal interesting directories, but they're not always accessible, and directory indexing is increasingly rare in applications, Thankfully, by using content discovery scans we can look into directories for other misconfigured sensitive information. Consider a scenario where the application hosted on http: //[Link]/ contains a particular directory that may be password protected. A common misconfiguration in applications is to protect the parent directory but incorrectly assume all subdirectories are also protected. This leads developers to drop more sensitive directories in the parent and leave them be. Earlier inspection of the robot s..txt file revealed a few interesting directories: Disallow: /cgi-bin/ Disallow: /test/ Disallow: /-admin/ [32]Chapter 2 The aamin directory catches the eye, but atlempting to access /-admin/ returns an HTTP 402 Forbidden error: JB Access raticten €)9) 0 1005381 @ ][a sear reaotn = aMost Visited 7 BHlOrensie Security “Kal Linx “\RaiDocs “Kali Tools MREXpIOt-DB WW Aicrack-ng Access forbidden! You don't have permission to access the requested directory. There is either no index document or the directory is read-protected, Ifyou think ths sa server error, please contact the webmaster Error 403 [Link] Apaches? 4.26 (HIn32) OpenSSL. 021 PHPA.6:31 Figure 2.8: Access to the directory is forbidden This may be discouraging, but we can't stop here. The target directory is too attractive to give up now. Using OWASP ZAP, we can start a new Fuzzer activity on this directory and see if we can find anything of interest that is not protected. [33]Efficient Discovery Make sure that the cursor is placed at the end of the URL in the left-most pane. Click the Add button next to Fuzz Locations in the right-most pane: Fuser ° aptora [Menage rocesors (@ Rerove without eorfimaton L@ enced Reset |) tet Fuzer Figure 2.9: Fuzzer configuration, adding Fuzz Locations On the next screen, we can add a new payload to feed the Fuzzer. We will select the vaft-small-files txt wordlist from the SecLists repository: [34]Chapter 2 ‘Add Payload oe ype: er Tar iron, ert lero chara tacng (US ‘mt: CJ ave 000 ‘nore Enel nes: gro Ft ine Payoads Preven: eon she Scorch pnp ) eon hp iene Fepeahe fetal poe mentee en coe eat ase. cea) [a4] Figure 2.10: Fuzzer configuration - the Add Payload sezeen Since we want to treat the /~aénin URI as a directory and look for files within, we will have to use a string processor for the selected payload. This will be a simple Prefix String processor, which will prepend a forward-slash to each entry in our list. ‘sa Processor ° Maes SSS ‘cureneFayiads recessed Paloads edecpre 4 irsexsne a Seach earn ahp ene Teronphe ‘caret fear Teeter Rewees vetalpro esate pale frente Rerbert php frond tp reerane Ireaterpn haonetote oneisota sta pga ot Ista pace fener cancel) | aa) Figure2.11: Fuzzer configuration - the Add Processor screen [38]Efficient Discovery The Fuzzer task may take a while to complete, and it will produce lots of 403 or 404 errors. In this case, we were able to locate a somewhat hidden administration file. = Sean = T gamertane a tomes orm ge Bo vo 9s HI 7s wd Figure 212: The completed Fuzzer scan shows an accessible hidden file The HTTP 200 response indicates that we have access to this file, even though the parent directory /~admin/ was inaccessible. It appears we have access to the adnin. html file contained within the enticing admin directory. Application security is hard to implement correctly, and it is even harder to maintain that initial security baseline as the application ages and evolves, and staff rotate. Access is granted and not removed; files are added broken pert ms; and underlying operating systems and frameworks become outdated, and remotely exploitable. When running initial content discovery scans, it is important to remember not to stop. at the first error message we see. Access control deficiencies are very common, and we could uncover various unprotected subdirectories or files if we are persistent. Payload processing Burp Suite's Intruder module is a powerful ally to an attacker when targeting web applications. Earlier discovery scans have identified the secretive, but enticing, /~admin/ directory. A subsequent scan of the directory itself uncovered an unprotected admin. html file. Before we proceed, we will switch to the Burp Suite attack proxy and configure the Target Scope to the vuln. app. Local domain: [36]Chapter 2 Ticenvers [ender @aseronn [aaerantons Ana Ota aereert Figure 2.13: The Burp Suite Target Scope configuration screen The Target Scope allow’ us to define hosts, ports, or URLs that are to be induded. in the scope of the attack. This helps to filter out traffic that may not be related to our target. With Burp Suite configured as our attack proxy, we can visit the hidden admin. html URL and record the traffic in our proxy's history: Morita Firefox - ax (EB [Link] 9 \ ot €)> © | vulr-apptocaladminladmin. htm ¢ | [ Search wor» = Server Connectivity Test [vuin app. local/car-binvtest ca) Figure 2.14: Accessing the hidden file through the browser succeeds [37]Efficient Discovery Following the Server Connectivity Test link, we are greeted with a basic authentication realm Admin Tools, as shown here: Bo age an eee ere green arene sere User Nae: Paccuet caret Figure 2.15: Authentication popup when attempting to follow the link Our pentester reflexes kick in and we automatically type in the unfortunately ‘common admin /adnin credentials, but with no luck this time. Since all of the interactions with the target are being recorded by the Burp proxy, ‘we can simply pass the failed request on to the Intruder module, as shown in the following figure. Intruder will let us attack the basic authentication mechanism with little effort: [28]Chapter 2 [terme [arom Soe [Serrer [rrerRepeoer [Seamer [es [Lasers [oe se [votes Nay [ Oona [eemnrer [etree [Promtemters [Urersore [aes | a Ser agines Heestis7S.0 (dL) Lanse 935 £4 e289) eteren hetero sin bpp tects-adniv/ady| Ce elven ae BBG Fete] tres eae ———_—_——.. Figure 2.16; The HTTP history sereen In the Intruder module, the defaults are good for the most part—we just have to select the Base64-encoded credentials portion of the Authorization header and click the Add button on the right-hand side. This will identify this position in the HTTP request as the payload location. The following shows the payload position selected in the Authorization header: (ine [rs [emis [oe] @ Payload Positions oh pntn es pane ere erg hei crn apn sstceiee: (See * = , ; 7] (ana Rime MEFs aay as CSRs Ce: SRS sets (itech Figure2.17; Specifying a payload position in the Authorization header [38]Efficient Discovery In the Payloads tab, we will select the Custom iterator payload type from the dropdown, as seen in the following figure: = See pe [eee reo “wa: | roavore [Poon overs] ‘ae banner ete ensatemmnsfemeeyms monty tate dish Figure 2.18: Configuring the Payload type The authorizat ion header contains the Base64-encoded plaintext values of the colon-separated username and password. To brute-force the application effectively, the payload will have to be in the same format. We will need to submit a payload that follows the same format that the Authori zation header expects. For each brute-force request that the attack proxy will make, the payload will have to be the username and password separated by a colon, and wrapped by Base64 encoding: bases4 ( [user_payload] : [password_payload] }. [40]Chapter 2 We can grab the already captured value in the Aut hori zation header and pass it to Burp Suite's Decoder module. Decoder allows us to quickly process strings to and from various encoding schemes, such as Base64, URL encoding, GZip, and others. This figure shows how we can leverage Decoder to convert the value ywRaWa ywRtan4= from Base64 using the Decode as... dropdown. The result is listed in the bottom pane as admin :admin: a a ee tirana @ tet One B adiricadrnn (Heer is) (Usman decide Figure 2.19: The Burp Decoder screen Back in the Intruder module, for payload position 1, we will once again use a small wordlist from the SecLists Usernames collection called top-useznanes-short list. ext. Our goal is to find low-hanging fruit, while minimizing the flood of requests that will hit the application. Using a short list of common high-value usernames is a good first step. [41]Efficient Discovery This figure shows that the list was loaded in payload position 1 using the Load... button in the Payload Options: rex [saver sarer [ana owt sone [veoae [comsorer [ender [erasore [vee optone Aer mL [restim [retain one] la) Payload Options (Custom iterator] voster-[I) (cea | é a rt scenes: Gnesamnaei ane Figure 2.20: Payload position 1 configuration screen The separator for position 1 should be colon (;). For payload position 2, you can use the 500-worst -passwords .ext list from the SecL ists passwords directory. The following figure shows payload position 2 containing the loaded 500-worst - passwords .txt contents: [42]Chapter 2 tore | rows |sexre" J mae [ncneer [semencer [ueceer [moar Leasrer [rsesccters | ver sens [ates | ae tt [onsrs apie eo | Payload options Lcustem erator i Figure 221: Payload position 2 configuration screen The separator for position 2 should be left blank. At this point, each request sent to the application will contain an Authorization header in the following format: Authorization: Basic admin:admin Authorization: Basic admin:test Lal Authorization: Basic root :secret Authorization: Basic root :password To complete the payload, we also have to instruct Intruder to Base64-encode the payload before sending it over the wire. We can use a payload processor to force Base64 encoding for every request. [43]Efficient Discovery In the Payloads tab, under Payload Processing, click Add and select the Base64- encode processor from the Encode category. We will also disable automatic URL encoding, as it may break the Authorization header. The following URL shows the enabled Base64-encode processor: ee aa] RR Re | ete cede | na [snc | roa ar | Fa © Pavead processing BF isrnsrws 1 Ener he dete ete mond prec (2) Payload Encoding vavercnde mass tater ees HE Figure 2.22: Payload processing tule ~ Basob-encexle Once the payload has been configured, we can begin the brute-force using the Start Attack button in the top-right corner of the Intruder module, as shown in the following figure: mmtotor Beet Figure 2.23: Starting the attack [44]Chapter 2 As with the content discovery scan, this credential brute-force will generate a fair amount of HTTP 401 errors. If we're lucky, at least one will be successful, as seen in the figure that follows: Fine] tet] restore | rerknds | opto] ter snenng aller Raat Pood Sian ale T al ia mawiecene =e : jm OO ie S enoatooapay= @ OG las 2 Somanomsious m@ 0 Oise 3 Moewouans @ 9 ie { Seaeamuvaue @ 5 Oise 3 Reseesnnar= m@ 3 Ole = Semontouteen mie + owen em OO ie 8 eigen 5 ie 5 Smoupemyraemnon= eae to Naivavonyeconee wi Bie ic [rosa J nesoran] cnt [ox [10H | ode sate) 4.36 tint) Spe... Pes aL ecemtish cone fomesinnt typetect cnehast-siittypeaimt walter /fome Figure 2.24: Attack results screen, Now, because every request in the Intruder attack is recorded, we can inspect each one or sort all of them by column to better illustrate the results of the attack. In the preceding example, we can clearly see that the successful authentication request returned an HTTP status code of 200, while the majority of the other requests returned an expected 401. The status code is not the only way to determine success at a quick glance, however. A deviation in the content length of the response may bea good indicator that we are on the right track. Now that we have a payload that has successfully gained access to the Admin Tools authentication realm, we can run it through the Decoder module to see the plaintext credentials. [45]Efficient Discovery This figure shows the Decoder module revealing the guessed credentials: [Sean rer een arene ee earl eave Comer el “toon epters [art] Figure 2.25: Burp Suite Decoder Credential brute-forcing is just one of the many uses for Intruder. You can get creative with custom payloads and payload processing, Consider a scenario where the vuln. app. Loca application generates PDF files with sensitive information and stores them in an unprotected directory called /pat/. The filenames appear to be the MDS digest of the date the file was generated, but the application will not generate a PDF file every day. You could try and guess each day manually, but that's not ideal. You can even spend some time whipping up a Python script that can automate this task. The better alternative is to leverage Burp Suite to do this easily with a few clicks, This has the added benefit of recording the attack responses in one window for easy inspection, [46]Chapter 2 Once again, we can send a previously recorded request to the target /pa#/ folder directly to the Intruder module. This figure shows that the PDF's name, minus the extension, is identified as the payload position using the Add button: Jrevdor [nerves [Seamer | sestr | coorer [etner [rst opts | sorentane [ite | “raat [esane Baines [one] (@ Payload Postion: amare Oe 7] os attend esntcapgtientaer at neh Stare (Cos) Se oo Figure 2.26: Intrucler Payload Positions configuration screen (47)Efficient Discovery The following figure shows the Dates payload type options available in Intruder: [Fare [renner] Ontone | @ Payload Sets aT ‘Yeuean defo ene o rota vaload sate. ha numberof paoad sue depan een tha attack Spe daa the Presteratas Varina goylodtypa ave arabs foreach payload ast, and nah ppoad tye cn be fistemedin ferent wae pelont st: (ZR) esdcure 2.008 relent ss (Dates) a avet cure: 2.008 @ Payload options (pates] Thi eed ts aaa dite ease within a iv rangs sein zai Frat from: | (mags) to (E(u =) ma step T | (Bam + tema Q (ena? is) © earned ® Payload Processing ‘euler define rules to perform vious processing tks on each payed before usd erable Daa HOE Figure 2.27: Intruder's Payloads sereen In this attack, you will use the Dates payload type with the proper date format, going back a couple of years. The payload processor will be the MD5 hash generator, which will generate a hash of each date and return the equivalent string. This is similar to our Base64-encode processor from the previous attack. Once again, the payload options have been configured and we can start the attack. The following figure shows a few requests with the 200 HTTP status code and a large length indicating a PDF file is available for download: [48]Chapter 2 Intruder attack 3 oo°0 | fmemtn|teost | renitra [Peven [one] Tier sheingal tems Bl ecner Tiree. Lewh | Gomment vibe 2 Semroiviammecesesel. tot be 3 Wrosraseiseaceace7sos7.. a4 Be ‘ awcassieenovestene. ot a ‘ ZsaovietewdTosztd Hot ue [er-agene: moait a5. 203; Lim x84 r45.0) cackoromomsd Firefoxs5. 9 Incest test Ital apt ientson/ sheet al anal ieerion ee 9,87 Figure 2.28: Intrucler attack Results sereen Intruder will generate the payload list based on our specified date format and calculate the hash of the string, before sending it to the application, all with a few clicks. Inno time, we have discovered at least three improperly protected, potentially sensitive documents that are available anonymously. Polyglot payloads A polyglot payload is defined as a piece of code that can be executed in multiple contexts in the application. These types of payloads are popular with attackers because they can quickly test an application's input controls for any weaknesses, with minimal noise. [4s]Efficient Discovery Ina complex application, user input can travel through many checkpoints—from the URL through a filter, into a database, and back out to a decoder, before being displayed to the user, as illustrated in the following figure: Figure 2.29: Typical data flow from user to application, Any one of the steps along the way can alter or block the payload, which may make it more difficult to confirm the existence of a vulnerability in the application A polyglot payload will attempt to exploit an injection vulnerability by combining multiple methods for executing code in the same stream. This attempts to exploit weaknesses in the application payload filtering, increasing the chance that at least. one portion of the code will be missed and will execute successfully. This is made possible by the fact that JavaScript is a very forgiving language. Browsers have always been an easy barrier of entry for developers, and JavaScript is rooted in a similar philosophy. The OWASP cross-site scripting (XSS) Filter Evasion Cheat Sheet contains examples of polyglot payloads, which can also evade some application filters: https: //www. [Link]/[Link]/xSS_Filter_Evasion Cheat_sheet. A good example of a strong polyglot payload can be found on GitHub from researcher Ahmed Elsobky: Javascript: /*-/4' /*\"/4! /an/ee/(/* */olclick=alert () } / /ODWAKOdB0a//\x3ceVa/\x3e [so]Chapter 2 At first glance, this appears rather messy, but every character has a purpose. This payload was designed to execute JavaScript in a variety of contexts, whether the code is reflected inside an HTML tag or right in the middle of another piece of JavaScript. ‘The browser's HTML and JavaScript parsers are extremely accommodating. They are case-insensitive, error-friendly, and they don't care much about indenting, line endings, or spacing. Escaped or encoded characters are sometimes converted back to their original form and injected into the page. JavaScript in particular does its very best to execute whatever code is passed to it. A good polyglot payload will take advantage of all of this, and seek to evade some filtering as well The first thing a sharp eye will notice is that most of the keywords, such as textarea, javascript, and onload, are randomly capitalize, JaVaaCript: /*-/+' /4\1/¥! /4n/oe/(/+ + /oNe1iCk=alert () } / /ODROAROdRDa//\x3e This may seem like a futile attempt to evade application firewall input filters, but you'd be surprised how many are poorly designed. Consider the following regular expression (regex) input filter: s/onclick= [a-2l +\(.4\)//g, A regex is a piece of text defining a search pattem. Some WAFs may use regex to try and find potentially dangerous strings inside HTTP requests. This will effectively prevent JavaScript code from being injected via the one Lick event, but with one glaring flaw: it doesn't take into account case-sensitivity. Regular expressions have many modifiers, such as the g in the preceding example, and by default most engines require the i modifier to ignore case, or else they will not match and the filter is vulnerable to bypass. [51]Efficient Discovery The following figure shows Regex101's visualization of the preceding regex applied toa sample test string, We can see that only two of the four payloads tested matched the expression, while all four would execute JavaScript code: = "tae harm pemenin che ew © einad seneseorann 2 Figure 2.30; Reges filter visualization When assessing an application's regex-based input filter, Regex101 is a great place to test it against several payloads at once. RegexI01 is an online tool available for free at https: //[Link] Many times, developers work under unrealistic time constraints. When a penetration testing report highlights a particular input sanitization issue, developers are pressured to turn in a security fix that was quickly written, insufficiently tested, and remediates only part of the problem. It is often too time-consuming and expensive to implement a potentially application-breaking framework to handle input filtering, and shortcuts are taken at security's expense. The Elsobky payload also aims to exploit being passed through an engine that processes hex-encoded values escaped with a backslash. JavaScript and Python, for example, will process two alphanumeric characters preceded by \x as one byte. This could bypass certain in-line XSS filters that perform primitive string compare checks: [s2]Chapter 2 javascript :/+-/+'/#\ 1/41 /snfee/ (/* + /oNicLickealert () } //MoDsOASOd¥0a//\x3e It is possible that the payload may be stripped of most of the other keywords, but when the filter reaches \x3c and \x3e, it interprets them as benign strings of four characters. The application may parse the string and inadvertently return the one-byte equivalent of the escaped hexadecimal characters < and > respectively. The result is an