Tuesday, July 14, 2015

Some Remarks About the Hacking Team Hack

UUID: 90e9fc07-e6ab-454d-8265-48876691db93

I have to say, right up front, that I haven't been tracking this too closely. Things have been too busy (with things that I can't write about) for me to do more than follow a bit of the trade press, and do some very minimal exploration. Plus,  it's a bit odd to be doing two posts is a row (7/15/15 update: almost in a row. There is one post between this one and Does the Navy Buy Vulnerabilities Too?) on disclosure. That's a topic that could use a flight of posts, but creating that would require more effort than I am able to supply, given that I regard fubarnorthwest as a sort of twisted alien mutant from the Forbidden Zone hobby, not a business tool. And again, things are busy.

Finding trade press articles is obviously not difficult; it's a huge story. My position is that too much following of trade press is counterproductive. I use various criteria for classifying sources into tiers. A current example would be breathlessly wondering about whether or not a pre-announced TLS bug is "the next Heartbleed." No, it isn't. You can tell, without the bother of reading the story, because it was pre-announced. Too much of that crap gets a source downgraded. More information on how I rate sources is a subject for a future post, but not something with a high priority. If you are curious about it, tell me.

That said, Ars Technica has done solid trade press work on this, with a flight of articles. I'm only going to mention a couple here. But they are all linked in some fashion, so navigation shouldn't be a problem.

Article the First

Hacking Team’s Flash 0-day: Potent enough to infect actual Chrome user
Government-grade attack code, including Windows exploit, now available to anyone.
by Dan Goodin - Jul 10, 2015 2:00pm PDT
I'm going to ignore the "Potent enough to infect actual Chrome user" bit, save to note that browsers are inherently dangerous, and Chrome had unpatched vulnerabilities on the day it was launched, back in August of 2008, because it was built on an older, exploitable version of WebKit. Implicit trust in a Web browser, from any supplier, is a Really Bad Idea.

Have a look at the lead graphic in this article. The one with the caption that says, "A browser-detection script that was part of a Hacking Team Flash zero-day exploit used in an Egyptian campaign."

That is Python, and it is being used to differentiate between Google Chrome and Microsoft Internet Explorer. The thing is, Python is rarely found on Windows systems. The simplest explanation is that Hacking Crew shipped a Python runtime for Windows. Bulky and noisy, but perhaps they just loves them some Python. I know I do. But it seems more likely that in a reasoned analysis, they find it advantageous. I tracked down the source code behind the graphic. This site is under heavy load as I write this, but it is available from https://ht.transparencytoolkit.org/gitlab/Windows-Multi-Browser/deliverables/scout_appended/resources/chrome_non_chrome_filter.py.

We can also infer something about their Python development environment -- that it is built around iPython notebooks. Again, no surprise. I use them too. The clue is (again, heavy load warning) 
https://ht.transparencytoolkit.org/gitlab/Windows-Multi-Browser/deliverables/scout_download/Reame.md. This is a  Markdown file, and it's one of the basic capabilities of iPython notebooks. Not least because you can dress them up with CSS to create elegant documentation. This tends to confirm (not that this is really necessary) that this was a business that paid a good deal of attention to business processes. Such as producing better doc, faster, and cheaper. As I do, and you should. If even the Bad Guys (and Hacking Crew are purely mercenary) are seizing that business advantage, and you aren't, why not?

Article the Second

Firefox blacklists Flash player due to unpatched 0-day vulnerabilities
Also, Facebook calls for Flash end-of-life, so that we can "upgrade the whole ecosystem."
by Sebastian Anthony (UK) - Jul 14, 2015 6:45am PDT

I have had my Security Guy hatred on for Adobe products since, well, forever. Was that justified? There are ample reasons for not trusting the track record of a bit software, vis-a-vis a previous track record, as in any way an indicator of the future. To a point. The number of vulnerabilities appearing in CVE or other databases, etc., are all very flawed mechanisms. Papers have been written about it (no, not White Papers, but Real Papers), presentations have been given at security conferences (there are a couple of people I need to contact about this before I say more), etc. And there are some possibly better indicators, such as static code analysis.

Again, we can only make allowances to a certain point. Even if one considers that such software as Flash, running on Windows, is an almost universally installed target, and will receive a disproportionate amount of attention from exploit creators. We may, just possibly, be reaching a point where consumers are just fed up with the constant (FUBAR) state of Adobe Flash, and alternatives to Flash exist. Adobe Flash has had a very human cost in terms of stolen funds, identities, personal information, etc.

In future, I hope to call out those sites that still require Flash, in the hopes that it will just freaking die before more damage is done. I have two browser updates waiting for me on this system. Both are probably about Flash -- Google Chrome is making changes as well. Fine. Of the four Web browsers I use regularly, Chrome is the only one that can run Flash. If I approve it, on a case-by-case basis.

Aaaaaaand Now I Have to Go

Because Oracle (another purveyor of crap software) has just released their quarterly Critical Patch Update. http://www.oracle.com/technetwork/topics/security/alerts-086861.html.

There is at least one more important post in the Ars Technica flight of stories, but I have to defer that. Things just got busier. Thanks, Oracle.

Thursday, July 9, 2015

What and When means better support and software

UUID: cd1d2cf8-266a-11e5-8834-00224d83fb0a

Finding help for a problem in the Open Source world often involves search engines, filtering out random rants, and all too often finding something that does not work, as it was only appropriate four years ago. Which is I put publication dates at the top of my infrequent posts.

This is a problem in my older notes files, of which there are many.
$ find $notes -type f | wc -l
It's not uncommon to find something that dates back ten years. It isn't a horrible problem, as modification times are in the files, so it's easy to spot. And no, I am not going to put that whole hierarchy under version control. Currently, it's too much overhead, given the way that I use that hierarchy.

For the past several years, I've dealt with the applicability issue with a shell alias in my .bashrc.
daterel() {
    date; cat /etc/redhat-release
$ daterel
Thu Jul  9 10:21:16 PDT 2015
Fedora release 21 (Twenty One)
I just paste the output into the doc. Or the bug report, or whatever. I recommend it to clients who are sending me bug reports, and some form of it is pushed to everything in the lab. I say 'some form' because in certain situations it may make more sense to output on a single line, change the date format to seconds since the epoch, or whatever.

Some variant of /etc/*-release is available in most Linux distributions, not just the families related to Red Hat (CentOS, Fedora, etc.). It might take other forms, such as /etc/lsb-release. Or even /etc/issue. And no matter which side of the systemd controversy you might fall on, it has at least provided /etc/os-release. Though that provides 'ANSI_COLOR=' which gets very near to one of my pet hatreds.

It might even take the form of a command, such as  'lsb_release <options>'
http://www.freedesktop.org/software/systemd/man/os-release.html. I note that freedesktop.org has done a Bad Thing here, though, in that they have made CPE_NAME= optional. Common Platform Enumeration is a standard worth supporting, if you ever expect to be glueing the output of disparate
security information and event management (SIEM) tools together.

It's not really complicated

Really. To the beginner, it might seem that way, but it really isn't. 
  1. Search for files in /etc/, such as /etc/*-release. or /etc/issue
  2. Search for commands, via something like 'which lsb_release'
  3. Look at the results
  4. Spend about 10 minutes thinking about it
  5. Drop in a shell alias, or a quick script (in your $PATH, so it Just Works)
  6. Profit! Better docs, better bug reports
  7. There is no 7