Musings from

Thu, 25 Jun 2015

Junk security reporting for cash — and credit?

by on :

A few times a year, Pidgin gets a rash of junk security reports from “independent security researchers”. Typically we get 3–5 or more reports in the span of just a couple of days, reporting “vulnerabilities” such as HTTP POST submission of plain-text passwords to TLS-encrypted GNU Mailman subscription preferences login. (As many of you will know, by default Mailman will email your password to you every month. In addition, password retrieval is as simple as entering a subscribed email address and waiting for the password to arrive in that address’s inbox.) The report typically also asks for consideration in the form of a bounty or finder’s fee.

The typical defining characteristics of such an email are:

  1. The security flaw being reported is trivial-to-irrelevant.
  2. The mechanism by which the flaw operates is often protocol- or configuration-related, such as the presence or absence of certain HTTP headers or the method used for a form submission.
  3. The report does not indicate that the “researcher” understands the flaw or even personally verified its existence; often one gets the feeling from this and the previous point that it was identified by an automated tool.
  4. The reporter shows no understanding of the entity being contacted, often (for example) referring to the Pidgin project as a “company” or suggesting that it is a large and wealthy organization.
  5. The reporter asks for some sort of reward.
  6. All of the reports in a given burst come from the same general locale, often India.

The first three points on this list make the reports seldom useful and somewhat of a nuisance. The third point, in particular, means that when the reporter receives a polite reply to the effect of “we know, it’s not a problem and here’s why,” they often persist in repeating textbook explanations of the flaw with no reference to the effective implications of the problem (or lack thereof). Sometimes this degenerates into threats of exploitation or disclosure to the highest bidder, though not often.

The fourth and fifth points conflict somewhat with the sixth point in trying to understand why this happens and attempting to address the problem. Points 4 & 5 suggest that the reporter’s primary objective is financial gain, and coupled with 1–3 that they recently found out about this issue (or issues like it) and saw an opportunity to make a quick buck off large organizations with mediocre security skills. This would lead me to believe that the rashes of back-to-back reports are prompted by, perhaps, media coverage of bug bounties or reporting of a new-and-interesting configuration error in large numbers of sites. Unfortunately, the error or flaw being reported is often not new or interesting.

I believe that the sixth point is most instructive, and I think there’s something the community can do about it. I suspect that these rashes of reports are in fact course assignments for some sort of course on computer security being taught at an academic institution (and probably various courses at various institutions). I suspect that students are instructed to learn about some common vulnerabilities, find an example on the web, and contact the site administrators with their findings.

I cannot object to the general principle behind such an assignment. However, I can object to the way it is being specifically handled. If my suspicions are correct, then I believe that it is the responsibility of the course instructor to vet the students’ individual reports for relevance and correctness before sending them on to the affected organizations. I would also leave out the bounty-seeking in an educational setting, but I recognize that requesting a bounty for valid flaws is an accepted practice in the commercial world, and that identifying valid flaws is a valuable service.

An alternate, but related, possibility is that some security course is discussing vulnerabilities and disclosures, and students are taking it upon themselves to contact various organizations with flaws they found using automated tools to try to make some cash on the side. I find this less likely given the very short time frames in which such reporting bursts occur (often just a few days).

In either of these education-related cases, there’s something that can be done about the problem. If you are an instructor teaching such a course, please emphasize responsible reporting, which includes understanding both the mechanism and the impact of the flaw, and determining whether it is likely to be relevant to the affected organization. In addition, as mentioned above, screening reports before they are sent out would be the neighborly thing to do.

In the case of an organization like Pidgin, we take vulnerability reports seriously and expend some effort validating their existence and/or relevance. As we are an all-volunteer organization with a limited amount of time at our disposal, dealing with bogus and junk reports waste valuable resources. Report responsibly!

tags: im, security, trust
path: / | permalink | Comments

[ | | ]