As I mentioned in my previous blog post, I only write blog posts about books that I like, and therefore it is pretty clear that I did like this one. The book begins with an in-depth psychological analysis of the author’s rabbit, and continues to guide us through the stories of other people who, according to the author, are relevant to the main point of the book, which is that slacking off is not inherently bad and that there are positive aspects to it.
The book is divided into several chapters that are themselves composed of three parts: an initial introduction to a certain aspect of laziness, a description of a former patient and an analysis of a famous person. I found this layout very interesting and the deep delve into the life of famous authors and directors was very enlightening for me as I am generally very ignorant about these topics.
Because the book is about laziness and not working, I am not going to write any further because I don’t want to.
Over the last couple of years there has been a lot of press regarding bug bounties, and I thought I would write my two cents on the matter. As a bit of background on who I am, I have five years of professional software development experience, five years of penetration testing experience and now a year of full-time bug bounty experience.
Criticism of Bug Bounties
I think most criticism of bug bounties is well-founded and is a reaction to the overly positive messaging coming from bug bounty companies. They are simply contesting the narrative being propagated by bug-bounty companies, that bug bounties should be a replacement to all other investment in security. Here’s a point, for example, that I agree on:
Bug bounty programs, she said, have been over-marketed as a solution to finding bugs. “They’re not a cost effective replacement for penetration testing,” she said.
Quote from Katie Moussouris,
I don’t personally run a bug bounty myself, but it seems hard to argue against it. If you are going to be paying top value for bug bounties, a single remote code execution vulnerability can set you back at least ten thousand dollars. If you set a low maximum bounty, most hackers won’t even look at your program. This is because they need to spend too much time understanding your external attack surface for the return in terms of money.
On the other hand, for that same amount of money, you can get a team of experts to look at various aspects of your technology stack, as well as provide proactive advice.
Real Benefits of Bug Bounty Programs
Having said that, however, I think there are real benefits to bug bounty programs, especially to large corporations such as Google, Facebook and the others. These benefits can mainly be summarised as these two points, below.
Firstly, penetration testing can be too laser-focused on individual assets when not managed properly. I have seen this in my experience when a client regularly spends upwards of $50,000 a year on pentesting alone, but fails to assess a number of critical elements of their internet prescence. This can happen due to a lack of inventory on part of the organisation or a lack of political will within the company to look at, for example, third party products sitting on their DMZ. Although this mistake can also happen in bug bounty programs, in my opinion bug bounty programs take a more hollistic approach.
Secondly, not all security professionals are experts on all subject matters. Having a wider range of people looking at your site can have the benefit of individual experts finding the security holes that are specific to their area of expertise. For example, certain hackers are SAML experts, others may specialize in finding certain kinds of IDOR vulnerabilities.
These benefits only materialise on properly handled bug bounty programs. If you add a program with a terribly constrained scope offering $50 rewards, your security is not magically going to improve.
Real Negatives of Bug Bounty Progams
Running a bug bounty program comes with its own overheads, and time spent managing a bug bounty program is time not spent doing something else. In particular, there is a lot of overhead in managing bad reports, dealing with inmature researchers, etc. If you have a managed program then this can be lessened, but of course the cost increases.
Certain aspects of your company’s security are not covered by bug bounties. At a minimum, bug bounty programs completely fail to address a critical component of I.T. security: the human aspect. If your external network is hardened, but your staff are not trained to respond to phishing emails, then your money was probably not well spent, because attackers are likely to try phishing first due to its low-cost and high success rate.
Additionally, bug bounties are not a good place to obtain advice previous to a software lauch, are not a good way to train your developers to follow security best practices, and are not a good way to obtain advice regarding currently-deployed solutions, and how to best secure them. These problems require a solution outside of bug bounties.
Are Bug Bounties a Good Investment of Your Time as a Hacker?
There is also a lot of criticism regarding bug bounties from the perspective that they are unfair to security researchers. Critics say that a minority of bug bounty hunters will actually reap any rewards for their time investment. When you compare the amount of money obtained by most people, and you compare it against the average salary of a penetration tester, it shows that only a minority of hackers will break through that threshold.
This, in my opinion is fair criticism, and again possibly a response to the marketing of Bug Bounty companies. These companies’ marketing is overly positive, which is understandable because they need to entice hackers to spend time on their platforms. The fact that a 19 year old from Argentina made $1.000.000 on bug bounties does not guarantee that you will, though.
My opinion on the matter is that you should consider your own circumstances and your own skills when considering whether doing bug bounties is going to be worth your time. It may very well be that you will waste your time, but not all rewards have to be monetary: it may be that it simply helps you become a better pentester.
With regards to finding vulnerabilities, it will come down to target selection and your affinity to finding vulnerabilities over time, as well as your persistence. Big corporations that have had a bug bounty for a while have had their external attack surface hardened, so the vulnerabilities you find will be the ones that only somebody with your expertise can find. You may also get lucky and find new attack surface that has only just became vulnerable.
I think if you are a hacker that regularly finds RCE/SQLI/SSRF/XXE in client applications, chances are that over time you will find these and get a bounty
Negative Aspects of Bug Bounties as a Hacker
There are some negative aspects to bug bounties in my opinion, and they are the lack of regularity in payments and also the lack of recourse when dealing with an unfair resolution. The lack of regularity in payments is self-evident: if you are a pentester you will get paid if you show up to work, whereas if you do bug bounties it doesn’t really matter whether you show up to work. This can work for some people, and it may be overly stressful for other people.
With regards to the lack of recourse, I think this is related to the amount of spam that bug bounty programs get. They make the final choice, and that is that. Sometimes this means you report a valid bug that you can exploit to do something great, but you won’t get paid.
This article is meant to be a summary of my opinion on the topic, which I think can be interesting to some people. As I noted above, corporations can reap benefits from a properly-managed, properly-funded bug bounty program.
Hackers can also reap benefits from bug bounty programs, but these benefits come at the expense of other things, such as stable wages and a guarantee of income.
Almost a year ago a huge number of women accused Morgan Marquis-Boire of sexual assault. Their courage in coming forward is incredible, especially considering the horrible record that society has in addressing these wrongs, and I would like to state my opinion on the matter for public record.
I want it to be stated that I personally believe all of these women on a number of grounds: the vividness of their descriptions, the widespread geographical locations of the victims, the toxic culture I observed in the workplace, and some of the attitudes that I observed my ex-colleagues have toward women.
I think the lack of prosecution on Marquis-Boire despite the overwhelming amount of testimony reflects poorly on society’s view of women’s right to be free of violence. I hope one day justice will be served and Morgan Marquis-Boire will be sentenced to a lengthy prision term.
This is a blog post summarising a few notes I’ve gathered around the internet, with the purpose of cementing them in my mind rather than adding anything new or attempting to broadcast them to a wider crowd. If you find it useful, that’s great, but it’s nothing original and its been pulled from several sources noted at the end of the post.
The post is organised in several categories: general attacks against URL parsers and implementations, and specific attacks against parsers in specific languages, with the intention of highlighting differences in interpretation of URL strings.
Discrepancies between parsers and HTTP libraries
This is interesting. These three URL parsing libs in python all interpret this individual URL differently:
In versions earlier than a few years ago, there was an inconsistency between parse_url and readfile which could lead to URL parser bypass with URLs with several colons: http://127.0.0.1:11211:80/ or a URL with extraneous characters http://email@example.com/. In both examples parse_url and readfile interpreted the URL differently. In the second case, readfile interprets the host as evil.com, whereas parse_url interprets the host as google.com.
This may affect other programming languages.
Curl is in widespread usage, and there are curl bindings in every language under the sun. Discrepancies between language URL parsers and Curl could lead to SSRF. Consider the following URL, as interpreted by PHP:
curl 'http://firstname.lastname@example.org @google.com/'
curl: (7) Failed to connect to 127.0.0.1 @google.com port 80: Connection refused
As you can see it is attempting to retrieve 127.0.0.1. This example uses PHP, but these discrepancies have been identified in other languages as well and more are bound to exist. Example vulnerabilities have been found in WordPress, VBulletin and MyBB utilising this technique.
Path traversal bypasses are possible with special unicode character U+FF2E. This happens because node’s internal unicode parser interprets this multibyte character as two separate bytes, and then proceeds to discard a part, leaving \x2E, a dot.
Similar results can be observed by injecting U+FF0D and U+FFOA, which results in a newline, allowing newline injection.
In linux, hostname resolution is generally done with gethostbyname. As per RFC1035 it supports escaping of values with \DDD notation. This may allow for additional parser confusion.
The ability to add invalid trailing content can lead to an attacker that can perform HTTP header smuggling attacks in the event they can inject encoded new lines, such as 127.0.0.1\r\nfoo.com\r\nAuthorization: blah
Additionally, an attacker can smuggle other protocols (such as SMTP) thanks to TLS’ SNI.
Internationalizing Domain Names in Applications (IDNA) is a standard or a set of standards that allow for characters not in the ascii set to be used in domain names. There are two diferring standards, IDNA2003 and IDNA2008, which are difficult to transition between for client implementations, which lead the unciode consortium to release UTS46.
Different HTTP libraries and URL parsing libraries implement different versions of this standard, as well as implementing the standard in different ways. This can be useful to avoid blacklists of disallowed hosts. An example of this is an inconsistency in PHP’s gethostbynamel function and curl’s resolver: PHP’s gethostbynamel fails when provided with a domain with a special character, which can lead to bypasses. cURL will then retrieve the URL and resolve it successfully.
Values synonymous to localhost
Beside the obvious examples, the following URLs will all attempt to retrieve localhost.
Several mechanisms for bypassing SSRF protections through DNS shenanigans exist. I will cover these on a high level below:
Host that resolves to a malicious IP
DNS records may point to an internal IP address (such as 10.0.0.2 or 127.0.0.1). This frequently works because developers check whether the ip matches an address range but accept arbitrary DNS names regardless of what they resolve to.
Time of check, time of use vulnerabilities (TOCTOU)
A TOCTOU vulnerability can occur if the target application implements host whitelisting or host blacklisting. Imagine the following pseudo-code:
download_url = request.get('target')
target_host = urlparse.urlparse(download_url).netloc
target_ip = socket.gethostbyname(target_host) #resolve
if target_ip in blacklist:
A TOCTOU vulnerability allows for a bypass of the blacklist check if DNS resolution occurs twice: once for the check, and twice for the retrieval. An attacker-controlled DNS server could resolve the first time to a good address and the second time to a malicious IP.
A SSRF protection bypass may occur if an attacker creates a malicious site that redirects to an internal IP because the check is performed on the initial IP address and not the address the HTTP client gets redirected to. This frequently works for most HTTP clients as they tend to follow HTTP redirections by default. Here’s an example:
http://victim.org?url=http://127.0.0.1 -> FAIL, not allowed
http://victim.org?url=http://attacker.com/ -> 301 REDIRECT TO 127.0.0.1 -> 200 OK.
The ability to inject \r\n in combination with either spaces or \t characters allows you to inject new headers into the request, which may allow other attacks. Imagine a request to `victim.com?url=yourserver.com/aa’ results in the following request:
GET /aa HTTP/1.1
A request that looks like victim.com?url=yourserver.com/aa%20HTTP/1.1%0Ainjected-header: true%0Ax-aa: could result in the following:
GET /aa HTTP/1.1
This would allow you to attack a lot of plaintext protocols.
A new version of droopescan has been released, which increases the version’s patch digit from 1.33.6 to 1.33.7. With this, droopescan officially reaches elite status. This is a minor increase to update fingerprint databases for all supported CMS’. No serious vulnerabilities have come out this round, although WordPress has patched a Cross Site Scripting vulnerability.
For those that are not aware, a large number of improvements have been implemented between 1.0 and 1.33.7, almost too many to count. A few highlights are:
Support for CMS type autodetection. This allows you to specify a list of URLs and dscan will automatically determine what CMS it is and perform the usual version and plugin enumeration. Performance is pretty great, and I’ve successfully version scanned several million hosts in three days time.
Allow for resuming of mass scans with the –resume flag.
Several performance improvements and tweaks.
Preliminary support for WordPress and Joomla.
droopescan development continues on, and exciting things for the future include tools that will make updating the fingerprint even easier (for me, as I am very lazy), support for other CMSs, and the release of version 2.0 which will tidy up JSON output.
Hoy estoy por sacar una versión nueva de droopescan, que debido a que es la versión que sigue a la 1.33.6, va a ser la versión 1.33.7. Este es un número muy particular para la comunidad de la seguridad informática y los nerds en general, y también es indicativo del mucho tiempo de desarrollo y el número de parches que he publicado para droopescan.
Esta nueva versión sale a raiz de que hay nuevas versiones en Drupal, WordPress, Joomla y SilverStripe. WordPress arregla algunos fallos de seguridad (XSS).