Penetration test – Adventures in the programming jungle

(My) BruCON 2018 Notes (Retro Day)

4 October, 2018Adrian Citu

Here are my quick notes from the BruCON 2018 conference.This first day was called “Retro Day” because it contained the best (as chosen by peoples) previous talks. All the slides of the conference can be found here.

Advanced WiFi Attacks using Commodity Hardware (by Mathy Vanhoef)

Wifi devices assume that each device is behaving fairy,share the bandwidth with the other devices for example.

With special hardware it is possible to modify this behavior ; It is possible to do:

continous jamming; channel unusable.
selective jamming; block specific packets.

Implementing of selfish behavior using cheap devices

Steps to send a frame:
frame1 + SIFS + AIFSN + backoff + frame2

SIFS : represents the time to let the hardware process the frame.
Backoff : random amount of time, used to avoid collisions.

Implement the selfish behavior (this was done by modifying the firmware):

disable Backoff.
reduce AIFSN.

Countermeasures to this problem:

DOMINO defense system detects selfish devices

What if are multiple selfish stations ?
in theory : in collision both frames are lost but in reality due to the “capture effect” in a collision the frame with best signal and lowest
bit-rate is decoded (similar to FM radio).

Continuous jamming

how it works:

instant transmit:disable carrier sense
no interruptions : queue infinite packets

This will
– only first package visible in monitor mode
– other devices are silcenced

What is the impact in practice:
We can jam any device that use the 2.4 and 5 GHz band, not only wifi, but other devices like security cameras.

Selective jammer

Decides based on the header whether the jam the frame
so it should:

detect and decode the header.
abort receiving current frame.
inject dummy packet

The hard part is the first step. This is done by monitoring the (RAM) memory written by the radio chip.

Impact of the attacks on higher layers

Breaking WPA2; this is a shorter version of :KRACKing WPA2 in Practice Using Key Reinstallation Attacks.

Hacking driverless vehicles (by Zoz)

Drivelless vehicles advantages:

energy efficiency
time efficiency

Main roadblocks:
– shared infrastructure (have to share road/s with card driven by humans)
– acceptance (safety robustness).

Classical failures:

RQ-3 DarkStar – self flying drone; it crashed due to cracks into the runway.
sandstorm ; self driving car contest: in this case the mismatch between GPS info and other sensor.

Autonomous vehicle logic structure:

Mission task planners
|
Navigation
|
Collision avoidance
|
Control lops

Sensors used by driveless vehicles:

active vs passive sensors
common sensors:
- gps
- lidar
- cameras
- wave radar
- digiwheel encoderes

Sensor attacks

2 kinds:

denial
spoofing – craft false data

GPS:

denial – jamming
spoofing – fake GPS satellite signals

LIDAR

denial:
- active overpowering
- preventing returning signal
spoofing
- can fake road markings invisible to humans
- can make solid looking objects

Digital compass:

extremely difficult to interfere with acoustic attacks.
gyroscope vibrates and has a resonance frequency.

Levelling Up Security @ Riot Games (by Mark Hillick)

The talk was structured in 2 parts; what RiotGames do/did to enhance security in 2015 and what they are doing to enhance security in 2018

2015

introduced the idea of security champion.
introduced the RFC (Review For Commens) document = Technical Design.
- not an approval process it’s more about receiving advice
- becomes a standards through adoption.
- introduction of bug bounty program.

2018

security team had doubled in size.
sec-ops team and read team are working together.
put in place an anti-cheating strategy:
- prevention
- detection
- deterence

Top8 vulnerabilities:

improper authentication.
open redirect.
information disclosure.
business error.

Challenges around secrets:

detected an api key from AWS in a commit.
how to fix it.
- provide temporary AWS API token
- remove the usage of long-lived AWS Api keys.

Social engineering for penetration testers (by Sharon Conheady)

Definition: efforts to influence popular attitudes and social behavior.

Main take away (for 2018); the social engineering (a.k.a SE) is used more and more and actually the techniques it didn’t change too much.

what has changed since 2009 ?
nothing

example of social enginnering through history:

What had changed since 2009 (when the same talk has been given):

the scale of the attacks.
sophistication
more targeted
ethical SE is mostly phishing.

Why social engineering (still) works:

peoples want to help.
greed
tendency to trust
complacency
peoples do not like confrontations.

Stages of an attack

target identification
reconnaissance
- passive information gathering
- physical reconnaissance
- google map
- where are the security guards
sample scenarios
- tailgate
going in for the attack
- use your scenario to get in
- prove you were there
- have an exit strategy
write the report
tell the story

The 99c heart surgeon dilemma (by Stefan Friedli)

The presentation was about pen test bad examples and how to make the things better.

It starts with examples of bad pen test:

Unclear impact metrics.
Accidentally pasting other customer names.
Reported false positives.

How to make the things better:

Avoid security companies offering bad services. How:
- Ask about procedures, standards.
- Ask to talk to the testers
- Check for community participation
- Look at sample deliverables
How to fix Penetration Testing:
- Involve more people.
- Have more conversations.
- Don’t stop at the report

Book review: Software Security: Building Security in – Part II: Seven Touchpoints for Software Security

3 April, 201623 March, 2016Adrian Citu

This is a review of the second part of the Software Security: Building Security in book.

Chapter 3: Introduction to Software Security Touchpoints

This is an introductory chapter for the second part of the book. A very brief description is made for every security touch point.

Each one of the touchpoints are applied on a specific artifact and each touchpoints represents either a destructive or constructive activity. Based on the author experience, the ideal order based on effectiveness in which the touch points should be implemented is the following one:

Code Review (Tools). Artifact: code. Constructive activity.
Architectural Risk Analysis. Artifact: design and specification. Constructive activity.
Penetration Testing. Artifact: system in its environment. Destructive activity
Risk-Based Security Testing. Artifact system. Mix between destructive and constructive activities
Abuse Cases. Artifact: requirements and use cases. Predominant destructive activity.
Security Requirements. Artifact: requirements. Constructive activity.
Security Operations. Artifact: fielded system. Constructive activity.

Another idea to mention that is worth mentioning is that the author propose to add the securty aspects as soon as possible in the software development cycle;moving left as much as possible (see the next figure that pictures the applicability of the touchpoints in the development cycle); for example it’s much better to integrate security in the requirements or architecture and design (using the risk analysis and abuse cases touchpoints) rather than waiting for the penetration testing to find the problems.

Chapter 4: Code review with a tool

For the author the code review is essential in finding security problems early in the process. The tools (the static analysis tools) can help the user to make a better job, but the user should also try to understand the output from the tool; it’s very important to not just expect that the tool will find all the security problems with no further analysis.

In the chapter a few tools (commercial or not) are named, like CQual, xg++, BOON, RATS, Fortify (which have his own paragraph) but the most important part is the list of key characteristics that a good analysis tool should have and some of the characteristics to avoid.

The key characteristics of a static analysis tool:

be designed for security
support multi tiers architecture
be extensible
be useful for security analysts and developers
support existing development processes

The key characteristics of a static analysis tool to avoid:

too many false positives
spotty integration with the IDE
single-minded support for C language

Chapter 5: Architectural Risk Analysis

Around 50% of the security problems are the result of design flows, so performing an architecture risk analysis at design level is an important part of a solid software security program.

In the beginning of the chapter the author present very briefly some existing security risk analysis methodologies: STRIDE (Microsoft), OCTAVE (Operational Critical Threat, Asset and Vulnerability Evaluation), COBIT (Control Objectives for Information and Related Technologies).

Two things are very important for the author; the ara (architectural risk analysis) must be integrated in and with the Risk Management Framework (presented briefly in Book review: Software Security: Building Security in – Part I: Software Security Fundamentals), and we must have a “forest-level” view of the system.

In the last part of the chapter the author present the Cigital way of making architectural risk analysis. The process has 3 steps:

attack resistance analysis – have as goal to define how the system should behave against known attacks.
ambiguity analysis – have as goal to discover new types of attacks or risks, so it relies heavily on the experience of the persons performing the analysis.
weakness analysis – have as goal to understand end asses the impact of external software dependencies.

Process diagram for architectural risk analysis

Chapter 6: Software Penetration Testing

The chapter starts by presenting how the penetration testing is done today. For the author, the penetration tests are misused and are used as a “feel-good exercise in pretend security”. The main problem is that the penetration tests results cannot guarantee that the system is secured after all the found vulnerabilities had been fixed and the findings are treated as a final list of issues to be fixed.

So, for the author the penetration tests are best suited to probing (live like) configuration problems and other environmental factors that deeply impact software security. Another idea is to use the architectural risk analysis as a driver for the penetration tests (the risk analysis could point to more weak part(s) of the system, or can give some attack angles). Another idea, is to treat the findings as a representative sample of faults in the system and all the findings should be incorporated back into the development cycle.

Chapter 7: Risk-Based Security Testing

Security testing should start as the feature or component/unit level and (as the penetration testing) should use the items from the architectural risk analysis to identify risks. Also the security testing should continue at system level and should be directed at properties of the integrated software system. Basically all the tests types that exist today (unit tests, integration tests) should also have a security component and a security mindset applied.

The security testing should involve two approaches:

functional security testing: testing security mechanism to ensure that their functionality is properly implemented (kind of white hat philosophy).
adversarial security testing: tests that are simulating the attacker’s approach (kind of black hat philosophy).

For the author the penetration tests represents a outside->in type of approach, the security testing represents an inside->out approach focusing on the software products “guts”.

Chapter 8: Abuse Case Development

The abuse case development is done in the requirements phase and it is intimately linked to the requirements and use cases. The basic idea is that as we define requirements that suppose to express how the system should behave under a correct usage, we should also define how the system should behave if it’s abused.

This is the process that is proposed by the author to build abuse cases.

The abuse cases are creating using two sources, the anti-requirements (things that you don’t want your software to do) and attack models, which are known attacks or attack types that can apply to your system. Once they are done, the abuse cases can be used as entry point for security testing and especially for the architectural risk analysis.

Chapter 9: Software Security Meets Security Operations

The main idea is that the security operations peoples and software developers should work together and each category can (and should) learn from the other (category).

The security operation peoples have the security mindset and can use this mindset and their experience in some of the touchpoints presented previously; mainly abuse cased, security testing, architectural risk analysis and penetration testing.

Book review: Basics of Web Hacking (Tools and Techniques to Attack the Web)

3 March, 201520 January, 2018Adrian Citu

This is a review of The Basics of Web Hacking: Tools and Techniques to Attack the Web.

Chapter 1: The basics of Web Hacking

The chapter starts with a quick introduction to some fundamental notions of web development like web applications, web servers, http protocol and a quick presentation of 2 penetration testing methodologies: The Open-Source Security Testing MethodologyManual (OSSTM) and Penetration Testing Execution Standard (PTES).

Then the author explains how the book is structured; the book will present attack vectors around three type of targets: web server, web application and the web user and for every type of target the same steps will be followed:

Reconnaissance
Scanning
Exploitation
Fix

The last part of the chapter is dedicated to the creation of the testing environment. As testing environment the author uses the BackTrack 5 distribution on which Damn Vulnerable Web Application (DVWA) is installed.
The installation procedure is slightly outdated, for a newer version you can check this blog entry.

Chapter 2: Web Server Hacking

This chapter is dedicated to the hacking of the first type of target: the web server; the chapter is constructed arround the 3 steps (actually 4, but the Fix step have a dedicated chapter) that should be follow in order to sucesfully attack a web server.

The reconnaissance step is made firsly manually using commands like host and analysis of the robots.txt file. Once some basic data about the web server is gathered, the automatic step of the reconnaissance is fulfilled using the Nmap port scanner. The authors explains how the Nmap can be updated (in case your BackTrack distribution do not have the version 6 or later) and some basic scan commands are performed (some of the flags used by the nmap command like -O, -sV, -p are explained in detail).

The scanning step is fulfilled using the Nessus tool. For Nessus, the authors explains how to install the free version, configure, run a basic scan and interpret the results. The Nikto open-source scanning tool is also very briefly presented.

The exploitation step is fulfilled using the (well known) Metasploit framework. The author starts by introducing some basic terminology like vulnerability, exploit and payload and then he presents the use of Metasploit framework in 7 easy commands: search, use, show payloads, set payload, show options, exploit. In order to explain the Metasploit commands, the author uses a hunting game analogy; for example the search command is like reviewing all possible animals that you could target, the use command is like deciding what kind of animal to hunt, the show payload is like reviewing all possible gun types, etc…

Chapter 3: Web Application Recon and Scanning

The chapter is dedicated to the web application reconnaissance and scanning. The recon part have as goal to build a map of the target web site using a web proxy. A web proxy is a application that stands between the client browser and the web application and intercepts the . The recon part can be done using automated spidering (the application starts from a page and automatically finds and requests links, submits forms, and performs any allowed action) and a manual spidering (the human operator browse through the web site). The recon is handled using the Burp Suite.

The scanning part have as goal to discover vulnerabilities. A web proxy is capable to find vulnerabilities that are detectable by inspecting the clients requests and server responses like input-based vulnerabilities targeting the server side of the application (SQL injection, OS command injection and path traversal) or input-based vulnerabilities that target the client side (XSS). The scanning part is handled using the OWASP Zed Attack Proxy (ZAP) and the author also presents briefly the Burp Scanner which is only available in the pro version of Burp Suite.

Chapter 4: Web Exploitation with Injection

This chapter is mainly dedicated to the SQL injection vulnerabilities and Operating System Command vulnerabilities. For the SQL injection the author explains in great detail what is the SQL and how this class of vulnerabilities can affect the target web application. To find and expose this kind of vulnerabilities the author uses the Burp Proxy, Burp Repeater and the sqlmap tool (which is a SQL injection command line tool).

The second part of the chapter is dedicated to the Operating System Command vulnerabilities. These types of vulnerabilities are covered in less detail compared to the SQL injection. In order to demonstrate these types of vulnerabilities the DVWA application is used but no tools that are capable to find (or to help the user to find) this kind of vulnerabilities are presented. One interesting detail for this chapter is this page containing one-liner reverse shells.

Chapter 5: Web Exploitation with Broken Authentication and Path Traversal

The author tries to broke the (web application) authentication using 2 methods: a brute force attack and an attack on the cookies generated by the web application.

For the brute force attack, a normal authentication attemp is initially intercepted using Burp Intercept in order to find the parameters (username name and password) used for the authentication. Once this parameters have been found, the Burp Intruder product is configured to execute (repetitively) the authentication with different usernames and passwords; these usernames and passwords (called payloads) are read from external files. The attack on the cookies it’ around the randomness of the session identifiers and the test it’s done using the Burp Sequencer product.

The last part of the chapter is dedicated to the path traversal attacks. The theorethical part of this kind of attacks is very good covered but (as for the OS command vulnerabilities) no tool that can discover this kind of vulnerbilities is presented.

Chapter 6: Web User Hacking

This chapter is a (very) light introduction to the Cross-Site Scripting (XSS) vulnerabilities, Cross-Site Request Forgery (CSRF) vulnerabilities and to the social engineering vulnerabilities.

The good part about this chapter is that the author gives very good explanations about how this kind of attacks are triggered by the bad guys: it gives very good explanation about the difference between the XSS and CSRF vulnerabilities, it explains what is the different between a reflected and a stored XSS attack, it also gives good (web sites) references http://XSSed.org , OWASP XSS Filter Evasion Cheat Sheet , http://www.social- engineer.org/).

On the less good part, the author do not explains how the attacker can exploit the info gathered from an XSS attack (he just says that the attacker can retrieve the user cookie using a Java script call like document.cookie).

Chapter 7: Fixes

This chapter is about how to fix the vulnerabilities presented in the previous chapters. The chapter is articulated around the same 3 possible targets: web server, web application and the web user.

For the web server, the author proposes some strategies for server hardening: develop a repeatable hardening process, develop a process for deploying all new software updates and patches in a timely manner to the live systems, running scans and doing audits.

For the web application and the web user, the author proposes some sort of “to do” list for almost every kind of vulnerability (for example for the “Injection vulnerabilities” here is the list of things to do: Use parameterized queries, Escape malicious syntax, Make use of stored procedures, Remove unnecessary functionality on your database server, Encrypt sensitive dat).

Chapter 8: Next Steps

This small chapter contains some ideas in order to extend your knowledge regarding the security topics; what are the security grouse and events, what are the existing (security)certifications and some titles of security books.