The Ashley Madison Breach Was Likely a Good Thing

Commentary::Breach
Audience::Entry
UUID: 4cf5d0bf-381b-4bc5-be2f-f31b8fb0d481

Unless you happen to be a victim, anyway. There is a large set of users who will trust their most sensitive secrets to some random Web site. That has been true since the Web was born, and it isn't going to change, save temporarily. This is one of those moments when a lot of people get outed, and the extent to which it damages them is likely proportional to both their perceived importance (celebrities are not intrinsically important people) and their foolishness.

We can expect a stream of celebrity 'exposures' as news agencies comb a large data dump. Meh. Much noise, signifying nothing. Though I do not doubt that security vendor marketing departments of one sort or another are grinding their heads trying to come up with a way to peddle another White Paper.

The threat, minimal though it is, lies in having someone within your organization who is doubly foolish. Enough to trust that random Web site to begin with, and now willing to do silly things, in the hopes that they will not be outed via what is a very public data dump. In other words, victims of extortion, waiting to happen.

The outcome of that could be very bad indeed. But it really isn't very likely, despite what IT press might indicate.

Take The Register, for example. Always a favorite amongst many IT folk, for the headline comedy, if nothing else. They are unabashedly, well, flamboyant. Now Ashley Madison hackers leak CEO's emails, source code As IBM, Cisco and HP lead the IT pack on adultery website, it seems. They have a couple of bar charts. The first might be of interest to sociologists, as it's about Attached Male Seeking Female, etc. Though one would hope that even practitioners of the soft sciences would do their own research. The second graph is even better. 'Number of Valid Ashley Madison Accounts Among the Largest Tech Companies'. The winner is IBM, with 311. Oh, noes! Until you realize that this is out of a headcount of 379,592 employees at the end of 2014, according to Bloomberg. Eight hundredths of one percent. I doubt that the IBM risk management team is sweating this, and you likely shouldn't either.

What is more likely, in my opinion, is that unteachable people are the greater threat. Those unfortunate people who fall for every phishing scam, click any link in email from strangers, can't exist without a years-old version of Adobe Flash, etc. Yeah. Those people.

Who, by the way, are not mentally deficient, and if you are one of those people making snide remarks referring to 'lusers' instead of 'users', you are part of the problem. If you are heard making a remark like that as you make your way through the cube-farm, you have just alienated the people you are supposed to helping. It's unprofessional, and hasn't been funny for twenty-odd years.

A large subset of the workplace population have certain characteristics that may make a security worker's life more difficult.

1. An inherently trusting nature
2. Not comprehending the nature of the environment
3. Exclusive focus on the task at hand

There's nothing you can do about 1, save waiting for life to burn them enough times for them to develop the required amount of cynicism. Which it undoubtedly will. Number 2 is usually teachable, provided you have not blown any chance of building a rapport via 'luser' comments, etc. Number 3 involves a certain amount of irony, in that we often admire people who can get to that level of focus, and refer to it as in the zone, flow state, etc. That's my personal Happy Place, so I'm sympathetic. Their managers will likely value these employees, because duh. They are very productive.

So there you have it. 2 and 3 mean teaching, which is mind-boggling more effective if you can establish a rapport. 1? We're back to my title. The Ashley Madison Breach Was Likely a Good Thing. IT touches everything these days, from Wall Street to the local tire company. The chances are probably good that the legions of celebrity gossip fans, whom you probably never hoped to reach, will in some way be influenced by this.

How is that not a win?

Some Remarks About the Hacking Team Hack

Commentary::Disclosure
Audience::All
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
http://arstechnica.com/security/2015/07/hacking-teams-flash-0day-potent-enough-to-infect-actual-chrome-user/

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
http://arstechnica.com/security/2015/07/firefox-blacklists-flash-player-due-to-unpatched-0-day-vulnerabilities/

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.

What and When means better support and software

Recommendation::Documentation
Audience::Entry
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
1277
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

Does the Navy Buy Vulnerabilities Too?

Commentary::Disclosure
Audience::All
UUID: e62e4ab8-ad7e-449d-9a4b-d2f2f2dd459e

This morning, I happened across this dead as I write this link. It goes to the FedBizOpps.gov site, and was original for Solicitation Number N0018915T0245, titled 70--Common Vulnerability Exploit Products. I happened to open it in another browser because I was curious about a rendering problem, which can be seen in the text below. I suspected it was due to the common mislabeling of content as charset=iso-8859-1 in HTML files.

By 2015-06-12 0715 PDT it was gone; a reload in that browser landed on a search page.  Back in the original browser, I saved a copy of the original solicitation as usn_exploit_request-1.pdf (229 KiB).

For a very few minutes it could be found by solicitation number from that search page, though the link presented did not do anything when clicked. That result became usn_exploit_request-2.pdf (131 KiB).

Within a very few more minutes it had disappeared from the search, and could no longer be found at all, by solicitation or title, even when the the search included both active and archived documents. I included archived documents purely because I thought that even though it was well before the original archive date, perhaps the request had been filled, and the document archived early. That result became usn_exploit_request-3.pdf (183 KiB).

It seems to have been simply deleted. There are many reasons that this might happen. Perhaps too many news sources had discovered it, it was causing an unfavorable reaction, and it was pulled for simple PR reasons. Though one takeaway from this is yet another lesson in not assuming that government archives are complete.

For those who don't want to look at PDFs, here is some of the relevant text, emphasized, with a bit of commentary from me.

This is a requirement to have access to vulnerability intelligence, exploit reports and operational exploit binaries affecting widely used and relied upon commercial software. 

In a bit, they become rather more focused of exploits than the defense side of things.

These include but are not limited to Microsoft, Adobe, JAVA, EMC, Novell, IBM, Android, Apple, CISCO IOS, Linksys WRT, and Linux, and all others. 

So, all of the most commonly-used operating systems, including mobile, an interest in storage (and possibly VMWare), and some common networking gear (including a wireless router commonly deployed in home, small branch offices, etc.). As well those long-time security horror stories, JAVA [sic] and Adobe.

The vendor shall provide the government with a proposed list of available vulnerabilities, 0-day or N-day (no older than 6 months old). This list should be updated quarterly and include intelligence and exploits affecting widely used software. The government will select from the supplied list and direct development of exploit binaries.

So, either 0-day, or at least not too stale.

Completed products will be delivered to the government via secured electronic means. Over a one year period, a minimum of 10 unique reports with corresponding exploit binaries will be provided periodically (no less than 2 per quarter) and designed to be operationally deployable upon delivery.

This qualifies as high volume.

Based on the Governmentâ€TMs direction, the vendor will develop exploits for future released Common Vulnerabilities and Exposures (CVEâ€TMs). 

An obvious flaw here is that not even remotely all vulnerabilities ever receive a CVE number. Assignment of a CVE number, to the extent that it has any effect at, would tend to decrease the number of vulnerable systems, shortening the useful life of the vulnerability that the Navy had just purchased. Naval armament apparently includes footguns. Also, here is that rendering flaw.

Binaries must support configurable, custom, and/or government owned/provided payloads and suppress known network signatures from proof of concept code that may be found in the
wild. 

Suppress is a poor choice of words. What they are after are exploits that don't present a signature that is already known to suppliers of Network Intrusion Detection Systems (NIDS). I am curious about why host-based antivirus and IDS (HIDS) isn't mentioned.

Innocent? Incompetent? Generic FUBAR?

This could be completely innocent; even an interest in 0-day or low n-day exploits may be an effort to provide their penetration testers with better tools. In the few contest between government employees and the private sector that I am aware of, feds of any stripe were trounced.

So, why was it pulled? Bad PR? Poorly written? Even a mistaken project approval? These are all possibilities, but it seems just as likely that it was a coordination issue. That could take a couple of forms. One is purely financial: duplicate efforts between government departments might well lead to the same exploit being purchased, perhaps from two different vendors. 

The second form involves operations. Suppose that the Navy is unknowingly using a given vulnerability against a target of value x. Meanwhile, some random three-letter agency is using the same vulnerability to collect against a target of value 10x. If the Navy were detected, and a NIDS signature is created, the random three-letter agency could lose access.

Whatever the reason, it is not a sterling example of government competence. Someone needs to go shine their Cyber or something.

Anti-tracking May Lower Temperatures, and It May Not Matter

Commentary::Reliability
Audience::All
UUID: c078319b-b156-404f-a48b-1e639dd734b6

Earlier today, in the midst of an ongoing project, I noticed that

1. The temperature of a single physical CPU was running at 104° F; about 10° hotter than expected.
2. There were a large number of Firefox tabs open (40-odd), as is typical when abnormal high temps are seen.

My first reaction was my normal knee-jerk: This is totally FUBAR. The extent of tracking of Web tracking creeps me the hell out, and long experience with hardware has led to a lot of exposure to the notion that increased temperatures lead to decreased service life.

Knee-jerk reactions seldom lead to any good outcome.

Step one was to take a quick a quick shot at verifying the problem. Since Firefox 35, we have been able to set privacy.trackingprotection.enabled=true in about:config. I had done that the day before, (before the problem was noticed) but had not restarted Firefox. This time I bookmarked all pages, restarted Firefox, and reloaded all tabs. Temps returned to normal. Though based on a single datum, I may be able to assign a provisional cause. Go, me! Possible progress! I did some ancillary things, such as noting before and after memory usage (in case the kernel scheduler was part of the problem), etc.

None of that really mattered, though. In the greater scheme of things, it seems likely to be irrelevant. At the very least, a lot more open research is needed.

Temperature

First off, the widely-taught inverse correlation between temperature and lifetime, may be entirely bogus over large domains, and seems highly likely to be far more nuanced than is often taught.

Perhaps it matters in, say, applications related to RF power systems, such as radars and electronic countermeasures, but I haven't worked in those fields in years. Though messing up fire-control radars was tons-o-fun. I care a lot more about, to use an overly-generic term, IT.

HPC centers, the hyper-scale service providers, and large enterprises, all care about bills due to power. Supply costs, conversion efficiency, what is devoted to heat dissipation, thermal effects on the longevity of vast fleets of servers, etc.

Google does not provide OpenSource code at anything like the rate that they consume it, but they do provide landmark papers, which is at least partial compensation. Failure Trends in a Large Disk Drive Population (2007) was such a paper, and it implied that increased temperatures enhanced longevity.
Temperature Management in Data Centers: Why Some (Might) Like It Hot (SIGMETRICS12, University of Toronto) extended those results to DRAM, set some boundary conditions, etc.

In the same year (2012) No Evidence of Correlation: Field failures and Traditional Reliability Engineering was published, but I have not digested that yet. It's corporate, and I've only recently discovered it. I'm interested in the intersection of security and traditional reliability engineering (it's the 'A' in the CIA security triad, after all) you might want to read it as well.

Obviously, this is nothing like a comprehensive literature search. But I really doubt that simplistic schemes purporting to draw an obvious inverse correlation have any merit.

Tracking

Without taking extraordinary measures, anyone using the Web is going to be tracked. Usually very effectively, because tracking was baked into the Web, from protocols to economics, from the start.

Unfortunately, this post has gone on for too long. Not in terms of what should be covered, but in what I have time to cover. It's 1915, there are still Things To Do, and it is already going to be a late night.

Some things are going to be left for a possible future post. I tend to want to leave this sort of thing to more consumer-oriented security sites, where 'Don't Run Adobe Flash' might possibly help someone. An obvious problem is that many of the consumer sites do not cover tracking issues, and some of those that do are either biased or intentionally misleading. That sucks, but it isn't as if I am going to write a definitive post, complete with an economic history, this evening.

Open Thread: Is There Any Point in a Security Blog?

Commentary::Internals
Audience::All
UUID: 1af6f74e-015a-4cc6-a668-181a083b1850

Earlier today, I published #101, since 2013-03-17. A bit of a milestone, I guess, though I don't pay much attention to that sort of thing; I totally missed #100.

It does bring up a bit of a question, though. Some time ago, I mentioned that I wanted the date of publication right up top, where viewers would immediately see it. Because information gets stale rapidly. Arriving on a blog post from a search engine, reading some lengthy post, and then discovering that it is five years out of date (if you can discover it at all) is FUBAR.

It is even more FUBAR if you consider how many servers may have been incorrectly configured because due to dated information, etc. This one of the several reasons that blogs, particularly security blogs, and most definitely this one, suck. They are little, if at all, better than security trade press.

Here's the thing. At 100 or so posts, I can still maintain a mental image of what I have written in the past. I can go back to previous posts and and post an update.

This will not scale. What's more, I have an idea of posting about common themes (things that the security community might do better) that might conceivably have a greater impact. If I were to become successful at that, the specific content of individual posts on a given topic (log analysis comes to mind -- I could go on about that) is going to blur together. Success at one goal seams likely to lead to failure at another.

But I can't really set aside a block of time each month month, and delete the old stuff. First off, time is scarce. Second, I will break links from more-recent posts to what has become background information.

A blog seems to not be an appropriate tool. A wiki, or a document series on GitHub, might be more useful. Or perhaps using this blog to announce revisions to either. The thing is, there is a critical mass at which a community forms, feedback is received and acted upon, etc. A rule of thumb seems to be that perhaps one in a thousand blog viewers will comment. This blog gets a few hundred visitors per month, so it seems unlikely that a critical mass will ever be reached.

Perhaps I am wrong about this, and I just needed to announce an open thread. OK. Done and dusted. I have my doubts, but the idea has to be given a chance, if only to give potential community members a voice in describing something that might better fit their needs.

A SOHO Router Security Update

Commentary::Network
Audience::All
UUID: 6cb54b70-6f80-4959-bb8b-c8d20fc07e93

In April, 2014 I published Heartbleed Will Be With Us For a Long Time. One point of that post was the miserable state of SOHO router security. I referenced /dev/ttyS0 Embedded Device Hacking, pointing out that /dev/ttyS0 has been beating up on these devices for years. If you don't feel like reading my original post, the takeaway from that portion of the post is as follows.

Until proven otherwise, you should assume that the security of these devices is miserable. I have private keys for what seems to be 6565 combinations of hardware/firmware combinations in which SSL or SSH keys were extracted from the firmware. In that data, 'VPN' appears 534 times.

The database was hosted at Google Code, which Google has announced will be shutting down. I am interested in the rate at which embedded system security is becoming worse (as it demonstrably is) and meant to urge /dev/ttyS0 to migrate, if they hadn't already done so. I wanted the resource to remain available to researchers. Google Code doesn't seem to provide (at least in this case) a link to where migrated code might have gone, but searching GitHub turns up four repositories. Apparently I am not the only person interested in the preservation of this work, and the canonical /dev/ttyS0 repository is still available.

/dev/ttyS0 also has a blog. Visiting that today, I find that they have recently been beating up on Belkin and D-Link. That's a bit sad, because in simpler times, I carried products from both of these vendors in my hardware case.

There is no room for sentimentality in this business. But there is room for keeping track of trends, and gazing into an always-cloudy crystal ball, trying to extrapolate trends, and spot emerging threats. Sometimes that is ridiculously easy; I hereby predict:

a) the Internet of Things will be a source of major security/privacy breaches in 2015 [1]
b) consumers will neither know nor care, in any organized manner
c) businesses will continue to buy 'solutions' that are anything but

In short, things will continue to get worse, at an increasing rate, as they have always done.

[1] I often tell a simplistic story (to non-practioners) about how I came to be interested in security and privacy, equating the two as a simple scaling matter. Privacy is security on a small scale, and the obverse. That is not actually true; there are technical differences, down to the level of which attacks are possible, let alone which matter. But that is a whole different post.