Darknet - The Darkside

Don`t Learn to HACK - Hack to LEARN. That`s our motto and we stick to it, we are all about Ethical Hacking, Penetration Testing & Computer Security. We share and comment on interesting infosec related news, tools and more. Follow us on Twitter, Facebook or RSS for the latest updates.

08 October 2014 | 2,212 views

IPFlood – Simple Firefox Add-on To Hide Your IP Address

Check Your Web Security with Acunetix

IPFlood (previously IPFuck) is a Firefox add-on created to simulate the use of a proxy. It doesn’t actually change your IP address (obviously) and it doesn’t connect to a proxy either, it just changes the headers (that it can) so it appears to any web servers or software sniffing – that you are in fact using a proxy.

IPFlood (previously IPFuck) - Simple Firefox Add-on To Hide Your IP Address

This add-on is a “proof of concept” to show anyone who isn’t already aware that IP address has become obsolete and that no one should use an IP address as an evidence any more. This plug-in is just one of many ways to spoof an IP address and these spoofing could lead to outrageous accusation of innocents.

How does it work?

You can imagine that if I could just overwrite any existing information about your IP address I would have done so (or somebody else would have a while back ago)…

But it’s actually a little more tricky : when sending a request to a server you will provide several information about your IP address : three of them come from the Application Layer and the last one comes from the Transport Layer. This last one I can’t modify : you wouldn’t get the answer to your request if that was done. But the three others can be overwritten without any consequence to your browsing…

These three headers were created to provide information on the real IP of a person surfing through a proxy server. So when you enable IPFuck, the websites you are visiting will believe that your real IP is a proxy server and (if the website was done correctly) focus on the false IP you are sending…

A lot of websites try and figure out who is hiding behind a proxy server. And if you don’t believe me (I won’t mind), just check out this Google search request : get real ip address php. Most of the snipplets given here will check HTTP headers (the one we overwrite) before the Transport Layer information (‘REMOTE_ADDR’).

You can install IPFlood (previously IPFuck) for Firefox here:

ipflood-1.2.1-fx.xpi

Or read more here.



06 October 2014 | 1,153 views

JPMorgan Hacked & Leaked Over 83 Million Customer Records

So yah last week we all discovered, OMG JPMorgan Hacked! This set a lot of people on edge as JPMorgan Chase & Co is the largest US bank by assets – so it’s pretty seriously business. The breach happened back in July and was only disclosed last Thursday due to a filing to the US Securities and Exchange Commission.

JPMorgan Hacked

This is a HUGE breach (76 million households and 7 million small businesses), one of the biggest in history – especially when it comes to the banking sector. Fortunately no really ‘critical’ data was leaked such as credit card details or social security numbers, but there was important information like addresses and phone numbers which at this volume are definitely valuable on the black market.

The July cyberattack on JPMorgan Chase & Co. that compromised the names, addresses, phone numbers and contact information of over 83 million people are believed to have originated in Russia with at least some level of state approval.

“It could be in retaliation for the sanctions” placed on Russia, one senior official briefed on the intelligence told The New York Times on Saturday. “But it could be mixed motives — to steal if they can, or to sell whatever information they could glean.”

JPMorgan Chase has worked with the Treasury, the Secret Service and intelligence agencies since the attack, which did not completely shut out the attackers until August, the paper reported. More than 90 servers were accessed and over 7 million small businesses were compromised.

There’s a lot of speculation that the hackers that pulled of this rather sophisitacted attack are Russian and somehow linked to Putin (although I’m not sure how they figured that out). The news also broke today that it was not only JPMorgan Chase & Co that was infiltrated – but they were just 1 of 9 financial institutions breached as part of this attack.

This includes banks and brokerages, more here: JPMorgan CYBER-HEIST: 9 US financial firms snared by ‘Russian hackers’, says report

“It was a huge surprise that they were able to compromise a huge bank like JPMorgan,” said Al Pascual, a security analyst with Javelin Strategy and Research, told the Times. “It scared the pants off many people.”

Experts fears that similar attacks in the future could ignite a financial crisis. JPMorgan Chase may be particularly vulnerable: The Times noted that the hackers were able to steal “a list of every application and program deployed on standard JPMorgan computers that hackers can crosscheck with known, or new, vulnerabilities in each system in a search for a backdoor entry.”

JPMorgan Chase has responded to the hacking by disabling compromised accounts and resetting passwords for its employees. The company also notified customers that they would not need to change their passwords or account information, nor would they be held liable for unauthorized transactions, The Associated Press reported Thursday.

It’s interesting that the hackers didn’t seem to go after the money, they really just wanted as much data as possible on JPMorgan customers.

It’ll be interesting to see if any of the other currently unnamed financial institutions are released to the press or if any of them suffered monetary losses – or they were all similar data grab scenarios.

Source: The Washington Times


03 October 2014 | 2,814 views

iSniff-GPS – Passive Wifi Sniffing Tool With Location Data

iSniff GPS is a passive wifi sniffing tool which sniffs for SSID probes, ARPs and MDNS (Bonjour) packets broadcast by nearby iPhones, iPads and other wireless devices. The aim is to collect data which can be used to identify each device and determine previous geographical locations, based solely on information each device discloses about previously joined WiFi networks.

iSniff-GPS - Passive Wifi Sniffing Tool

iOS devices transmit ARPs which sometimes contain MAC addresses (BSSIDs) of previously joined WiFi networks, as described in here: Anatomy of a leak: how iPhones spill the ID of networks they access. iSniff GPS captures these ARPs and submits MAC addresses to Apple’s WiFi location service (masquerading as an iOS device) to obtain GPS coordinates for a given BSSID. If only SSID probes have been captured for a particular device, iSniff GPS can query network names on wigle.net and visualise possible locations.

By geo-locating multiple SSIDs and WiFi router MAC addresses, it is possible to determine where a device (and by implication its owner) is likely to have been.

Components

iSniff GPS contains 2 major components and further python modules:

  • iSniff_import.py uses Scapy to extract data from a live capture or pcap file and inserts it into a database (iSniff_GPS.sqlite3 by default).
  • A Django web application provides a browser-based interface to view and analyse the data collected. This includes views of all detected devices and the SSIDs / BSSIDs each has probed for, a view by network, Google Maps views for visualising possible locations of a given BSSID or SSID, and a pie chart view showing a breakdown of the most popular device manufacturers based on client MAC address Ethernet OUIs.
  • wloc.py provides a QueryBSSID() function which looks up a given BSSID (AP MAC address) on Apple’s WiFi location service. It will return the coordinates of the MAC queried for and usually an additional 400 nearby BSSIDs and their coordinates.
  • wigle.py provides a getLocation() function for querying a given SSID on the wigle.net database and returns GPS coordinates. It must be configured with a valid wigle.net auth cookie. Please respect the wigle.net ToS in using this module.

You can download iSniff-GPS here:

master.zip

Or read more here.


02 October 2014 | 2,731 views

OpenVPN Vulnerable To Shellshock Exploit

So last week the big news was about the cross platform exploit in BASH that we covered in our article – Everything You NEED To Know About Shellshock Bug In BASH.

As mentioned in the comments, a certain combination of circumstances and configuration options can leave OpenVPN vulnerable to Shellshock.

OpenVPN Vulnerable To Shellshock Exploit

This could be a pretty serious issue as I’m sure there are thousands of OpenVPN servers sitting around fairly idle, that are unlikely to be updated and around about to get pwned. If the OpenVPN is using system level pre-auth with the auth-user-pass-verify option – they will be in trouble.

The Shellshock Bash bug, the gift that just keeps on taking, could also sting OpenVPN users, according to researcher Fredrick Stromberg. Pre-authentication vectors affect communication through the popular and formerly secure VPN platform, he says.

Shellshock affected the crucial and ubiquitous *nix component Bash up to and including version 4.3. Mullvad chief technology officer Stromberg described the flaw in a forum post overnight, adding that he disclosed the vulnerability to OpenVPN sometime last week.

“OpenVPN servers are vulnerable to Shellshock under certain configurations,” Stromberg said. “OpenVPN has a number of configuration options that can call custom commands during different stages of the tunnel session. Many of these commands are called with environmental variables set, some of which can be controlled by the client.

“One option used for username+password authentication is auth-user-pass-verify. If the called script uses a vulnerable shell, the client simply delivers the exploit and payload by setting the username. This attack vector is pre-auth.”

There’s a whole list of Shellshock PoCs here on Github including the one for OpenVPN – Shellshocker PoCs. The exploit walkthrough is available here, including the OpenVPN config and log output – OpenVPN ShellShock PoC.

I’m honestly not sure how much impact this will actually have in the wild as to know that we’d have to know how common it is for OpenVPN systems to auth in this manner.

A proof of concept for the exploit has surfaced online. Those using OpenVPN can dodge Shellshock by preventing Bash from running scripts. OpenVPN’s Gert Doering told Threat Post OpenVPN was vulnerable only on systems where /bin/sh points to /bin/bash, or when scripts running bash as an interpreter were called explicitly.

“What you want to do from OpenVPN’s point of view is to ensure that you’re not using a 2.2.x version anymore, and that you just do not run your scripts using bash (#!/bin/bash) but use a shell that is better suited to script usage, like ash/dash,” Doering told the publication. “Also, always use client certificates, as the username verification script that is the attack vector here is only called after successful verification of a client cert.”

Vendors have released solid and borked patches for the Shellshock bug over the last week since the flaw was revealed. The patching prompted Blighty’s privacy watchdog to urge organisations patch their Bash instances

Apple has issued a patch for the smaller subset of affected users, while F5 has moved to stop holes in its line of BIG-IP products including the ARX, Enterprise Manager and BIG-IQ systems, but not FirePass or LineRate proxy systems. Stromberg in April identified the susceptibility of OpenVPN to the HeartBleed vulnerability.

The OpenVPN systems will only be vulnerable if /bin/sh points to /bin/bash and if they don’t use an alternative (more suitable) shell like ash/dash (which is the default shell in Debian systems).

There are also other vectors being exposed like QNAP NAS devices (which was one of my worries), anything Linux based with BASH that is unlikely to get updated is at fairly high risk:

Shellshock Attacks Hit Major NAS Kit; IoT Next?

Shellshock – the bug that just keeps on giving.

Source: The Register


29 September 2014 | 3,855 views

masscan – The Fastest TCP Port Scanner

masscan is the fastest TCP port scanner. It can scan the entire Internet in under 6 minutes, transmitting 10 million packets per second.

It produces results similar to nmap, the most famous port scanner. Internally, it operates more like scanrand, unicornscan, and ZMap, using asynchronous transmission. The major difference is that it’s faster than these other scanners. In addition, it’s more flexible, allowing arbitrary address ranges and port ranges.

masscan - The Fastest TCP Port Scanner

NOTE: masscan uses a custom TCP/IP stack. Anything other than simple port scans will cause conflict with the local TCP/IP stack. This means you need to either use the -S option to use a separate IP address, or configure your operating system to firewall the ports that masscan uses.

PF_RING – Beyond 2 million packets/second

To get beyond 2 million packets/second, you need an Intel 10-gbps Ethernet adapter and a special driver known as “PF_RING DNA” from http://www.ntop.org/products/pf_ring/. Masscan doesn’t need to be rebuilt in order to use PF_RING. To use PF_RING, you need to build the following components:

  • libpfring.so (installed in /usr/lib/libpfring.so)
  • pf_ring.ko (their kernel driver)
  • ixgbe.ko (their version of the Intel 10-gbps Ethernet driver)

You don’t need to build their version of libpcap.so.

When masscan detects that an adapter is named something like dna0 instead of something like eth0, it’ll automatically switch to PF_RING mode.

Usage

Usage is similar to nmap. To scan a network segment for some ports:

This will:

  • scan the 10.x.x.x subnet, all 16 million addresses
  • scans port 80 and the range 8000 to 8100, or 102 addresses total
  • print output to that can be redirected to a file

To see the complete list of options, use the –echo feature. This dumps the current configuration and exits. This output can be used as input back into the program:

Banner checking

Masscan can do more than just detect whether ports are open. It can also complete the TCP connection and interaction with the application at that port in order to grab simple “banner” information.

The problem with this is that masscan contains its own TCP/IP stack separate from the system you run it on. When the local system receives a SYN-ACK from the probed target, it responds with a RST packet that kills the connection before masscan can grab the banner.

The easiest way to prevent this is to assign masscan a separate IP address. This would look like the following:

The address you choose has to be on the local subnet and not otherwise be used by another system.

In some cases, such as WiFi, this isn’t possible. In those cases, you can firewall the port that masscan uses. This prevents the local TCP/IP stack from seeing the packet, but masscan still sees it since it bypasses the local stack. For Linux, this would look like:

On Mac OS X and BSD, it might look like this:

Windows doesn’t respond with RST packets, so neither of these techniques are necessary. However, masscan is still desigend to work best using its own IP address, so you should run that way when possible, even when its not strictly necessary.

The same thing is needed for other checks, such as the –heartbleed check, which is just a form of banner checking.

You can download masscan here:

1.0.3.zip

Or read more here.


26 September 2014 | 3,921 views

Everything You NEED To Know About Shellshock Bug In BASH

Shellshock (CVE-2014-6271) the bug in BASH is causing havoc on the Internet this week, as far as I’m concerned it’s a bit overstated – seriously how many people are still using cgi scripts? None I hope. I do suspect though a lot of shared hosts might get owned by this as most commercial control panel software installs a /cgi-bin/ and sometimes a script by default.

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution, aka “ShellShock.” NOTE: the original fix for this issue was incorrect; CVE-2014-7169 has been assigned to cover the vulnerability that is still present after the incorrect fix.

Shellshock Bug In BASH

We’ve been so focused on buffer overflows and memory stack bugs during the past decade, we’re currently getting owned by bugs from the 90s – which once again shows the need for proper code auditing on Open Source projects (and donations/budget allocations for such activities).

The other risk profile I see exposed here is devices like routers/proxy boxes and so on that use some type of trimmed down regular Linux with BASH. I’ve seen some comments from the embedded community that this shouldn’t be an issue for them as they tend to use BusyBox which is not vulnerable.

To test for the vulnerability on your *nix systems just issue the following command as any user (doesn’t have to be root):

If you see this:

It’s vulnerable, if it’s fixed or not vulnerable you should see this:

As far as the risk, I definitely don’t think it’s a 10/10 risk vulnerability, although there already 2 worms in the wild exploiting this bug to build botnets. I don’t think any reasonably well secured server will fall foul to this though, even without BASH updated it shouldn’t be an issue.

But if you do find a vulnerable system with a cgi script, it’s trival to exploit and get a reverse shell with code such as this:

I pretty much exclusitely use nginx so I don’t have the issues many will have, if you use Apache and have mod_cgi enabled – you may well be in trouble. Look out for servers with FTP/Telnet/Apache with something like Masscan and sort them out as your primary/production systems are pretty safe without any updates/changes.

Some views/updates from others:

The vulnerability is present in Bash up to and including version 4.3, and was discovered by Stephane Chazelas. It puts Apache web servers, in particular, at risk of compromise: CGI scripts that use or invoke Bash in any way – including any child processes spawned by the scripts – are vulnerable to remote-code injection. OpenSSH and some DHCP clients are also affected on machines that use Bash.

The Register

It can be exploited by attackers looking to override or bypass environment restrictions to execute shell commands, i.e. unauthorized, malicious code.

The flaw is deemed critical for many reasons. For one, the number of affected devices is huge: think about all the web servers (including Apache ones) and embedded devices (routers, etc.) running on Linux, Mac computers… The number could very well be in the hundreds of millions.

Secondly, the US-CERT and NIST gave it the maximum score (10.0) for both impact and exploitability. Exploitation of the flaw can lead to unauthorized disclosure of information, unauthorized system access and modification, and disruption of service, and the exploitation process is extremely short and simple: it takes just a few lines of code.

Helpnet Security

According to several security firms, attackers are already probing systems for the weakness, and that at least two computer worms are actively exploiting the flaw to install malware. Jamie Blasco, labs director at AlienVault, has been running a honeypot on the vulnerability since yesterday to emulate a vulnerable system.

“With the honeypot, we found several machines trying to exploit the Bash vulnerability,” Blasco said. “The majority of them are only probing to check if systems are vulnerable. On the other hand, we found two worms that are actively exploiting the vulnerability and installing a piece of malware on the system. This malware turns the systems into bots that connect to a C&C server where the attackers can send commands, and we have seen the main purpose of the bots is to perform distributed denial of service attacks.”

Krebs on Security

Today’s bash bug is as big a deal as Heartbleed. That’s for many reasons.

The first reason is that the bug interacts with other software in unexpected ways. We know that interacting with the shell is dangerous, but we write code that does it anyway. An enormous percentage of software interacts with the shell in some fashion. Thus, we’ll never be able to catalogue all the software out there that is vulnerable to the bash bug. This is similar to the OpenSSL bug: OpenSSL is included in a bajillion software packages, so we were never able to fully quantify exactly how much software is vulnerable.

The second reason is that while the known systems (like your web-server) are patched, unknown systems remain unpatched. We see that with the Heartbleed bug: six months later, hundreds of thousands of systems remain vulnerable. These systems are rarely things like webservers, but are more often things like Internet-enabled cameras.

Robert Graham

If you are running Mac OS X it’s not so trivial to fix, even if you run Homebrew, updating that will only update Homebrew BASH and not system BASH which still leaves you vulnerable if you have any public web services. If you don’t run any public web services from your Mac (like most people) you don’t have much to worry about. Some reading:

How to patch Bash on OSX in wake of “shellshock”?
How to patch your vulnerable OS X to latest bash issue (for advanced users)

If you running Ubuntu on your production systems (like me) the update/patch is trivial:

If you only want to upgrade BASH and not mess with your packages then just do:

The reboot might not strictly be necessary, but honestly I prefer to be safe than sorry.

So what’s the downlow? Are a lot of huge websites going to get owned and is half the Internet going to go dark? No. Are a lot of old devices/servers/unloved pieces of equipment/shared hosting servers going to get owned and turned into members of Botnets? Yes most likely.

Is this going to effect the average consumer? No not really, does it effect the average company? Probably yes it will, but not at the core of your production systems which should be fairly immune to this vulnerability.

But it’s fairly easy to patch, so why not – if you can do it without disrupting your business too much – just patch.

We’ll have to wait a couple of weeks to see where this really goes, and see if it’s really as disruptive as Heartbleed was.


24 September 2014 | 1,387 views

drozer – The Leading Security Testing Framework For Android

drozer (formerly Mercury) is the leading security testing framework for Android. drozer allows you to search for security vulnerabilities in apps and devices by assuming the role of an app and interacting with the Dalvik VM, other apps’ IPC endpoints and the underlying OS.

drozer - Android Security Testing Framework

drozer provides tools to help you use, share and understand public Android exploits. It helps you to deploy a drozer Agent to a device through exploitation or social engineering. Using weasel (MWR’s advanced exploitation payload) drozer is able to maximise the permissions available to it by installing a full agent, injecting a limited agent into a running process, or connecting a reverse shell to act as a Remote Access Tool (RAT).

drozer helps to reduce the time taken for Android security assessments by automating the tedious and time-consuming. In a way you could think of drozer as Metasploit for Android devices.

  • Discover and interact with the attack surface exposed by Android apps.
  • Execute dynamic Java-code on a device, to avoid the need to compile and install small test scripts.

Features

  • Discover Installed Packages
  • Send Intents to IPC Endpoints
  • Broadcast Intents
  • Access Databases from other Apps
  • Interact with Services in other Apps
  • Arbitrary Java Execution
  • Run an Interactive Shell
  • Access a device with Remote Exploits
  • Root Privilege Escalation
  • Command-line Interface
  • Use drozer with Physical Devices
  • Use drozer with Android Emulators

You can download drozer here:

Windows installerdrozer-installer-2.3.3.zip
Debian/Ubuntu (.deb)drozer_2.3.3.deb
Redhat/CentOS (.rpm)drozer-2.3.3-1.noarch.rpm

Or read more here.


23 September 2014 | 1,481 views

CloudFlare Introduces SSL Without Private Key

Handing over your private key to a cloud provider so they can terminate your SSL connections and you can work at scale has always been a fairly contentious issue, a necessary evil you may say.

As if your private key gets compromised, it’s a big deal and without it (previously) there’s no way a cloud provider or load balancing service could terminate your SSL connections and complete the secure handshake with a users browser.

CloudFlare Introduces SSL Without Private Key

Until now, CloudFlare presents a fairly intelligent solution – which has taken them 2 years to develop – but solves most problems with the current situation.

Content delivery network and web security provider CloudFlare has introduced a new feature that allows customers to take advantage of the company’s solutions without ever having to hand over their private SSL keys.

Private SSL keys are highly sensitive because they can be leveraged by a malicious actor to spoof an organization’s identity and intercept traffic. That is why, over the past two years, CloudFlare has been working on introducing keyless SSL.

The idea emerged after CloudFlare had a meeting in the fall of 2012 with representatives of a major bank, which at the time was targeted with distributed denial-of-service (DDoS) attacks by alleged Iranian hackers of the Izz ad-Din al-Qassam Cyber Fighters group.

“The bankers all acknowledged what they needed was a cloud-based solution that could scale to meet the challenges they faced. Unfortunately, since they needed to support encrypted connections, that meant the cloud-based solution needed to terminate SSL connections,” Matthew Prince, the CEO and co-founder of CloudFlare, wrote in a blog post.

Losing an SSL key is considered a critical security event which, as Prince describes it, could turn into a “nightmare,” and financial institutions can’t afford to take such risk. CloudFlare has been working since the 2012 meeting with the bank representatives on finding a practical way of helping organizations benefit from the cloud without the need to take possession of their SSL keys.

I honestly think the whole SSL certificate process is pretty broken, really it needs a major rework – but I’m not exactly sure what the solution is. At least what CloudFlare has come out with is a solution to one part of the problem.

It seems fairly obvious in some ways, run an agent inside the secure infrastructure of the client, have very limited access to the agent to access the key. But it’s always obvious when someone else thought of it, isn’t it?

One of CloudFlare’s engineers came up with a solution by the next day, but it took two years to perfect the solution and make it secure, fast and scalable.

“To make it work, we needed to hold connections open between CloudFlare’s network and agents running on our customers’ infrastructure. Moreover, we needed to share data about crytographic sessions setup for a visitor between all the machines that could serve that visitor,” Prince explained. “Making it work was one thing, making it fast was another. And, today, Keyless SSL clients are experiencing 3x+ faster SSL termination globally using the service than they were when they were relying only on on-premise solutions.”

On Friday, CloudFlare security engineer Nick Sullivan published a blog post providing technical details on how they’ve managed to achieve keyless SSL.

“We’ve seen how private keys can be stolen, and investing in techniques to limit their exposure makes the Internet a safer place. Our review of Keyless SSL indicates the keys themselves do not leave your infrastructure, and a secure channel with CloudFlare both protects the communication and reduces the attack surface for your key,” a spokesperson from NCC Group’s Cryptography Services group commented.

“One of the core principles of computer security is to limit access to cryptographic keys to as few parties as possible, ideally only the endpoints. Application such as PGP, Silent Circle, and now Keyless SSL implement this principle and are correspondingly more secure,” Jon Callas and Phil Zimmermann of encrypted communications firm Silent Circle said in a joint statement.

There’s a nice technical post with details of the implementation here: Keyless SSL: The Nitty Gritty Technical Details

It’s only just been launched, so it’s too early to see if anyone has figured out how to hack it yet. As obviously, if the agent can be discovered and is insecure – it can compromise the client infrastructure and the private key.

Source: SecurityWeek


20 September 2014 | 3,880 views

tinfoleak – Get Detailed Info About Any Twitter User

tinfoleak is basically an OSINT tool for Twitter, there’s not a lot of stuff like this around – the only one that comes to mind in fact is creepy – Geolocation Information Aggregator.

tinfoleak is a simple Python script that allow to obtain:

  • basic information about a Twitter user (name, picture, location, followers, etc.)
  • devices and operating systems used by the Twitter user
  • applications and social networks used by the Twitter user
  • place and geolocation coordinates to generate a tracking map of locations visited
  • show user tweets in Google Earth!
  • download all pics from a Twitter user
  • hashtags used by the Twitter user and when are used (date and time)
  • user mentions by the the Twitter user and when are occurred (date and time)
  • topics used by the Twitter user

tinfoleak

You can filter all the information by:

  • start date / time
  • end date / time
  • keywords

You can download tinfoleak here:

tinfoleak-1.2.tar.gz

Or you can read more here.


18 September 2014 | 731 views

Twitter Vulnerability Allows Deletion Of Payment Details

Twitter has been in the news a lot lately, firstly about their patent filing regarding the pro-active scanning on the web for malware and then the bug bounty going live – which is related to this story.

This is a pretty neat Twitter vulnerability that was discovered by someone taking part in the Twitter bug bounty program that we wrote about earlier this month.

Twitter Vulnerability

It’s not a massively dangerous vulnerability, in terms of the average Twitter user – but it could have been very disruptive to Twitter itself if undiscovered as a malicious user could have removed payment details from any account it could find the username/account ID for.

A researcher has uncovered a vulnerability on one of Twitter’s subdomains that could have been exploited to delete all the payment cards used by customers to pay for advertisements.

Companies and individuals that want to run ad campaigns on Twitter’s platform are required to add a payment card to their account. Egyptian security researcher Ahmed Aboul-Ela discovered multiple Insecure Direct Object Reference flaws that could have been leveraged by an attacker to delete the cards associated with Twitter Ads.

Aboul-Ela identified the first vulnerability after analyzing the POST request sent to the server when the “Delete this card” button is clicked. The request contained the parameters “account,” the ID of the Twitter account, and ” id,” a 6-digit number associated with the customer’s credit card. By changing the value of these parameters to one of a different account he owns, the researcher managed to delete the card.

While this method required the attacker to know the targeted user’s Twitter account ID, the second vulnerability found by the Egyptian expert is far easier to exploit.

It would be fairly trivial to write a brute force script to delete all cards from all accounts and effectively halt all Twitter advertising campaigns, which would save a lot of people money, and cost Twitter a lot of money.

But the vulnerability was disclosed responsibly and fixed two days after it being divulged to Twitter, the researcher received $2,800 for this vulnerability, which is a fairly respectable amount.

If users add invalid credit cards to their Twitter Ads accounts, they’re presented with two options: try to add the card again, or dismiss it. Dismissing a card is the same as deleting it, and the researcher soon realized that he could perform this action on valid cards already added to accounts. After analyzing the POST request, Aboul-Ela found that unlike the previous attack method, this one only required the attacker to know the 6-digit ID associated with the card.

“Imagine a blackhat hacker that could write a simple Python code and use a simple for loop on 6 numbers he could delete all credit cards from all Twitter accounts which will result in halting all the Twitter ads campaigns and incur big financial loss for Twitter,” the researcher explained in a blog post.

Aboul-Ela said Twitter addressed the vulnerabilities within two days after being notified. The company rewarded him with a $2,800 bounty.

Twitter has been running a bug bounty program on the HackerOne platform for the past three months, but at the beginning of September, the company decided to start handing out monetary rewards for researchers who contribute to making the service more secure. The minimum reward is $140, but a maximum limit has not been set. The bounty paid by Twitter to Aboul-Ela is the largest so far.

It’s good to see some interesting stuff coming out of the Twitter bug bounty program and I hope to see more, especially things like this which are pretty clever edge case scenarios that developers really wouldn’t think of addressing.

More companies should be running more effective bug bountry programs and securing them against potentially devastating attacks like this.

Source: Security Week