pytbull – Intrusion Detection/Prevention System (IDS/IPS) Testing Framework

pytbull is an Intrusion Detection/Prevention System (IDS/IPS) Testing Framework for Snort, Suricata and any IDS/IPS that generates an alert file. It can be used to test the detection and blocking capabilities of an IDS/IPS, to compare IDS/IPS, to compare configuration modifications and to check/validate configurations.

The framework is shipped with about 300 tests grouped in 11 testing modules:

1. badTraffic: Non RFC compliant packets are sent to the server to test how packets are processed.
2. bruteForce: tests the ability of the server to track brute force attacks (e.g. FTP). Makes use of custom rules on Snort and Suricata.
3. clientSideAttacks: this module uses a reverse shell to provide the server with instructions to download remote malicious files. This module tests the ability of the IDS/IPS to protect against client-side attacks.
4. denialOfService: tests the ability of the IDS/IPS to protect against DoS attempts
5. evasionTechniques: various evasion techniques are used to check if the IDS/IPS can detect them.
6. fragmentedPackets: various fragmented payloads are sent to server to test its ability to recompose them and detect the attacks.
7. ipReputation: tests the ability of the server to detect traffic from/to low reputation servers.
8. normalUsage: Payloads that correspond to a normal usage.
9. pcapReplay: enables to replay pcap files
10. shellCodes: send various shellcodes to the server on port 21/tcp to test the ability of the server to detect/reject shellcodes.
11. testRules: basic rules testing. These attacks are supposed to be detected by the rules sets shipped with the IDS/IPS.

It is easily configurable and could integrate new modules in the future.

There are basically 5 types of tests:

1. socket: open a socket on a given port and send the payloads to the remote target on that port.
2. command: send command to the remote target with the subprocess.call() python function.
3. scapy: send special crafted payloads based on the Scapy syntax
4. client side attacks: use a reverse shell on the remote target and send commands to it to make them processed by the server (typically wget commands).
5. pcap replay: enables to replay traffic based on pcap files

Architecture

Remote mode

In this mode, the IDS is plugged on the span port (or port mirroring) of the core switch and is configured in promiscuous mode. The IDS analyzes all traffic that goes through the core switch. Malicious files can be downloaded either by pytbull or by the server. This mode is called “remote”.

Local mode

In this mode, files are downloaded on the client pytbull is started from.

IDS mode with attacked server in DMZ

In this configuration, a firewall splits the network into 3 parts (lan, wan, dmz). The IDS is plugged in a span port (or port mirroring) of the switch with its interface configured in promiscuous mode. It will analyze every traffic that is sent to the LAN interface of the firewall.

IPS mode

In this configuration, a firewall splits the network into 3 parts (lan, wan, dmz). The IDS is plugged between pytbull and the firewall. To give the IDS a chance to detect the malicious files, pytbull has to download the infected files itself.

IPS mode with attacked server in DMZ

In this configuration, a firewall splits the network into 3 parts (lan, wan, dmz). The IDS is plugged between pytbull and the firewall. Malicious files have to be downloaded by pytbull directly to give the IDS a chance to detect them.

Usage

If you have selected the clientSideAttacks module (see configuration file section for more information), you will need to start the reverse shell on the server. Following command uses port 34567/tcp:

$ ./pytbull-server.py -p 34567

Since the files are downloaded in the current directory, you can create a pdf/ directory and start pytbull from the parent location:

$ mkdir pdf/
$ cd pdf/
$ ../pytbull-server.py -p 34567

Then start pytbull (on the client side). An example to start pytbull tests against 192.168.100.48, running Snort:

$ sudo ./pytbull -t 192.168.100.48

Notice that you will need to adapt (config.cfg) the port used by the reverse shell if you use the optional parameter -p on remote side.

Download pytbull

Original Post: http://www.kitploit.com/2016/06/pytbull-intrusion-detectionprevention.html

UBER HACKING: HOW WE FOUND OUT WHO YOU ARE, WHERE YOU ARE AND WHERE YOU WENT!

“WHAT CAN BE MORE EXCITING THAN BEING AUTHORIZED TO TEST ONE OF THE MOST HYPED COMPANIES IN 2016?”

Here at Integrity we love to be challenged, so whenever there is some free time, there is encouragement to do research or to break some things (http://labs.integrity.pt/advisories/) in addition to play foosball.

We (@r0t1v, @fjreis, @fabiopirespt) decided to use this time to jump into some bug bounties.

What is a bug bounty?

As stated in wikipedia:

A bug bounty program is a deal offered by many websites and software developers by which individuals can receive recognition and compensation for reporting bugs, especially those pertaining to exploits and vulnerabilities. These programs allow the developers to discover and resolve bugs before the general public is aware of them, preventing incidents of widespread abuse.

For our luck, Uber decided to open their bug bounty program to the public, and in Portugal, Uber was almost a daily issue in the news because of the taxi drivers, so we dove right into this program.

After a couple of hours, we found out two open redirects that we reported right away. This could be the start of something good (we thought), but both issues were already reported by other researchers.

At first it was a bit disappointing, but not giving up we doubled back and decided to implement some processes/methodologies.

The process / Methodology

In order to implement some kind of methodology, we went back to the Uber bug bounty program to check again their scope, which is far extensive as it can be seen below:

• https://*.uber.com/
• http://*.uberinternal.com/ (added later into the program)
• http://petition.uber.org
• http://ubermovement.com
• iPhone Rider Application
• iPhone Partner Application
• Android Rider Application
• Android Partner Application

Information Gathering

To gather more information about Uber subdomains we started with a dns brute-force.

Example of subdomains retrieved with sublist3r

With all subdomains enumerated, all that was left to do was to use nmap and check for banners, page titles, page redirects as well as exploit-db and some blogs for known vulnerabilities.

For the mobile apps, jd-gui was used to read the java classes in order to map the mobile endpoints, later we also turned toMobSF.

API endpoints gathered with jd-gui

Now, judging from the information that we gathered, we felt that it was more than enough to start searching for some vulnerabilities.

Vulnerabilities

0×01 – Possibility to brute force promo codes in riders.uber.com

Uber has a feature that allows the usage of promotion codes. This codes can be given by other users or companies. The application riders.uber.com had this feature in the payment page, so after adding a new promotion code we grabbed the request and realised that the application didn’t had any kind of protection against brute-force attacks, which helped us to find many different promotion codes.

Promotions page form – without any promotion code applied

The image below illustrates our brute force attack. As stated before different codes were found and can be distinguished by their response.

Responses length:

• 1951 – Valid code
• 1931 – Not valid
• 1921 – Code Expired

Example of brute-force attack

Uber also gives an option to customize promotion codes, and since all the default codes began with the word “uber”, it was possible to drop the time of the brute force considerably allowing us to find more than 1000 valid codes.

Initially this issue was not considered valid because the promotions codes are supposed to be public and be given by anyone. This was true until finding an $100 ERH (Emergency Ride Home) code which they (uber-sec team) had no knowledge about. This ERH codes work differently from all others since even if a promotion code is already applied this ones can still be added.

Vulnerable form with ERH code applied

DISCLOSURE TIMELINE

March 23, 2016 – Bug reported to Uber
March 23, 2016 – Uber’s team changed status to Informative
March 24, 2016 – We provided new information
March 24, 2016 – Uber’s team changed status to Triaged
April 19, 2016 – Uber’s team changed status to Resolved
May 2, 2016 – Uber rewarded us with a bounty.

0×02 – Possibility to get private email using UUID

As you can see in the picture below, inside Uber riders mobile application there is a “Help” section that allow users to send questions directly to support. Let’s be honest, many of us almost never use the “Help” or even know that it exists, but as pentesters we can’t say no to another form. (later we found that the Partners application had the same forms).

Help feature

After submitting a question, the server would reply with the message: “We’ve received your request and will be in touch as soon as possible via <my-email-address>”. Looking at this message we thought that maybe we could enumerate some user emails.

Request sending uuid instead of token

By looking at the request there are two places (the x-uber-uuid header and the uuid parameter) that  might allow us to get emails from other users if we change them for another valid UUID. We tried to change both, but unfortunately the server returned our email again. Although there is a token parameter also, our first approach was to fuzz a bit into this parameter but in the end we end up by changing it to another user UUID and something magic happened, the webserver returned the email address for that user.

Server replied with email associated to uuid

It’s a bit hard to say why a UUID has been interpreted as a valid token, but it is indeed.

Since the application wasn’t throttling our requests in this endpoint, we grabbed a small amount of UUIDs and with them we were able to get all the emails corresponding to those UUIDs. Now you’re probably asking: “how can you know UUIDs from other users?”, that’s what we will explain later.

DISCLOSURE TIMELINE

March 31, 2016 – Bug reported to Uber
March 31, 2016 – Uber’s team changed status to Triaged
April 11, 2016 – Uber’s team changed status to Resolved
April 13, 2016 – Uber rewarded us with a bounty.

0×03 – Enumerating UserIDs with phone numbers (duplicated)

When looking for vulnerabilities we always try to find all of the application/webapp features, especially those that aren’t easily found or used. With this in mind, we decided to get our phones, computers and called for a Uber and so we did. During our trip we intercepted all the requests and one of those requests caught our attention.

Request inviting to split the fare

This request happens when an user tries to split his fare with others. To invite someone to split the fare, the user needs to add a phone number from his contact list.

The problem here is that the response is leaking too much information such as driver UUID, invitees UUIDs and the invitees picture, even before they accepting the fare split.

You can see the app leaking the information in the pictures below:

Response leaking information about invited user [1/2]Response leaking information about invited user [2/2]

Remember before when we told you that we would explain how we got a list of UUIDs? This is how!

Now, joining this vulnerability with the previous one we could get anyones email address that was associated to the phone number.

Unfortunately, after reporting this issue, it was marked as duplicated.

DISCLOSURE TIMELINE

April 6, 2016 – Bug reported to Uber
April 7, 2016 – Uber’s team changed status to Needs more info
April 7, 2016 – We provided new information
April 7, 2016 – Uber’s team changed status to Duplicate

0×04 – Use Partner/Driver App Without Being Activated (duplicated)

Every user is able to create a driver account but it remains not activated until Uber verify all your driver documents.

After started to test the Partner/Driver app, we realized that you can only enter in the mobile app after the activation process.

“Driver account not activated” response

Looking on the request of the response above, you can see a parameter called allowNotActivated and his value wasfalse.

Request with new value on “allowNotActivated” parameter

By manipulating the login request and changing the parameter allowNotActivated to true, it was possible to obtain a valid session token. So at least, it means that the server create a valid token even when the account was not activated.

New token created

As you can see on the response, there is a field called isActivated setted to false. Changing this to true allowed us to get into the app.

Interface of Partners mobile application

Now we got a couple of new features to test.

DISCLOSURE TIMELINE

March 31, 2016 – Bug reported to Uber
March 31, 2016 – Uber’s team changed status to Needs more info.
March 31, 2016 – We provided new information
April 7, 2016 – Uber’s team changed status to Duplicated

0×05 – Possible to View Driver Waybill via Driver UUID

Using the previous vulnerability we were able to test a new functionality called waybill. By crafting the request that the app sends, we notice that it has a broken access control vulnerability that allowed us to see the last trip from every driver, by only knowing his uuid.

Request for waybill of other driver

To get a driver UUID you can, for example, request a random car, let the driver accept the trip and after this you cancel it. In the meanwhile you are able to capture the driver UUID.

In the response of this request, we were able to get the driver name, license plate, last tripUUID, last passenger name, number of passengers, the origin and destination of the trip.

Detailed response of driver’s waybill

Notice the TRIP # in this response? To get the full path of the trip, we ended up discovering a new functionality that returns the full path of the trip, the driver name, client name, license plate and even the car model.

This functionatility  could not be detailed in this moment, but as soon as we are authorized, we will talk about it.

Full path of the trip

DISCLOSURE TIMELINE

March 31, 2016 – Bug reported to Uber
April 1, 2016 – Uber’s team changed status to Triaged
April 13, 2016 – Uber’s team changed status to Resolved
April 18, 2016 – Uber rewarded us with a bounty.

0×06 – Information regarding trips from other users

Remember the vulnerability 0×03 where we found out that by changing the token by a UUID we could impersonate another user?

Requesting trips associated to uuid (in the token)

The request above allow an user to view the trips made by himself. Notice that in the request there is any session headers or session cookies. All the **session** details are sent via GET parameters.

By changing the highlighted uuid and maintaining the original token, the server return a 403 unauthorized access. If we change the UUID and the token for the UUID of the user that you want to see the trips, we get a bunch of new information

This was the response when asking for trips by sending the same value in UUID and TOKEN fields.

List of trips associated to the UUID

As it can be seen we were able to get the date of the trip, driver name and picture, the id and cost of the trip and the map of where he have been.

The response above only demonstrate one single trip, but the full response gives us all the trips made by the user.

DISCLOSURE TIMELINE

March 31, 2016 – Bug reported to Uber
March 31, 2016 – Uber’s team changed status to Triaged
April 5, 2016 – Uber’s team changed status to Resolved
April 13, 2016 – Uber rewarded us with a bounty.

What about profits?

DUPLICATED VULNERABILITIES

#	Vulnerability	Reported at
1	Open Redirect in trip.uber.com	23/03/2016
2	Open Redirect in riders.uber.com	23/03/2016
3	Possibility to enumerate users via getrush.uber.com and bruteforce login via iOS app to get a valid account	26/03/2016
4	Possibility to download beta app as admin (Riders app IOS)	30/03/2016
5	Use Partner/Driver App Without Being Activated	31/03/2016
6	Enumerating userIDs with phone numbers	06/04/2016

TRIAGED/CLOSED VULNERABILITIES

#	Vulnerability	Reported at	Bounty
1	Possibility to brute force invite codes in riders.uber.com	23/03/2016	Paid
2	To be disclosed	24/03/2016	Waiting..
3	To be disclosed	25/03/2016	Waiting..
4	Possible to View Driver Waybill via Driver UUID	31/03/2016	Paid
5	Possibility to get private email using UUID	31/03/2016	Paid
6	Information regarding trips from other users	31/03/2016	Paid
7	To be disclosed	07/04/2016	Waiting..
8	To be disclosed	13/04/2016	Waiting..

Conclusion

This was our first bug bounty program that we really dedicated some time, and we think it had a positive outcome. At the beginning we weren’t too confident with this program because a lot of people had already tested Uber in the private program, but after some time and when we started to find some good vulnerabilities it gave us the drive to continue and see where it could lead us.

For the people who are starting the bug bounty programs, our advice is: never give up or be afraid if it is a big company, just have fun and try to learn as much as possible along the way and in time the profits will come.

As a final note to our article, we want to say that Uber should provide testing accounts to bug hunters. During our tests we did have our accounts being locked due to the nature of our tests and to unlock them, it was a bit of a nightmare. At that moment we tried to talk with Uber support team and they didn’t helped much, so the only thing to do was to try to talk with the security team directly. In this case we have to say that they did help, and much! (A big thank you to all of them).

With this being said, we think that Uber has one of the best bug bounty programs, with great payouts.

From a pentester’s view, the security team takes this program very seriously by trying to resolve all the issues as fast as they can.

Original Post: https://labs.integrity.pt/articles/uber-hacking-how-we-found-out-who-you-are-where-you-are-and-where-you-went/

Faraday v1.0.20 – Pen Test Environment (IPE)

Faraday introduces a new concept (IPE) Integrated Penetration-Test Environment

a multiuser Penetration test IDE. Designed for distribution, indexation and analysis of the generated data during the process of a security audit.

The main purpose of Faraday is to re-use the available tools in the community to take advantage of them in a multiuser way.

Design for simplicity, users should feel no difference between their own terminal application and the one included in Faraday. Developed with a specialized set of functionalities that help users improve their own work. Do you remember yourself programming without an IDE? Well, Faraday does the same an IDE does for you when programming, but from the perspective of a penetration test.

 

A brand new Faraday version is ready! Faraday v1.0.20 is here, bringing more functionality to our GTK interface and other cool new features.
Changelog v1.0.20

• Fixed bugs in plugins: Acunetix – Nmap – Nikto
• Removed description from Hosts list in web UI
• Fixed sort in Hosts list in web UI
• Fixed ports sorting in Host view in web UI
• Added search link for OS in Hosts list in web UI
• Removed description from Services list in web UI
• Added version to Services list in web UI
• Modified false values in Hosts list in web UI
• Added search links in Services list in web UI
• Added scrollbar in Gtk Terminal
• Added workspace status in Gtk interface
• Added conflict resolution support for the Gtk interface
• Added search entry for workspaces in Gtk
• Added support for ‘exit’ command inside Faraday’s Gtk terminal
• Improved handling of uncaught exceptions in Gtk interface
• Improved text formatting in Gtk’s log console
• Fixed several small bugs in Faraday GTK
• Added support for resize workspace bar
• Added a quote for imported reports in web UI
• Added support for a new type of report in Qualysguard plugin

Full Changelog: here

Download Faraday v1.0.20

Original Post: http://www.toolswatch.org/2016/06/faraday-v1-0-20-pen-test-environment-ipe/

How To Find Wi-Fi Password Using CMD Of All Connected Networks

 

It is very easy to find WiFi password using few cmd commands. This command works even when you are offline or you are connected to some other WiFi network. Using this command, we can further optimize our particular WiFi network like turning on some features such as mac randomization, changing the radio type of your WiFi etc.

Whenever we connect to a WiFi network and enter the password to connect to that network, we actually make a WLAN profile of that WiFi network. That profile is stored inside our computer along with the other required details of the WiFi profile.

Instead of using a GUI to find the individual passwords, we can also look for the WiFi password of that particular WiFi network using cmd.These steps work even when you are totally offline or you are not connected to the particular wifi you are looking the password for.

How to know the WiFi password using cmd:

• Open the command prompt and run it as administrator.

• In the next step, we want to know about all the profiles that are stored in our computer. So, type the following command in the cmd:

netsh wlan show profile

This command will list out all the WiFi profiles that you have ever connected to.

In the above picture, I have intentionally blurred some of my WiFi networks’ name. As you can see, there are eight WiFi networks that I connect to. So, let’s go and find out the password for the WiFi ‘NETGEAR50’ in this case which I created intentionally for this article.

Want to learn Wi-Fi hacking? Get started here.

• Type the following command to see the password of any WiFi network:

netsh wlan show profile WiFi-name key=clear

• Under the security settings, in the ‘key content’, you see the WiFi password of that particular network.

Besides knowing the password, you can also use this result to further optimize your WiFi. For example, Under the profile information, you can see mac randomization is disabled. You can turn on mac randomization feature to avoid your location tracking based on the device’s MAC address.

Here is how to turn on mac randomization on Windows 10:

• Go to settings and click on ‘Network & internet’
• Choose the ‘WiFi’ in the left pane and click on the advanced option.

• Turn on the ‘Random Hardware Address’ feature under this settings. If your wireless hardware does not support this feature, the “Random Hardware Addresses” section will not show up at all in the settings app.
• Once you have turned this on, you are done.

Also, under the connectivity settings, in radio type, you can see the whole list. Channel interference could be another reason for a slow WiFi. So, next time, you might also like to change the radio type settings for a better speed.

As far as radio type is concerned, you can also change that in your router for a better connection or connectivity. For this purpose, we have a dedicated article on to increase WiFi speed by choosing correct WiFi channel.

Original Post: http://fossbytes.com/find-wifi-password-connected-networks-cmd-windows/