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.

26 September 2014 | 3,758 views

Everything You NEED To Know About Shellshock Bug In BASH

Check For Vulnerabilities with Acunetix

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,294 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,454 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,747 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 | 721 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


16 September 2014 | 1,415 views

StegExpose – Steganalysis Tool For Detecting Steganography In Images

StegExpose is a steganalysis tool specialized in detecting steganography in lossless images such as PNG and BMP (LSB – least significant bit type). It has a command line interface and is designed to analyse images in bulk while providing reporting capabilities and customization which is comprehensible for non forensic experts.

Steganography is the art or practice of concealing a message, image, or file within another message, image, or file. The word steganography combines the Ancient Greek words steganos, meaning “covered, concealed, or protected”, and graphein meaning “writing”.

StegExpose rating algorithm is derived from an intelligent and thoroughly tested combination of pre-existing pixel based staganalysis methods including:

  • Sample Pairs by Dumitrescu (2003)
  • RS Analysis by Fridrich (2001)
  • Chi Square Attack by Westfeld (2000)
  • Primary Sets by Dumitrescu (2002)

In addition to detecting the presence of steganography, StegExpose also features the quantitative steganalysis (determining the length of the hidden message).

Detecting Steganography In Images

Usage

[directory] – directory containing images to be diagnosed

[speed]Optional. Can be set to ‘default’ or ‘fast’ (set to ‘default if left blank). default mode will try and run all detectors whereas fast mode will skip the expensive detectors in case cheap detectors are able to determine if a file is clean.

[threshold]Optional. The default value here is 0.2 (for both speed modes) and determines the the level at which files are considered to be hiding data or not. A floating point value between 0 and 1 can be used here to update the threshold. If keeping false positives at bay is of priority, set the threshold slightly higher ~0.25. If reducing false negatives is more important, set the threshold slightly lower ~0.15

[csv file]Optional. Name of the csv (comma separated value) file that is to be generated. that If left blank, the program will simply output to the console.

Performance

The accuracy and speed of StegExpose has been tested on an image pool of 15,200 lossless images, where 5,200 of them were stego images (images with hidden data) created with the tools OpenStego, OpenPuff, SilentEye and LSB-Steganography. Embedding rates range from 2.5% to 25.3% with an average of 13.8% (secret data / cover image).

You can download StegExpose here:

master.zip

Or read more here.


13 September 2014 | 2,446 views

Google DID NOT Leak 5 Million E-mail Account Passwords

So a big panic hit the Internet a couple of days ago when it was alleged that Google had leaked 5 Million e-mail account passwords – and these had been posted on a Russian Bitcoin forum.

I was a little sceptical, as Google tends to be pretty secure on that front and they had made no announcement regarding the incident. The news was published on a number of fairly high profile, legitimate news sources as though it was real (TIME, CBS, FastCompany, IBT, The Independent & many more).

Google Password Leak

Some may say the whole thing was just an elaborate e-mail farming excercise as many articles cited a domain IsLeaked.com which registered a mere 2 days before the huge password leak..by Russians.

Plenty of room for conspiracy theories here.

In some cases, those alleged breaches are not quite what they seem to be. Case in point is a report first posted to a Russian Bitcoin forum site that information on nearly 5 million Google account holders was breached this week.

Any alleged attack against Google is noteworthy, and 5 million accounts is also a significant number. That said, the bigger questions that always should be asked in any breach coverage center on what was stolen and whether there is any real impact.

As a professional, facts are my currency, and speculation is just a cheap narcotic. So when I initially saw the first Google account breach reports, I held off on writing until the facts were revealed.

The facts are that Google itself was not breached and 5 million users are not actually at risk.

In a blog post Sept. 10, Google claimed that less than 2 percent of the username/password credentials in the Russian breach list were actually valid.

To add further fuel to the fire, Google noted that its automated anti-hijacking systems would limit the risk on the 2 percent that might be affected. Additionally, Google is now telling those people in the 2 percent list that they are required to reset their passwords.

Google did release something later about this ‘compromise’ and stated that less than 2% of the leaked e-mail addresses were valid credentials and all those that might have been effected have had their passwords forcibly reset.

The Google announcement is here: Cleaning up after password dumps

They also stated categorically that the leaked account details were not due to a compromise of any Google systems.

So to recap, it wasn’t 5 million “real” passwords, and of those that might be real, there is little user risk. It also was not actually an attack directly against Google’s infrastructure either.

“It’s important to note that, in this case and in others, the leaked usernames and passwords were not the result of a breach of Google systems,” Google stated. “Often, these credentials are obtained through a combination of other sources.”

So what does that mean? Simply put, Google account information is also used on non-Google systems and also might be stored outside of Google’s control or influence. An attacker can get a user account by a breach of a third-party system or more likely via a phishing attack against a user.

In this case, Google has made it painfully obvious that the risk is low with this credentials breach. Aside from the fact that only 2 percent of the account information might be valid, Google’s efforts to protect its users and its systems from attacks are exemplary. Alerting users to the potential of a highjack and requiring a new password is an excellent best practice.

The use of other security tools and techniques to detect anomalous account behavior is also admirable. As I’ve written in the case of the Apple iCloud security incident, it is incumbent on Internet vendors and online services to proactively defend users against fraud, and that’s precisely what Google is doing.

So basically yah, this is a whole lot of non-news about something that didn’t really happen. Either way, keep your accounts safe and set up 2FA please.

But it does show once again, Google is up on the security of its userbase and it intends to keep everyone safe. Because they need your data, that’s how they make money.

Source: eWeek


11 September 2014 | 2,684 views

Lynis v1.6.0 Released For Download – Linux Security Auditing Tool

Lynis is an open source linux security auditing tool. The primary goal is to help users with auditing and hardening of Unix and Linux based systems. The software is very flexible and runs on almost every Unix based system (including Mac). Even the installation of the software itself is optional!

It’s a great tool for auditing *nix based systems and hardening them based on the recommendations, it works well on a variety of systems including Linux, AIX, FreeBSD, OpenBSD, Mac OS X & Solaris.

Lynis - Linux Security Auditing Tool

We’ve written about this tool a few times, when it first came out in 2008 – Lynis – Security & System Auditing Tool for UNIX/Linux and again in 2009 – Lynis 1.2.6 Released – UNIX System & Security Auditing Tool.

How it works

Lynis will perform hundreds of individual tests to determine the security state of the system. Many of these tests are also part of common security guidelines and standards. Examples include searching for installed software and determine possible configuration flaws. Lynis goes further and does also test individual software components, checks related configuration files and measures performance. After these tests, a scan report will be displayed with all discovered findings.

Typical use cases for Lynis:

  • Security auditing
  • Vulnerability scanning
  • System hardening

Why open source?

Open source software provides trust by having people look into the code. Adjustments are easily made, providing you with a flexible solution for your business. But can you trust systems and software with your data? Lynis provides you this confidence. It does so with extensive auditing of your systems. This way you can verify and stay in control of your security needs.

You can download Lynis v1.6.0 here:

lynis-1.6.0.tar.gz

Or read more here.


08 September 2014 | 749 views

Twitter Bug Bounty Official – Started Paying For Bugs

So the Twitter bug bounty program is now official, they are actually paying – and not a bad amount too. A minimum of $140 for a confirmed bug with no defined maximum.

This includes the Twitter website itself and any sub-domain (mobile, ads, apps etc), and the official mobile apps for iOS and Android. It’s somewhat strange it doesn’t mention Windows Phone as well, but I’d assume that’s included as it’s also an official app.

Twitter Bug Bounty

You can see the official tweet on the matter here:

Set up through the security response and bug bounty platform HackerOne, the program offers a minimum of $140 per threat. The maximum reward amount has not been defined.

The company is currently asking bug hunters to submit reports about bugs on its Twitter.com domain and subdomains (ads.twitter.com, apps.twitter.com, tweetdeck.twitter.com, and mobile.twitter.com) and its iOS and Android apps.

“Any design or implementation issue that is reproducible and substantially affects the security of Twitter users is likely to be in scope for the program,” the company pointed out. “Common examples include: Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF), Remote Code Execution (RCE), unauthorized access to protected tweets, unauthorized access to DMs, and so on.”

It includes all kinds of vulnerabilities, including those which some other companies brush off as “non-serious” like CSRF and XSS especially. Just don’t bother if you’re from Cuba, Sudan, North Korea, Iran or Syria because you won’t get paid.

They specifically list:

  • Cross Site Scripting (XSS)
  • Cross Site Request Forgery (CSRF)
  • Remote Code Execution (RCE)
  • Unauthorized Access to Protected Tweets
  • Unauthorized Access to DMs

Reports about bugs on other Twitter properties or applications are welcome, but will not be eligible for a monetary reward – bug hunters will have to be content with a mention on the Twitter’s Hall of Fame, which is already populated with the names of 44 hackers.

In fact, Twitter’s bug reporting program on HackerOne has been up for three months now, but the company has only now announced that it will start paying out bounties.

So far, 46 of the reported bugs have been closed by the company’s security team, but reports received prior to September 3, 2014, are not eligible for monetary rewards.

“Maintaining top-notch security online is a community effort, and we’re lucky to have a vibrant group of independent security researchers who volunteer their time to help us spot potential issues,” the company noted, adding that the bug bounty program was started to “recognize their efforts and the important role they play in keeping Twitter safe for everyone.”

Things that do not quality (are outside the scope of the program) are issues such as:

  • Issues related to software or protocols not under Twitter control
  • Reports from automated tools or scans
  • Reports of spam (see here for more info)
  • Vulnerabilities affecting users of outdated browsers or platforms
  • Social engineering of Twitter staff or contractors
  • Any physical attempts against Twitter property or data centers

The full details of the program can be found here: https://hackerone.com/twitter

It’s good to see more companies that are supporting responsible disclosure and putting their money where their mouths are. And honestly, the amount of money they have to pay out to make their platform and users more secure is minuscule compared to their over-bloated valuations.

Source: Help Net Security


03 September 2014 | 2,974 views

BurpSentintel – Vulnerability Scanning Plugin For Burp Proxy

BurpSentintel is a plugin for Burp Intercepting Proxy, to aid and ease the identification of vulnerabilities in web applications.

Searching for vulnerabilities in web applications can be a tedious task. Most of the time consists of inserting magic chars into parameters, and looking for suspicious output. Sentinel tries to automate parts of this laborous task. It’s purpose is not to automatically scan for vulnerabilities (even if it can do it in certain cases), as there are better tools out there to do that (BURP scanner for example). So it’s the only tool which sits in between manual hacking with BURP repeater, and automated scanning with BURP scanner.

BurpSentintel - Vulnerability Scanning Plugin For Burp Proxy

To use it, just send a suspicious HTTP request from BURP proxy to Sentinel. Then the user is able to select certain attack patterns for selected parameters (say, XSS attacks for parameter “id”). Sentinel will issue several requests, with the attack patterns inserted. It will also help find suspicious behaviour and pattern in the accompaining HTTP responses (for example, identify decoded HTML magic chars).

Features

  • AutomatedDetection Automated XSS/SQL Detection
  • AttackLists Self-Defined Attack Lists
  • Sessions Session Definition
  • Categorizer Categorizer
  • Reporter Generate Report
  • FirefoxAddon Firefox Addon

You can download BurpSentinel here:

BurpPlugin-full.jar

Or read more here.