Wednesday, May 6, 2020

Learning Web Pentesting With DVWA Part 3: Blind SQL Injection

In this article we are going to do the SQL Injection (Blind) challenge of DVWA.
OWASP describes Blind SQL Injection as:
"Blind SQL (Structured Query Language) injection is a type of attack that asks the database true or false questions and determines the answer based on the applications response. This attack is often used when the web application is configured to show generic error messages, but has not mitigated the code that is vulnerable to SQL injection.
When an attacker exploits SQL injection, sometimes the web application displays error messages from the database complaining that the SQL Query's syntax is incorrect. Blind SQL injection is nearly identical to normal , the only difference being the way the data is retrieved from the database. When the database does not output data to the web page, an attacker is forced to steal data by asking the database a series of true or false questions. This makes exploiting the SQL Injection vulnerability more difficult, but not impossible."
To follow along click on the SQL Injection (Blind) navigation link. You will be presented with a page like this:
Lets first try to enter a valid User ID to see what the response looks like. Enter 1 in the User ID field and click submit. The result should look like this:
Lets call this response as valid response for the ease of reference in the rest of the article. Now lets try to enter an invalid ID to see what the response for that would be. Enter something like 1337 the response would be like this:

We will call this invalid response. Since we know both the valid and invalid response, lets try to attack the app now. We will again start with a single quote (') and see the response. The response we got back is the one which we saw when we entered the wrong User ID. This indicates that our query is either invalid or incomplete. Lets try to add an or statement to our query like this:
' or 1=1-- -
This returns a valid response. Which means our query is complete and executes without errors. Lets try to figure out the size of the query output columns like we did with the sql injection before in Learning Web Pentesting With DVWA Part 2: SQL Injection.
Enter the following in the User ID field:
' or 1=1 order by 1-- -
Again we get a valid response lets increase the number to 2.
' or 1=1 order by 2-- -
We get a valid response again lets go for 3.
' or 1=1 order by 3-- -
We get an invalid response so that confirms the size of query columns (number of columns queried by the server SQL statement) is 2.
Lets try to get some data using the blind sql injection, starting by trying to figure out the version of dbms used by the server like this:
1' and substring(version(), 1,1) = 1-- -
Since we don't see any output we have to extract data character by character. Here we are trying to guess the first character of the string returned by version() function which in my case is 1. You'll notice the output returns a valid response when we enter the query above in the input field.
Lets examine the query a bit to further understand what we are trying to accomplish. We know 1 is the valid user id and it returns a valid response, we append it to the query. Following 1, we use a single quote to end the check string. After the single quote we start to build our own query with the and conditional statement which states that the answer is true if and only if both conditions are true. Since the user id 1 exists we know the first condition of the statement is true. In the second condition, we extract first character from the version() function using the substring() function and compare it with the value of 1 and then comment out the rest of server query. Since first condition is true, if the second condition is true as well we will get a valid response back otherwise we will get an invalid response. Since my the version of mariadb installed by the docker container starts with a 1 we will get a valid response. Lets see if we will get an invalid response if we compare the first character of the string returned by the version() function to 2 like this:
1' and substring(version(),1,1) = 2-- -
And we get the invalid response. To determine the second character of the string returned by the version() function, we will write our query like this:
1' and substring(version(),2,2) = 1-- -
We get invalid response. Changing 1 to 2 then 3 and so on we get invalid response back, then we try 0 and we get a valid response back indicating the second character in the string returned by the version() function is 0. Thus we have got so for 10 as the first two characters of the database version. We can try to get the third and fourth characters of the string but as you can guess it will be time consuming. So its time to automate the boring stuff. We can automate this process in two ways. One is to use our awesome programming skills to write a program that will automate this whole thing. Another way is not to reinvent the wheel and try sqlmap. I am going to show you how to use sqlmap but you can try the first method as well, as an exercise.
Lets use sqlmap to get data from the database. Enter 1 in the User ID field and click submit.
Then copy the URL from the URL bar which should look something like this
http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit
Now open a terminal and type this command:
sqlmap --version
this will print the version of your sqlmap installation otherwise it will give an error indicating the package is not installed on your computer. If its not installed then go ahead and install it.
Now type the following command to get the names of the databases:
sqlmap -u "http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=aks68qncbmtnd59q3ue7bmam30" -p id
Here replace the PHPSESSID with your session id which you can get by right clicking on the page and then clicking inspect in your browser (Firefox here). Then click on storage tab and expand cookie to get your PHPSESSID. Also your port for dvwa web app can be different so replace the URL with yours.
The command above uses -u to specify the url to be attacked, --cookie flag specifies the user authentication cookies, and -p is used to specify the parameter of the URL that we are going to attack.
We will now dump the tables of dvwa database using sqlmap like this:
sqlmap -u "http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=aks68qncbmtnd59q3ue7bmam30" -p id -D dvwa --tables
After getting the list of tables its time to dump the columns of users table like this:
sqlmap -u "http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=aks68qncbmtnd59q3ue7bmam30" -p id -D dvwa -T users --columns
And at last we will dump the passwords column of the users table like this:
sqlmap -u "http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=aks68qncbmtnd59q3ue7bmam30" -p id -D dvwa -T users -C password --dump
Now you can see the password hashes.
As you can see automating this blind sqli using sqlmap made it simple. It would have taken us a lot of time to do this stuff manually. That's why in pentests both manual and automated testing is necessary. But its not a good idea to rely on just one of the two rather we should leverage power of both testing types to both understand and exploit the vulnerability.
By the way we could have used something like this to dump all databases and tables using this sqlmap command:
sqlmap -u "http://localhost:9000/vulnerabilities/sqli_blind/?id=1&Submit=Submit" --cookie="security=low; PHPSESSID=aks68qncbmtnd59q3ue7bmam30" -p id --dump-all
But obviously it is time and resource consuming so we only extracted what was interested to us rather than dumping all the stuff.
Also we could have used sqlmap in the simple sql injection that we did in the previous article. As an exercise redo the SQL Injection challenge using sqlmap.

References:

1. Blind SQL Injection: https://owasp.org/www-community/attacks/Blind_SQL_Injection
2. sqlmap: http://sqlmap.org/
3. MySQL SUBSTRING() Function: https://www.w3schools.com/sql/func_mysql_substring.asp
More information
  1. Clases De Hacker
  2. Curso Hacking Gratis
  3. Hacking Desde Cero
  4. Hacking Xbox One

Tuesday, May 5, 2020

How Do I Get Started With Bug Bounty ?

How do I get started with bug bounty hunting? How do I improve my skills?



These are some simple steps that every bug bounty hunter can use to get started and improve their skills:

Learn to make it; then break it!
A major chunk of the hacker's mindset consists of wanting to learn more. In order to really exploit issues and discover further potential vulnerabilities, hackers are encouraged to learn to build what they are targeting. By doing this, there is a greater likelihood that hacker will understand the component being targeted and where most issues appear. For example, when people ask me how to take over a sub-domain, I make sure they understand the Domain Name System (DNS) first and let them set up their own website to play around attempting to "claim" that domain.

Read books. Lots of books.
One way to get better is by reading fellow hunters' and hackers' write-ups. Follow /r/netsec and Twitter for fantastic write-ups ranging from a variety of security-related topics that will not only motivate you but help you improve. For a list of good books to read, please refer to "What books should I read?".

Join discussions and ask questions.
As you may be aware, the information security community is full of interesting discussions ranging from breaches to surveillance, and further. The bug bounty community consists of hunters, security analysts, and platform staff helping one and another get better at what they do. There are two very popular bug bounty forums: Bug Bounty Forum and Bug Bounty World.

Participate in open source projects; learn to code.
Go to https://github.com/explore or https://gitlab.com/explore/projects and pick a project to contribute to. By doing so you will improve your general coding and communication skills. On top of that, read https://learnpythonthehardway.org/ and https://linuxjourney.com/.

Help others. If you can teach it, you have mastered it.
Once you discover something new and believe others would benefit from learning about your discovery, publish a write-up about it. Not only will you help others, you will learn to really master the topic because you can actually explain it properly.

Smile when you get feedback and use it to your advantage.
The bug bounty community is full of people wanting to help others so do not be surprised if someone gives you some constructive feedback about your work. Learn from your mistakes and in doing so use it to your advantage. I have a little physical notebook where I keep track of the little things that I learnt during the day and the feedback that people gave me.


Learn to approach a target.
The first step when approaching a target is always going to be reconnaissance — preliminary gathering of information about the target. If the target is a web application, start by browsing around like a normal user and get to know the website's purpose. Then you can start enumerating endpoints such as sub-domains, ports and web paths.

A woodsman was once asked, "What would you do if you had just five minutes to chop down a tree?" He answered, "I would spend the first two and a half minutes sharpening my axe."
As you progress, you will start to notice patterns and find yourself refining your hunting methodology. You will probably also start automating a lot of the repetitive tasks.

Related articles

BurpSuite Introduction & Installation



What is BurpSuite?
Burp Suite is a Java based Web Penetration Testing framework. It has become an industry standard suite of tools used by information security professionals. Burp Suite helps you identify vulnerabilities and verify attack vectors that are affecting web applications. Because of its popularity and breadth as well as depth of features, we have created this useful page as a collection of Burp Suite knowledge and information.

In its simplest form, Burp Suite can be classified as an Interception Proxy. While browsing their target application, a penetration tester can configure their internet browser to route traffic through the Burp Suite proxy server. Burp Suite then acts as a (sort of) Man In The Middle by capturing and analyzing each request to and from the target web application so that they can be analyzed.











Everyone has their favorite security tools, but when it comes to mobile and web applications I've always found myself looking BurpSuite . It always seems to have everything I need and for folks just getting started with web application testing it can be a challenge putting all of the pieces together. I'm just going to go through the installation to paint a good picture of how to get it up quickly.

BurpSuite is freely available with everything you need to get started and when you're ready to cut the leash, the professional version has some handy tools that can make the whole process a little bit easier. I'll also go through how to install FoxyProxy which makes it much easier to change your proxy setup, but we'll get into that a little later.

Requirements and assumptions:

Mozilla Firefox 3.1 or Later Knowledge of Firefox Add-ons and installation The Java Runtime Environment installed

Download BurpSuite from http://portswigger.net/burp/download.htmland make a note of where you save it.

on for Firefox from   https://addons.mozilla.org/en-US/firefox/addon/foxyproxy-standard/


If this is your first time running the JAR file, it may take a minute or two to load, so be patient and wait.


Video for setup and installation.




You need to install compatible version of java , So that you can run BurpSuite.
More info
  1. Que Es Un Hacker
  2. House Hacking
  3. Cómo Se Escribe Hacker
  4. Hacking Aves
  5. El Hacker Pelicula
  6. Crack Definicion
  7. Cosas De Hackers
  8. Google Hacking Database
  9. Hacking Pdf
  10. Kali Linux Hacking
  11. Hacking Ethical
  12. Hacking System
  13. Hacking Background
  14. Hacking Net

10 Best Wifi Hacking Android Apps To Hack Others Wifi (Without Root)

 Top 10 Best wifi hacking apps to hack wifi^s.   

Today, a smartphone without internet is like a decade ago featured phone which is mainly used to dial and receive the call. No one would even want such a phone today. The Internet is now a necessity for every mobile user. They can't live without the internet and unfortunately; if the Internet is not working due to some signal issues; they get frustrated and sometimes depressed too.


Generally, we need to pay for the Internet subscription package to run mobile data on our smartphone. But what to do if I don't want to spend money on the Internet? The solution is to connect your mobile with WiFi. You can access the internet from there. Easy, right? NO, it's not easy until you know the password of WiFi. But what if you don't know.

Two ways possible in this situation

  1. Either you ask for the password to the owner; he will provide you to use his internet through Wi-Fi
  2. You have to hack the Wi-Fi password of other's network and use the internet as an unauthorized person.

First is not reliable when you don't know the person so, you only have a second option. Today, I am going to share a few apps that help you steal the password and allow you to use the internet from others' account.

1. WiFi WPS WPA Tester

This is the foremost tool to hack the WiFi password without knowing even the root. This is a preferred choice of numerous smartphone users to decipher the pin and get access to the Wi-Fi. As time passes, a tool is upgraded and now even hack the WiFi networks while it was used to check if an access point is highly vulnerable to the rancorous attacks or not.

If you are using Lollipop or above version on your android mobile phone; you don't even need to root your device to crack a WiFi network.

Android App

Pros

  • Easy to use
  • Free
  • Decrypt the password in no time.
  • Implementation of several algos like Zhao, Arris, Dlink and more.

Cons

  • Need root access if you are using the version below Lollipop.

2. WPS Connect

Routers which has enabled a WPS protocol can be hacked with this app. The important thing is that almost all routers found in public places and homes fall under this category. In short, you will have what you want. Moreover, you can focus on your router & examine that it's vulnerable to any malicious attack or not. It helps you hack the WiFi password without root and also strengthen your WiFi network.

Once you identify the vulnerable (accessible) network, you can quickly get the password and start using the internet without any hassle. It uses algorithms like easyboxPIN and Zhao. Although, this app is not compatible with various Android phones as it is tested on Android devices like the Galaxy series, Nexus and more.

Android App

Pros

  • It's free and easy to use
  • Powerful algorithms (Zhao & easyboxPin) to crack the password
  • Supports pinning of Wi-Fi routers

Cons

  • Incompatible with few android devices
  • Couldn't identify the network automatically.

3. WiFi WPS WPA Tester Premium

This is an excellent app to decrypt the WiFi network password on your android phone. This works fine on rooted & non-rooted android phones. If you can root the Android device; you can have a better chance to hack into. Today,  security is the primary concern and so, many people use the highly secured wireless router, I think. For such networks, this app will not work as it should be. But, still it can work for numerous times with the help of WPS; not all the time. Every time, you have to try your luck to get access to other's WiFi network. This WPS WPA tester is a premium apk.

Android App

Pros

  • Works for both rooted and non-rooted android devices
  • Find the nearby network and connect your mobile with it.

Cons

  • It's a premium apk.
  • You have to try your luck to get access to the nearby network.
  • Not good to connect with highly secured wireless routers.

4. AndroDumpper Wifi (WPS Connect) – Discontinued

If you want to connect to a router which is WPS enabled; download this app immediately without going down to browse for other apps. Just open the app, start its interface & find the nearby wireless networks, you want to connect with. The app will provide an excellent option to regain the password of a selected network with & without root. Once you implemented the algorithm; it will display the password in app screen & connect to the network. Isn't it easy for you?

Android App

Pros

  • It's Free on Google Play Store
  • Easy to use and faster than some other tool.
  • Works fine for rooted & non-rooted devices
  • A dedicated blog is available for the tool (Get guidance anytime)
  • Supports for giant company routers (Vodaphone, Asus, Huawei, Dlink, etc.)

Cons

  • Rooting is required if you are using a version below android 5.0
  • Works only for WPS enabled routers.

5. Wi-fi Password Hacker Prank

Wifi Password hacker prank is a free app for the android users and can help you to connect your android phone to wifi networks available nearby. This free app simulates a process of hacking the wireless network with your smartphone. With this app, you can hack all wifi network passwords with just one key. The Prank word itself says it's a funny app used to prank with your friends. Sometimes, girls can be impressed with this prank as well. But try this at your own risk. Look excellent and professional in front of your friends and colleagues.

Steps to Hack Wifi using the Wifi Password Hacker Prank:

  • Catch up the wireless networks near to you and then select the secure network you wish to hack.
  • Wait for a while & a dialogue will be opened with the wifi password.
  • Bingo! Paste the password and start using others' Internet without spending single money.
  • Watch your favourite show and movie in High-Definition quality without worrying about your mobile data.
Android App

6. WiFi Warden

WiFi Warden is one of the finest and free android WiFi hacking apps to get access to others WiFi with ease. With WiFi Warden, a user can Analyze the WiFi networks, connect to your WiFi using the passphrase and WPS and view saved WiFi passwords without root.

By analyzing the WiFi networks, you can see all necessary information that can be discovered on the wireless networks around including BSSID, SSID, Channel bandwidth, encryption, security, router manufacturer, distance and channel number, etc.

Android App

Pros

  • Find the less crowded channel to get WiFi access.
  • You can root your device on all Android versions.
  • Easy to use and connect with the router quickly.
  • All features of this app are available for free.

Cons

  • This app doesn't work on all types of router, use a passphrase instead.
  • Access Point (AP) must have enabled WPS.
  • Require Android version 6 (Marshmallow) or higher version is necessary to display Wi-Fi networks around you.
  • Some of the features are in the testing phase. So, use it your own risk.

7. WiFi Password

'WiFi Password' is a completely free app for those who don't want to get away from the Internet even when their internet data is running out. You can connect with others' WiFi routers and use their Internet.

If you are using Android Version 5 or above; 'WiFi Password' can be the right choice for you to watch your favorite shows on YouTube in HD without even worrying about Mobile Data.

Android App

Pros:

  • Millions of WiFi Hotspots
  • Scan and detect the WiFi security
  • Connect WiFi Hotspot nearby without knowing the WiFi Password
  • You can simply add a free WiFi Hotspot by sharing the passwords with others.

Cons :

  • Still, there are some glitches in it but works well.

8. WiFi Kill Pro

WiFi Kill is one the best WiFi network controller application which can disable the Internet connection of others who are connected to the same network. Yes, this is true. It is a useful tool for internet users who want to improve their data speed by disabling other's internet connection and allocate all the bandwidth to your device only.

Currently, this app is only for Android users and needs root access to perform well.

Android App

Pros


    • You can see all connected device on the same network you are connected.

    • Display the data transfer rate of all devices

    • Monitor network activity

    • You can cut the network connection of any connected device.
  • It works well on tablets too.

Cons


    • Require root access
  • Require Android version 4.0.3 or up to use this app.

9. Penetrate Pro

A popular Wifi hacker app for android users, Penetrate pro is free and works well on Android devices. This app is widely used to find WEP and/or WPA keys to connect the devices with network routers without knowing the wifi password. Just install the app and search for the network; this app starts automatically displaying the WEP/WPA keys on the screen. Tap on the network you want to connect; one it gets connected; you can start watching videos on YouTube. Quite interesting, doesn't it?

Android App

Pros


    • Easy to search nearby free wifi networks.

    • Connect the network without knowing keys
  • Available for Free

Cons


    • Not available on Google Play Store; need to download manually.
  • Works well only for the rooted android devices

So, you have got the list of apps that help you use the internet from other's wireless network without getting caught. If you have any idea of any other Wi-Fi password hacking app; just let me know. We would love to discuss it here.


Disclaimer: VR Bonkers is not responsible for any consequences if you face while using any of the above apps. This is just a list and we are not taking any responsibility for the same. So, use them at your risk.


@EVERYTHING NT

Related articles

Monday, May 4, 2020

Playing With TLS-Attacker

In the last two years, we changed the TLS-Attacker Project quite a lot but kept silent about most changes we implemented. Since we do not have so much time to keep up with the documentation (we are researchers and not developers in the end), we thought about creating a small series on some of our recent changes to the project on this blog.


We hope this gives you an idea on how to use the most recent version (TLS-Attacker 2.8). If you feel like you found a bug, don't hesitate to contact me via GitHub/Mail/Twitter. This post assumes that you have some idea what this is all about. If you have no idea, checkout the original paper from Juraj or our project on GitHub.

TLDR: TLS-Attacker is a framework which allows you to send arbitrary protocol flows.


Quickstart:
# Install & Use Java JDK 8
$ sudo apt-get install maven
$ git clone https://github.com/RUB-NDS/TLS-Attacker
$ cd TLS-Attacker
$ mvn clean package

So, what changed since the release of the original paper in 2016? Quite a lot! We discovered that we could make the framework much more powerful by adding some new concepts to the code which I want to show you now.

Action System

In the first Version of TLS-Attacker (1.x), WorkflowTraces looked like this:
Although this design looks straight forward, it lacks flexibility. In this design, a WorkflowTrace is basically a list of messages. Each message is annotated with a <messageIssuer>, to tell TLS-Attacker that it should either try to receive this message or send it itself. If you now want to support more advanced workflows, for example for renegotiation or session resumption, TLS-Attacker will soon reach its limits. There is also a missing angle for fuzzing purposes. TLS-Attacker will by default try to use the correct parameters for the message creation, and then apply the modifications afterward. But what if we want to manipulate parameters of the connection which influence the creation of messages? This was not possible in the old version, therefore, we created our action system. With this action system, a WorkflowTrace does not only consist of a list of messages but a list of actions. The most basic actions are the Send- and ReceiveAction. These actions allow you to basically recreate the previous behavior of TLS-Attacker 1.x . Here is an example to show how the same workflow would look like in the newest TLS-Attacker version:


As you can see, the <messageIssuer> tags are gone. Instead, you now indicate with the type of action how you want to deal with the message. Another important thing: TLS-Attacker uses WorkflowTraces as an input as well as an output format. In the old version, once a WorkflowTrace was executed it was hard to see what actually happened. Especially, if you specify what messages you expect to receive. In the old version, your WorkflowTrace could change during execution. This was very confusing and we, therefore, changed the way the receiving of messages works. The ReceiveAction has a list of <expectedMessages>. You can specify what you expect the other party to do. This is mostly interesting for performance tricks (more on that in another post), but can also be used to validate that your workflow executedAsPlanned. Once you execute your ReceiveAction an additional <messages> tag will pop up in the ReceiveAction to show you what has actually been observed. Your original WorkflowTrace stays intact.


During the execution, TLS-Attacker will execute the actions one after the other. There are specific configuration options with which you can control what TLS-Attacker should do in the case of an error. By default, TLS-Attacker will never stop, and just execute whatever is next.

Configs

As you might have seen the <messageIssuer> tags are not the only thing which is missing. Additionally, the cipher suites, compression algorithms, point formats, and supported curves are missing. This is no coincidence. A big change in TLS-Attacker 2.x is the separation of the WorkflowTrace from the parameter configuration and the context. To explain how this works I have to talk about how the new TLS-Attacker version creates messages. Per default, the WorkflowTrace does not contain the actual contents of the messages. But let us step into TLS-Attackers point of view. For example, what should TLS-Attacker do with the following WorkflowTrace:

Usually, the RSAClientKeyExchange message is constructed with the public key from the received certificate message. But in this WorkflowTrace, we did not receive a certificate message yet. So what public key are we supposed to use? The previous version had "some" key hardcoded. The new version does not have these default values hardcoded but allows you as the user to define the default values for missing values, or how our own messages should be created. For this purpose, we introduced the new concept of Configs. A Config is a file/class which you can provide to TLS-Attacker in addition to a WorkflowTrace, to define how TLS-Attacker should behave, and how TLS-Attacker should create its messages (even in the absence of needed parameters). For this purpose, TLS-Attacker has a default Config, with all the known hardcoded values. It is basically a long list of possible parameters and configuration options. We chose sane values for most things, but you might have other ideas on how to do things. You can execute a WorkflowTrace with a specific config. The provided Config will then overwrite all existing default values with your specified values. If you do not specify a certain value, the default value will be used. I will get back to how Configs work, once we played a little bit with TLS-Attacker.

TLS-Attacker ships with a few example applications (found in the "apps/" folder after you built the project). While TLS-Attacker 1.x was mostly a standalone tool, we currently see TLS-Attacker more as a library which we can use by our more sophisticated projects. The current example applications are:
  • TLS-Client (A TLS-Client to execute WorkflowTraces with)
  • TLS-Server (A TLS-Server to execute WorkflowTraces with)
  • Attacks (We'll talk about this in another blog post)
  • TLS-Forensics (We'll talk about this in another blog post)
  • TLS-Mitm (We'll talk about this in another blog post)
  • TraceTool (We'll talk about this in another blog post) 

TLS-Client

The TLS-Client is a simple TLS-Client. Per default, it executes a handshake for the default selected cipher suite (RSA). The only mandatory parameter is the server you want to connect to (-connect).

The most trivial command you can start it with is:

Note: The example tool does not like "https://" or other protocol information. Just provide a hostname and port

Depending on the host you chose your output might look like this:

or like this:

So what is going on here? Let's start with the first execution. As I already mentioned. TLS-Attacker constructs the default WorkflowTrace based on the default selected cipher suite. When you run the client, the WorkflowExecutor (part of TLS-Attacker which is responsible for the execution of a WorkflowTrace) will try to execute the handshake. For this purpose, it will first start the TCP connection.
This is what you see here:

After that, it will execute the actions specified in the default WorkflowTrace. The default WorkflowTrace looks something like this:
This is basically what you see in the console output. The first action which gets executed is the SendAction with the ClientHello.

Then, we expect to receive messages. Since we want to be an RSA handshake, we do not expect a ServerKeyExchange message, but only want a ServerHello, Certificate and a ServerHelloDone message.

We then execute the second SendAction:

and finally, we want to receive a ChangeCipherSpec and Finished Message:

In the first execution, these steps all seem to have worked. But why did they fail in the second execution? The reason is that our default Config does not only allow specify RSA cipher suites but creates ClientHello messages which also contain elliptic curve cipher suites. Depending on the server you are testing with, the server will either select and RSA cipher suite, or an elliptic curve one. This means, that the WorkflowTrace will not executeAsPlanned. The server will send an additional ECDHEServerKeyExchange. If we would look at the details of the ServerHello message we would also see that an (ephemeral) elliptic curve cipher suite is selected:

Since our WorkflowTrace is configured to send an RSAClientKeyExchange message next, it will just do that:

Note: ClientKeyExchangeMessage all have the same type field, but are implemented inside of TLS-Attacker as different messages

Since this RSAClientKeyExchange does not make a lot of sense for the server, it rejects this message with a DECODE_ERROR alert:

If we would change the Config of TLS-Attacker, we could change the way our ClientHello is constructed. If we specify only RSA cipher suites, the server has no choice but to select an RSA one (or immediately terminate the connection). We added command line flags for the most common Config changes. Let's try to change the default cipher suite to TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:

As you can see, we now executed a complete ephemeral elliptic curve handshake. This is, because the -cipher flag changed the <defaultSelectedCiphersuite> parameter (among others) in the Config. Based on this parameter the default WorkflowTrace is constructed. If you want, you can specify multiple cipher suites at once, by seperating them with a comma.

We can do the same change by supplying TLS-Attacker with a custom Config via XML. To this we need to create a new file (I will name it config.xml) like this:

You can then load the Config with the -config flag:

For a complete reference of the supported Config options, you can check out the default_config.xml. Most Config options should be self-explanatory, for others, you might want to check where and how they are used in the code (sorry).

Now let's try to execute an arbitrary WorkflowTrace. To do this, we need to store our WorkflowTrace in a file and load it with the -workflow_input parameter. I just created the following WorkflowTrace:


As you can see I just send a ServerHello message instead of a ClientHello message at the beginning of the handshake. This should obviously never happen but let's see how the tested server reacts to this.
We can execute the workflow with the following command:

The server (correctly) responded with an UNEXPECTED_MESSAGE alert. Great!

Output parameters & Modifications

You are now familiar with the most basic concepts of TLS-Attacker, so let's dive into other things TLS-Attacker can do for you. As a TLS-Attacker user, you are sometimes interested in the actual values which are used during a WorkflowTrace execution. For this purpose, we introduced the -workflow_output flag. With this parameter, you can ask TLS-Attacker to store the executed WorkflowTrace with all its values in a file.
Let's try to execute our last created WorkflowTrace, and store the output WorkflowTrace in the file out.xml:


The resulting WorkflowTrace looks like this:

As you can see, although the input WorkflowTrace was very short, the output trace is quite noisy. TLS-Attacker will display all its intermediate values and modification points (this is where the modifiable variable concept becomes interesting). You can also execute the output workflow again.


Note that at this point there is a common misunderstanding: TLS-Attacker will reset the WorkflowTrace before it executes it again. This means, it will delete all intermediate values you see in the WorkflowTrace and recompute them dynamically. This means that if you change a value within <originalValue> tags, your changes will just be ignored. If you want to influence the values TLS-Attacker uses, you either have to manipulate the Config (as already shown) or apply modifications to TLS-Attackers ModifiableVariables. The concept of ModifiableVariables is mostly unchanged to the previous version, but we will show you how to do this real quick anyway.

So let us imagine we want to manipulate a value in the WorkflowTrace using a ModifiableVariable via XML. First, we have to select a field which we want to manipulate. I will choose the protocol version field in the ServerHello message we sent. In the WorkflowTrace this looked like this:

For historical reasons, 0x0303 means TLS 1.2. 0x0300 was SSL 3. When they introduced TLS 1.0 they chose 0x0301 and since then they just upgraded the minor version.

In order to manipulate this ModifiableVariable, we first need to know its type. In some cases it is currently non-trivial to determine the exact type, this is mostly undocumented (sorry). If you don't know the exact type of a field you currently have to look at the code. The following types and modifications are defined:
  • ModifiableBigInteger: add, explicitValue, shiftLeft, shiftRight, subtract, xor
  • ModifiableBoolean: explicitValue, toggle
  • ModifiableByteArray: delete, duplicate, explicitValue, insert, shuffle, xor
  • ModifiableInteger: add, explicitValue, shiftLeft, shiftRight, subtract, xor
  • ModifiableLong: add, explicitValue, subtract, xor
  • ModifiableByte: add, explicitValue, subtract, xor
  • ModifiableString: explicitValue
As a rule of thumb: If the value is only up to 1 byte of length we use a ModifiableByte. If the value is up to 4 bytes of length, but the values are used as a normal number (for example in length fields) it is a ModifiableInteger. Fields which are used as a number which are bigger than 4 bytes (for example a modulus) is usually a ModifiableBigInteger. Most other types are encoded as ModifiableByteArrays. The other types are very rare (we are currently working on making this whole process more transparent).
Once you have found your type you have to select a modification to apply to it. For manual analysis, the most common modifications are the XOR modification and the explicit value modification. However, during fuzzing other modifications might be useful as well. Often times you just want to flip a bit and see how the server responds, or you want to directly overwrite a value. In this example, we want to overwrite a value.
Let us force TLS-Attacker to send the version 0x3A3A. To do this I consult the ModifiableVariable README.md for the exact syntax. Since <protocolVersion> is a ModifiableByteArray I search in the ByteArray section.

I find the following snippet:

If I now want to change the value to 0x3A3A I modify my WorkflowTrace like this:

You can then execute the WorkflowTrace with:

With Wireshark you can now observe  that the protocol version got actually changed. You would also see the change if you would specify a -workflow_output or if you start the TLS-Client with the -debug flag.

More Actions

As I already hinted, TLS-Attacker has more actions to offer than just a basic Send- and ReceiveAction (50+ in total). The most useful, and easiest to understand actions are now introduced:

ActivateEncryptionAction

This action does basically what the CCS message does. It activates the currently "negotiated" parameters. If necessary values are missing in the context of the connection, they are drawn from the Config.


DeactivateEncryptionAction

This action does the opposite. If the encryption was active, we now send unencrypted again.


PrintLastHandledApplicationDataAction

Prints the last application data message either sent or received.


PrintProposedExtensionsAction

Prints the proposed extensions (from the client)


PrintSecretsAction

Prints the secrets (RSA) from the current connection. This includes the nonces, cipher suite, public key, modulus, premaster secret, master secret and verify data.


RenegotiationAction

Resets the message digest. This is usually done if you want to perform a renegotiation.


ResetConnectionAction

Closes and reopens the connection. This can be useful if you want to analyze session resumption or similar things which involve more than one handshake.


SendDynamicClientKeyExchangeAction

Send a ClientKeyExchange message, and always chooses the correct one (depending on the current connection state). This is useful if you just don't care about the actual cipher suite and just want the handshake done.


SendDynamicServerKeyExchangeAction

(Maybe) sends a ServerKeyExchange message. This depends on the currently selected cipher suite. If the cipher suite requires the transmission of a ServerKeyExchange message, then a ServerKeyExchange message will be sent, otherwise, nothing is done. This is useful if you just don't care about the actual cipher suite and just want the handshake done.


WaitAction

This lets TLS-Attacker sleep for a specified amount of time (in ms).





As you might have already seen there is so much more to talk about in TLS-Attacker. But this should give you a rough idea of what is going on.

If you have any research ideas or need support feel free to contact us on Twitter (@ic0nz1, @jurajsomorovsky ) or at https://www.hackmanit.de/.

If TLS-Attacker helps you to find a bug in a TLS implementation, please acknowledge our tool(s). If you want to learn more about TLS, Juraj and I are also giving a Training about TLS at Ruhrsec (27.05.2019).

Related posts


Friday, May 1, 2020

Exploring Monster Taming Mechanics In Final Fantasy XIII-2: Relational Data

In this next installment of the miniseries of exploring the monster taming mechanics of Final Fantasy XIII-2, we'll fill out another database table that we need in order to start connecting all of the monster data together. In the last article, we built the core monster table with hundreds of attributes for each of 164 monsters. In the first article, we had identified four other tables that we would need as well, these being abilities, game areas, monster materials, and monster characteristics. The data in these four tables is all related in one way or another to the monsters in the monster table. We'll start with the abilities table, which will end up being three tables because we actually have passive, command, and role abilities. Once the passive abilities table is complete, we'll see how to connect that data in the database so that we can later make inferences on the data.

Final Fantasy XIII-2 battle scene

Finding Monster Abilities

Like for the core monster data, the first thing we need to do is get the data for the monster abilities into a .csv format. We'll start with the passive abilities because this is the largest group of abilities and they have a rank attribute that the role and hidden abilities don't have. Since there are over 200 passive abilities, we're going to want to pull this data out of the FAQ with another script instead of building it up manually. We can use an FSM very similar to the one used for parsing the monster data with a few simplifications because there are not nearly so many attributes for the passive abilities. I'll just throw the script out there, and then we can discuss it:

SECTION_TAG = "PassADe"
ABILITY_SEPARATOR = "........................................"
ABILITY_REGEX = /(\w\S+(?:\s[^\s\(]+)*)\s\((RL|\d)\)-*:\s(\w\S+(?:\s\S+)*)/
ABILITY_EXT_REGEX = /^\s+(\S+(?:\s\S+)*)/

end_abilities = lambda do |line, data|
return end_abilities, data
end

new_ability = lambda do |line, data|
props = line.scan(ABILITY_REGEX)
if props.empty?
if line.include? ABILITY_SEPARATOR
return end_abilities, data
else
extra_line = ABILITY_EXT_REGEX.match(line)
data.last["description"] += ' ' + extra_line[1]
return new_ability, data
end
end

if props.first[1] == "RL"
props.first[1] = "99"
props.first[0] += " (RL)"
end
data << {"name" => props.first[0], "rank" => props.first[1], "description" => props.first[2]}
return new_ability, data
end

find_abilities = lambda do |line, data|
if line.include? ABILITY_SEPARATOR
return new_ability, data
end
return find_abilities, data
end

find_sub_section = lambda do |line, data|
if line.include? SECTION_TAG
return find_abilities, data
end
return find_sub_section, data
end

section_tag_found = lambda do |line, data|
if line.include? SECTION_TAG
return find_sub_section, data
end
return section_tag_found, data
end

start = lambda do |line, data|
if line.include? SECTION_TAG
return section_tag_found, data
end
return start, data
end

next_state = start
data = []
File.foreach("ffiii2_monster_taming_faq.txt") do |line|
next_state, data = next_state.(line, data)
end
Starting from the bottom, we can see that we kickoff the FSM by looking for the SECTION_TAG, which is "PassADe" in this case. We have to find it three times instead of the two times we looked for the section tag in the monster FSM because the tag appears one extra time in the FAQ in a sub-contents under the main "Monster Infusion" section. Then, we look for the ABILITY_SEPARATOR, which is the same as the MONSTER_SEPARATOR from the previous script, and then go into a loop of matching and storing the ability data in the data list of hash tables. The ability data has a pretty clean format with the possibility of overflowing to a second line. The first couple abilities showcase the variations we have to handle:
Uncapped Damage (RL)---------: Raises the cap on damage to 999,999.
Enhanced Commando (RL)-------: Enhances the Commando Role Bonus by one Bonus
Boost.
We have a name that can be multiple words (and by looking further ahead we also see some special characters) followed by a space and a rank in parentheses, a -: separator, and the description, possibly extending to a second line. We want to capture the name, rank, and description, and the rank can be either "RL" (for Red Lock, meaning it can never be removed from the monster) or a number 1-9. From what we've learned of regexes in past posts, it should be clear that the regex

/(\w\S+(?:\s[^\s\(]+)*)\s\((RL|\d)\)-*:\s(\w\S+(?:\s\S+)*)/

is sufficient to match on the first line and capture those three attributes. Looking at the rest of the new_ability state code, we can see that if the line doesn't match the ABILITY_REGEX, it checks if the line is the ABILITY_SEPARATOR and moves to the last state if it is. Otherwise, we know that the line is an extra line of description, so we capture it and add it to the description of the last ability captured. If the line did match the ABILITY_REGEX, then we create a new hash with the values populated from the regex captures and continue in the same state.

Note that if the rank was "RL", we convert that to "99" so that all ranks will be integers in the database. Why not "10?" Well, when an ability is yellow-locked, its rank increases by nine, so making the red-locked abilities have a rank of 10 would conflict. I could have made it 19 or 20, but 99 works just as well and really sets them apart. We also need to add the " (RL)" text back into the name of the ability because it's possible to have red-locked and non-red-locked abilities with the same name, and they are different abilities for all intents and purposes.

Validating and Exporting Monter Abilities

Next, we want to do a little validation check on this data and write it to a .csv file, so here's the code to do that:
PROPER_NAME_REGEX = /^\w.*[\w)!%]$/
NUMBER_REGEX = /^\d\d?$/
FREE_TEXT_REGEX = /^\S+(?:\s\S+)*$/

VALID_ABILITY = {
"name" => PROPER_NAME_REGEX,
"rank" => NUMBER_REGEX,
"description" => FREE_TEXT_REGEX,
}

data.each do |ability|
VALID_ABILITY.each do |key, regex|
if ability.key?(key)
unless ability[key] =~ regex
puts "Monster ability #{ability["name"]} has invalid property #{key}: #{ability[key]}."
end
else
puts "Monster ability #{ability["name"]} has missing property #{key}."
end
end
end

require 'csv'
opts = {headers: data.first.keys, write_headers: true}
CSV.open("monster_abilities.csv", "wb", opts) do |csv|
data.each { |hash| csv << hash }
end
Since we're building up each hash table directly with name, rank, and description, it's not necessary to make sure that each hash contains all three attributes and no others. We just want to make sure that each attribute value has the right (admittedly loose) format. Then we write it out to the monster_abilities.csv file.

Importing Monster Abilities

Moving right along, we can now import this .csv file into the database with another simple addition to our seed script:
csv_file_path = 'db/monster_abilities.csv'

CSV.foreach(csv_file_path, {headers: true}) do |row|
Ability.create!(row.to_hash)
puts "#{row['name']} added!"
end
Before running this script, we need to generate the Ability model and its schema. Since there are only three attributes, we can easily create the migration script in one shot:
$ rails generate model Ability name:string rank:integer description:string
This command will create this migration file:
class CreateAbilities < ActiveRecord::Migration[6.0]
def change
create_table :abilities do |t|
t.string :name
t.integer :rank
t.string :description

t.timestamps
end
end
end
Now we can run the migration and then seed the database:
$ rails db:migrate
$ rails db:seed
And we've added our second table to the database with 147 abilities. (Wait, I thought there were over 200 abilities. Good catch. We'll get to that in a bit.) However, we should have a link between this new ability table and the monster table because every monster's many abilities should all be one of the abilities in the ability table.

Associating Monsters' Abilities with the Abilities Table

What we want to do in order to associate each monster's abilities with the abilities table is make each ability in the monster table a reference instead of a string, and point those references at the correct specific abilities in the abilities table. To accomplish this association, we'll need to change both the monster table migration and the monster model part of the seed script.

First, we can change all of the t.string declarations in the monster table migration to t.references. Changing only the abilities that end in "_passive" is sufficient for now because those are the abilities we created in the abilities table. The references for these abilities will actually be foreign keys from the abilities table, so we need to tell Rails that at the end of the migration:
class CreateMonsters < ActiveRecord::Migration[6.0]
def change
create_table :monsters do |t|
t.string :name
# ... The other monster attributes ...
t.references :default_passive1
t.references :default_passive2
t.references :default_passive3
t.references :default_passive4
t.string :default_skill
t.string :special_notes
t.references :lv_02_passive
t.string :lv_02_skill
# ... The rest of the lv XX abilities ...

t.timestamps
end

add_foreign_key :monsters, :abilities, column: :default_passive1_id, primary_key: :id
add_foreign_key :monsters, :abilities, column: :default_passive2_id, primary_key: :id
add_foreign_key :monsters, :abilities, column: :default_passive3_id, primary_key: :id
add_foreign_key :monsters, :abilities, column: :default_passive4_id, primary_key: :id
add_foreign_key :monsters, :abilities, column: :lv_02_passive_id, primary_key: :id
# ... All of the other _passive abilities foreign keys ...
end
end
I know this seems like tedious busy work, but it's necessary for setting up the database. Some of it can be done with regex replace tools in some editors or generated with a script. I just brute-forced it and got pretty good at changing numbers really rapidly. Be sure to remove lv_xx_passive abilities that don't exist later in the list.

Because we changed this migration, we need to rerun it, but now it references the ability migration so when we rollback the migrations, we need to change the date in the file name on the monster migration to be after the ability migration before we run the migrations forward again. Otherwise, Rails will complain.
$ rails db:rollback STEP=2
$ [rename the monster migration file to a date after the ability migration file]
$ rails db:migrate
We're not quite done with preparing the database, yet, because the Rails models need to know about this association, too. The app/models/monster.rb file needs to know that the passive ability attributes are associated with the Ability model using the belongs_to association:
class Monster < ApplicationRecord
belongs_to :default_passive1, class_name: 'Ability', optional: true
belongs_to :default_passive2, class_name: 'Ability', optional: true
belongs_to :default_passive3, class_name: 'Ability', optional: true
belongs_to :default_passive4, class_name: 'Ability', optional: true
belongs_to :lv_02_passive, class_name: 'Ability', optional: true
# ... The rest of the lv_XX_passive attributes ...
end
It may sound weird that a monster belongs to an ability, but that's the type of association we want where the link points from the monster attribute to the ability. It's the same as if we had an Author model and a Book model, and the book belongs to the author that wrote it. The link would be in the book with the author's ID. That same link direction is what we want with monsters having links to ability IDs, so belongs_to it is.

We also need to add associations to the Ability model so that we can follow links from abilities to monsters. That association is done with has_many, which also seems a bit weird, but oh well:
class Ability < ApplicationRecord
has_many :default_passive1_monsters, :class_name => 'Monster', :foreign_key => 'default_passive1'
has_many :default_passive2_monsters, :class_name => 'Monster', :foreign_key => 'default_passive2'
has_many :default_passive3_monsters, :class_name => 'Monster', :foreign_key => 'default_passive3'
has_many :default_passive4_monsters, :class_name => 'Monster', :foreign_key => 'default_passive4'
has_many :lv_02_passive_monsters, :class_name => 'Monster', :foreign_key => 'lv_02_passive'
# ... The rest of the lv_XX_passive attributes ...
end

That was the easy, if mindlessly tedious, part. The next step is trickier. We want to change the db seed script so that when the monsters are created, the passive abilities in the monster table are references to the abilities table, and we want to catch any instances where the ability doesn't exist, meaning there was a typo or an omission. We need to make sure the ability table is populated first in the script, so we have access to those abilities when we're importing the monsters. Then, for each passive ability for each monster we search the ability table for that ability's name, and assign it to the corresponding ability attribute for the monster. That assignment creates the proper reference. If the ability isn't found, we print an error and return so the error can be fixed in the FAQ text file. We'll then have to rerun the ability or monster parser and try the import again. Here's what this process looks like in code, including the ability import:
csv_file_path = 'db/monster_abilities.csv'

CSV.foreach(csv_file_path, {headers: true}) do |row|
Ability.create!(row.to_hash)
puts "#{row['name']} added!"
end

csv_file_path = 'db/monsters.csv'

CSV.foreach(csv_file_path, {headers: true}) do |row|
monster = row.to_hash
monster.keys.select { |key| key.ends_with? '_passive' }.each do |key|
if monster[key]
monster[key] = Ability.find_by(name: monster[key])
if monster[key].nil?
puts "ERROR: monster #{monster['name']} #{key} not found!"
return
end
puts "Found #{key} #{monster[key].name}"
end
end
Monster.create!(monster)
puts "#{row['name']} added!"
end
This code is pretty much written as just described, but note that we check if the monster[key] exists before doing anything with it. Remember that these are optional attributes, so they can be nil for any given monster ability. If we run this script, we'll find right away that Cactuaroni has an ability "Critical: Haste (RL)" that doesn't exist in the ability table. We could add this ability to the FAQ and rerun the parser, but notice that there is an ability "Critical: Haste" already in the table. This issue of the non-red-locked ability existing in the table but not the red-locked version is fairly common, so we could solve the problem with code instead of tediously rerunning the scripts to find all of the instances where the red-locked ability is missing. All we have to do is search for the base ability, copy it, change the rank to 99, and tack " (RL)" onto the name. This process can be done like so:
CSV.foreach(csv_file_path, {headers: true}) do |row|
monster = row.to_hash
monster.keys.select { |key| key.include? '_passive' }.each do |key|
if monster[key]
if monster[key].ends_with?(' (RL)') && Ability.find_by(name: monster[key]).nil?
ability_name = monster[key][0..-6]
puts "Searching for #{key} ability #{ability_name}"
ability = Ability.find_by(name: ability_name).dup
ability['name'] = monster[key]
ability['rank'] = '99'
ability.save
puts "Ability #{ability['name']} added!"
end

monster[key] = Ability.find_by(name: monster[key])
if monster[key].nil?
puts "ERROR: monster #{monster['name']} #{key} not found!"
return
end
puts "Found #{key} #{monster[key].name}"
end
end
Monster.create!(monster)
puts "#{row['name']} added!"
end
If the monster ability ends with " (RL)" and it's not in the ability table, then we copy the base ability and create the corresponding red-locked ability from it. We've sidestepped a bunch of dreary work with a little bit of targeted code!

Now after running this script to seed the database, we will find a few more errors in the FAQ to fix. Four red-locked abilities are missing, so we'll have to add Perpetual Poison, Resist Damage +05%, Bonus CP, and Feral Speed. I found definitions for these abilities simply by googling them. The Resist Elements +20% ability that Twilight Odin has was also missing. I guessed at the rank of 8 for this one because I couldn't find it. Resist Elements +30% has a rank of 9 and Resist Elements +05% has a rank of 5, so it's most likely rank 7 or 8. Finally, there were three typos: the ability "Auto: Enfire (RL)" should not have the colon, the ability "Auto Haste (RL)" should be hyphenated, and the ability "ATB: Advantage (RL)" should not have the colon. After everything is fixed, we have a complete ability table with 218 abilities, and every passive monster ability is linked correctly to the ability table.


That was quite a lot of work, some of it tedious, but we accomplished a lot. We generated a list of passive abilities from the FAQ, validated that data, imported it into a new table in the database, and linked all of those abilities to the monsters that can learn them in the monster table. This process can be repeated for the much smaller tables that are left to create, and that is what we'll do next time.

Peter Dimitrov Lands Job At MilkyTea Studios!


Great to see our talented graduate @PeteDimitrovArt using his skills on new projects in the
@milkyteastudios.

Peter is a 3D environment artist and games designer and he's just joined the team at MilkyTea in the Baltic Triangle, Liverpool. The company are famous for 'Hyper Brawl Tournament, Coffin Dodgers and Roller Rally.
Huge Congratulations to Peter who has a real passion for art and games design. He created a great portfolio of work and it paid off.



Image

Image