Top Nav

In security testing, much like most things technical there are two very contrary methods, Dynamic Application Security Testing or DAST and Static Application Security Testing or SAST.

Dynamic testing relying on a black-box external approach, attacking the application in its running state as a regular malicious attacker would.

Static testing is more white-box looking at the source-code of the application for potential flaws.

Personally, I don’t see them as ‘vs’ each other, but more like they compliment each other – it’s easy to have SAST tests as part of your CI/CD pipeline with tools like Code Climate.

DAST – Dynamic Application Security Testing

There are also pros and cons for each methodology, with DAST you aren’t bound to any particular technology or language – but on the downside, you are also limited to the parts of the application visible to the outside World.

Mr.SIP was developed in Python as a SIP Attack and audit tool which can emulate SIP-based attacks. Originally it was developed to be used in academic work to help developing novel SIP-based DDoS attacks and defence approaches and then as an idea to convert it to a fully functional SIP-based penetration testing tool, it has been redeveloped into the current version.

Mr.SIP – SIP Attack Features

Mr.SIP currently comprises of four sub-modules named SIP-NES, SIP-ENUM, SIP-DAS and SIP-ASP. Since it provides a modular structure to developers, more modules will continue to be added by the authors and it is open to being contributed to by the open-source developer community.

SIP-NES needs to enter the IP range or IP subnet information. It sends SIP OPTIONS message to each IP addresses in the subnet and according to the responses outputs the potential SIP clients and servers on that subnet.

SIP-ENUM outputs which SIP users are valid according to the responses in that network by sending REGISTER messages to each client IP addresses on the output of SIP-NES.

SIP-DAS basically generates legitimate SIP INVITE message and sends it to the target SIP component via TCP or UDP. It has three different options for spoofed IP address generation, i.e., manual, random and by selecting spoofed IP address from subnet. IP addresses could be specified manually or generated randomly. Furthermore, in order to bypass URPF filtering, which is used to block IP addresses that do not belong to the subnet from passing onto the Internet, we designed a spoofed IP address generation module. Spoofed IP generation module calculated the subnet used and randomly generated spoofed IP addresses that appeared to come from within the subnet.

Uber is not known for it’s high level of ethics, but it turns out Uber paid hackers to not go public with the fact they’d breached 57 Million accounts – which is a very shady thing to do. Getting hacked is one thing (usually someone f*cked up), but choosing as a company to systematically cover up a breach to the tune of $100,000 – that’s just wrong.

57 Million is a fairly significant number as well with Uber having around 40 Million monthly users, of course, it’s not the scale of Equifax with 143 Million (or more).

It includes both riders and 600,000 driver information, Uber says nothing fraudulent appears to have happened since the breach and compromised accounts are flagged in the system for extra monitoring.

By Now, the name Uber has become practically synonymous with scandal. But this time the company has outdone itself, building a Jenga-style tower of scandals on top of scandals that has only now come crashing down. Not only did the ridesharing service lose control of 57 million people’s private information, it also hid that massive breach for more than a year, a cover-up that potentially defied data breach disclosure laws. Uber may have even actively deceived Federal Trade Commission investigators who were already looking into the company for distinct, earlier data breach.

On Tuesday, Uber revealed in a statement from newly installed CEO Dara Khosrowshahi that hackers stole a trove of personal data from the company’s network in October 2016, including the names and driver’s license information of 600,000 drivers, and worse, the names, email addresses, and phone numbers of 57 million Uber users.

As bad as that data debacle sounds, Uber’s response may end up doing the most damage to the company’s relationship with users, and perhaps even exposed it to criminal charges against executives, according to those who have followed the company’s ongoing FTC woes. According to Bloomberg, which originally broke the news of the breach, Uber paid a $100,000 ransom to its hackers to keep the breach quiet and delete the data they’d stolen. It then failed to disclose the attack to the public—potentially violating breach disclosure laws in many of the states where its users reside—and also kept the data theft secret from the FTC.

It’s definitely possible there could be some serious consequences for Uber in a legal context as they’ve certainly breached some federal laws concerning disclosure to the FTC and in general not disclosing a breach that has leaked customer records.

They previously fired their Chief Security Officer, which obviously hasn’t helped much (more of a PR/Blame exercise most likely).

According to Bloomberg, Uber’s 2016 breach occurred when hackers discovered that the company’s developers had published code that included their usernames and passwords on a private account of the software repository Github. Those credentials gave the hackers immediate access to the developers’ privileged accounts on Uber’s network, and with it, access to sensitive Uber servers hosted on Amazon’s servers, including the rider and driver data they stole.

While it’s not clear how the hackers accessed the private Github account, the initial mistake of sharing credentials in Github code is hardly unique, says Jeremiah Grossman, a web security researcher and chief security strategist at security firm SentinelOne. Programmers frequently add credentials to code to allow it automated access to privileged data or services, and then fail to restrict how and where they share that credential-laden software.

“This is all too common on Github. It’s not a forgiving environment,” says Grossman. He’s far more shocked by the reports of Uber’s subsequent coverup. “Everyone makes mistakes. It’s how you respond to those mistakes that get you in trouble.”

It’d be interesting to get a bit more details on what happened, were the credentials accidentally pushed to a Github repo that was public? Or did the hacker(s) actually get access to a private Github repo that contained critical credentials?

RDPY is an RDP Security Tool in Twisted Python with RDP Man in the Middle proxy support which can record sessions and Honeypot functionality. RDPY is a pure Python implementation of the Microsoft RDP (Remote Desktop Protocol) protocol (client and server side). RDPY is built over the event driven network engine Twisted. RDPY support standard […]

Once again the old, default Amazon AWS S3 settings are catching people out, this time the US Military has left terabytes of social media spying S3 data exposed to everyone for years. It’s not long ago since a Time Warner vendor and their sloppy AWS S3 config leaked over 4 million customer records and left […]