The Nested Mechanical Turk

(Speculation, and not the whole story ... but fits some facts):

For more than a decade, foreign influence operations have used techniques from technology, marketing, and social media -- tracking interaction/propagation, correlating with marketing metadata, A/B testing, etc. -- to map people to their "trigger" topics: ones that emotionally activate them and short-circuit their reasoning, things "close to the bone" (things they either love, hate, or fear). It's important to note that these trigger topics are often rooted in deep, understandable, and often positive instincts -- patriotism, group bonding, protecting children, etc. These chess pieces are already on the board.

Once mapped, social subgraphs can then be analyzed to find supernodes -- the accounts (real or bot) that are best at producing highly viral content in each subgraph. These accounts can then be used to seed specific content that gently starts to map trigger topics to target belief outcome -- to *condition* people, in the classic, operant conditioning, Pavlovian sense.

By aligning trigger topics with belief outcomes slowly over time, target populations can be pushed along a spectrum of beliefs until their behavior seems quite at odds with their beliefs.

Some populations are more vulnerable to this than others, either by nature or nurture. To exploit this, subgraph data, including influence outcomes, can be mapped to demographic data (age, race, gender, political or religious affiliation, buying habits, data etc.), as well as data from public leaks. This correlation enables automation of identifying, and efficiently focusing effort on, vulnerable populations.

The element of surprise is also important. Weaponizing these subgraphs takes time ... and can be countered if spotted too early! So this infrastructure is also used to study which methods are *more likely to not leak out too soon*. (Private chat groups, on Facebook and elsewhere, seem efficient here.)

Another important element is inoculation: conditioning target populations to ignore, and even be actively hostile to, factual talking points that might otherwise persuade a reasonable person. (This is why reactions to such talking points can be startling immediate, automatic, homogeneous, and dismissive. It may also be a factor in why polling is misleading; it seems feasible to condition people to avoid, or even actively lie to, pollsters).

Taken in total, it should be clear why externally observable outcomes might seem inexplicable -- and why outsiders dipping into these input streams can find it so disorienting and self-contradictory. By the time visible markers of this influence start to "bubble up", the Overton window of what its victims will believe has already dramatically shifted. Put another way: when a public figure starts dropping specific talking points to their base that seem instantly popular "out of the blue" ... it was only out of the blue to you. That topic was a submerged iceberg -- one that the target population has been exposed to for months or years. Only when the benefits of exposing the tip of that iceberg are judged to be worth the reveal, will it be "burned" (to mix my metaphors).

It should also be clear why traditional reasoning about root causes ("What caused this?" punditry) seems to keep falling short. By minimizing or skipping entirely the role of disinformation, think pieces and news coverage trying to leverage pre-social-media concepts to grapple with unexpected outcomes are woefully missing the mark. It should be obvious that part of the reason for this is that they have no tools to observe or assess this influence.

This should also help to explain that while protecting the voting process itself is necessary, it is not sufficient; and why relatively little money might need to be spent on campaigning:

There is less need to hack the vote ... if you've already hacked the voter.

The tools of digital marketing have been repurposed to weaponize your friends, co-workers, and family, in an almost Manchurian Candidate way. Which -- to me personally -- means that we should not be fully blaming the victims here. Were many of them already like this? Probably; exploiting the subgraph efficiently means discovering and exploiting the pieces that were already on the chessboard. But would those people have taken things to this extreme without amplification at scale? Probably not. 

The people are on the outside, and the machine is on the inside.

Some questions:

• Who is running the machines?
• How long ago did AI get applied to accelerate them?
• What are the visible signs of machines acting in tandem, or in opposition?
• Assuming it's true ... what can we do about it?

References:

The War on Pineapple (CISA)

‘The Great Hack’: Cambridge Analytica is just the tip of the iceberg (Amnesty International)

Sort by Controversial (Scott Alexander)

Fixing "error code: 1275" when using PHLASH to update BIOS on ancient laptops

If you happen to be turning old laptops into Chromebooks or something, and you're trying to flash the BIOS on an ancient laptop, and you can't do it from a DOS boot USB because it's a Windows-only flash utility, and you run into something like this:

Cannot load driver C:\dell\BIOS\WINPHLASH\PHLASHNT.SYS.

Please check your accounts, if you have no administrator privilege, please login again!

This driver has been blocked from loading

Error code: 1275

... then you're not alone. 

Here's what I tried that didn't work:

• Booting from a Windows 7 universal install disc. Trying to run PHLASH threw the error "the subsystem needed to support the image type is not present". I suspect this is because the install disc is primarily 64-bit, but PHLASH is 32-bit, but that's just a guess.
• Installing 64-bit Windows 7. The driver wouldn't load, throwing "Access is denied" in PHLASH.LOG, even when running as true Administrator. My theory is that this is because a newer kind of library or approach is needed by Windows 7 to write to the BIOS while Windows is loaded, and newer versions of the OS block the old method.
• Installing Windows XP. I couldn't find a version that had a variant of the offline algorithm used to validate the license key that recognized the key that the laptop actually shipped with. If I'd figured out how to do this, I suspect that it might have worked.

What did work was to boot from a 32-bit Windows Vista install/rescue CD. PHLASH was able to successfully run from there. 

Digging up an ancient BartPE might also work.

Updating the BIOS didn't fix my actual problem (some of the Neverware CloudReady menus are entirely black, as if there's some kind of video-driver overlay problem). 

But at least this Inspiron 1501 now has a 2008 BIOS instead of a 2005 one. "I'm doing my part!"

TIL: the unexpected back story of Mah Nà Mah Nà

Just read the Wikipedia article and the 2011 Slate piece.

... and then enjoy them:

The original, "Mah Nà Mah Nà", from the 1966 Italian movie "Svezia, inferno e paradiso" ("Sweden: Heaven and Hell")

The original 1969 Sesame Street version (video)

The 1971 Benny Hill version (audio only)

The version from 101st episode of the Muppet Show (video)

The 2011 Muppets Tonight sketch parody, featuring Sandra Bullock

The entry on the Muppet Wiki - many, many differnent versions and references

(Interestingly, the scat sequences actually vary from version to version, borrowing from a variety of musical sequences.)

Notes on passphrases as passwords

As we promote passphrases, we need to make it clear that not all phrases are created equal.

Phrases that match the rhythm of human language, and phrases that are even only somewhat based on anything that has already appeared anywhere -- lyrics, song titles, movie quotes, phrases that appear on Wikipedia, etc. -- are subject to guessing. The password cracking community is hot on this trail, and really pushing the envelope in this area. "Myd0ghasfle@s!" is certainly better than "abcdefgh" or "Summer2015!", but it is not sufficiently resistant to state-of-the art attacks. These attacks can quickly combine phrase lists with transformational rules, and really tap into the psychology of how people select naive passphrases.

Put another way ... we need to make sure that users do not walk away thinking that "itsmypartyandillcryifiwantto" is a good passphrase.

One problem is the word "passphrase". The layperson expects something called a "passphrase" to be a real, grammatically correct phrase, but that's exactly what we don't want them to use. Such phrases are inherently easier to guess. Only randomly-selected words provide resistance to both brute force and rules-based attacks.

The best balance of "memorizability" and strength is to use "Diceware"-style passphrases, just as that XKCD suggested (but perhaps with some adjustments to the size of the word pool and number of words). The words need to be truly randomly selected, and drawn from a relatively large pool of words that are nevertheless familiar enough to be easily remembered. An open-source, client-side, JavaScript implementation is available here, and some great statistics about the strength of the resulting passwords are shown there.

The sheer numbers behind Diceware-style passphrases are significant. When implemented correctly, even if I tell you which dictionary I've drawn from, and how many words that I used, brute-force cracking is still infeasible for any modern (and even many retired/outdated) password hashing methods.

One implementation hitch is that many sites either A) still apply naive complexity requirements to very long passwords, or B) don't allow passwords longer than a certain length.

To make Diceware-style passphrases compatible with naive complexity rules, users can add their own additional rule. Such a rule can make randomly generated passphrases compliant with such complexity rules. For example, I can always capitalize the first word, and appending "1!" at the end ("Correct horse battery staple1!") Even if I tell someone what my personal additional rule is, brute-force cracking is still infeasible.

If a website has an artificially low length cap (such as 15 or 20 characters), rather than trying to cram a shorter passphrase in, I recommend falling back to a randomly generated password that maxes out the allowed length, and storing it in a password manager.

The best things that web developers can do to support good passphrases is to:

• relax complexity requirements once a sufficient length is met, and
• support a high maximum password length (such as 128 characters)

Now with the SSLs

This blog (along with all other blogspot.com blogs) is now available over HTTPS:

https://roycebits.blogspot.com/

The RSS and Atom feeds are also HTTPS-aware:

https://roycebits.blogspot.com/feeds/posts/default?alt=rss
https://roycebits.blogspot.com/feeds/posts/default?alt=atom

Please update your bookmarks and feeds accordingly.

Geek note: you can see the Qualys SSL Labs Server Test results for this new setup. (Not perfect, but it's progress!)

Note: HTTPS is not yet available when wrapping a blogspot.com blog within your own domain (such as blog.example.net).

Hash filtering - an appeal to more than vanity

tl;dr: The major password-cracking projects should add support for general hash substring search (vanity hashes, partial collisions, etc.).

What is a vanity hash?

A vanity hash is a hash that contains an interesting substring. For example, my actual Bitcoin address is:

1AzVVHTijMGoWzPtUJoWkF5u6vyS1NcTzj

But it would be cooler if it was this:

1RoycehyNKfRC4nN5jKruZpjMKwNviQRb

That's a vanity hash. Finding one requires a brute-force search. The more characters you want, the harder it gets -- exponentially harder. But even just a few characters can be good enough.

Current examples of vanity hashes

We humans are vain creatures -- so when hashes are used as public identifiers, we want to personalize them:

• Bitcoin addresses can be "vanity addresses".
• Onion hashes and GPG keys can be vanity hashes.
• Tripcodes (used to prove identity on image boards) have vanity hash tools that can search for descrypt-like vanity hashes (at speeds in the 950Mh/s range!)
• Git commit hashes can be vanity hashes if patched to support it.
• Some folks want to personalize certificate signatures.

More than vanity

Searching for a vanity hash is really just an attempt to find hashes with certain content. Other efforts seek hashes with specific content for other reasons - hash collisions, partial collisions, etc. More generally, these are searches for hash substrings.

Why hash substring search is interesting

Finding substrings in hashes isn't just about vanity. Bringing hash substring search into the cracking platforms would enable other interesting work:

• Experimenting with collisions and partial collisions. This is a potential attack surface that is not adequately publicly explored. Nation-states are almost certainly capable of locating near-collisions for some hashes. When you check a download hash, how often is that check only a cursory visual check? True collisions for slow hashes are nigh-infeasible, of course -- but near-collisions may be interesting.
• Demonstrating weaknesses. For example, short GPG key IDs can have collisions.
• Filtering for hashes with broad properties (instead of just substrings). Hashes that contain only digits, or only letters, or letters and digits alternating, or only lower case (for hashes that distinguish case). Perhaps only a curiosity today, but they might be interesting in the future.
• Automatic/loose discovery of similar strings. This would be a nice-to-have at some point, but searching by edit distance would complement substring searching nicely. A minimum or maximum edit distance could be specified to find strings that are "close enough". One of the most common measurements of edit distance is Levenshtein distance, which has been implemented in most languages, and implemented efficiently on GPU.
• Working with non-contiguous substrings. Most vanity-hashing tools won't let you search for a hash that begins with "[aA][bB][lL][eE]" and ends with "[eE][lL][bB][aA]". But password crackers' mask syntax is perfect for this.
• Unforeseeable innovation. Once this capability is available across all hash types, people will tinker with it, revealing new use cases. I've seen some CTFs that involve searching for specific substrings in hashes. I think they're on to something.

Calling them "vanity hashes" doesn't do justice to the potential. I think that the activity of hash substring search -- partial collisions, vanity hashes, etc. -- needs a better name.

Let's call it hash filtering.

Why the password crackers are the best place to do hash filtering

• It's efficient. No one is better positioned to implement hash filtering than the password crackers -- and doing it anywhere else is a waste of resources. Each standalone vanity-search implementation reinvents the hash bruteforcing wheel - usually poorly: This rarely approaches the speeds that JtR and hashcat are capable of (though there are exceptions). The Bitcoin folks have an edge today because of FPGAs, but I expect this gap to close.
• It's high leverage. If implemented as a general framework within password crackers, all current and future hash types automatically inherit substring search capability, with little additional effort.

How the password crackers might respond

• Sound great! That would be awesome, but not likely to be the first reaction. So ...
• OK -- but it should be done as a separate executable. This is a waste of time. The best features of professional-grade password crackers -- core brute-force power, Markov, forking/parallelism, session management, masks, device selection, wordlist management, etc. -- would either be unnecessarily duplicated, left out, or suffer from bit rot.
• No. It will slow down cracking too much. Not necessarily. Hash filtering should be implemented as an early pre-optimization step, so that you only have to take the inevitable speed hit if you want hash filtering. Regular cracking would be unaffected.
• No. We're not interested in vanity hashing as a concept. That would be a mistake. Vanity hashing is already driving interest, contribution -- and even innovation (like entirely new S-boxes).
• No. It might attract noobs. Unavoidable -- but this should be offset by an influx of insight and talent. Also, we have to feed a certain number of noobs to Xanadrel, the Sarlacc of #hashcat. ;)
• No. It adds complexity. Technically true, but it should be a largely one-time cost. Also, I think that implementing Levenshtein distance on GPU would be kinda fun if I was atom or Sayantan. ;)
• No. Hash filtering itself will be too slow. By its nature, it will, indeed, be much slower than password cracking. But if it can be pre-optimized (see previous point), then it can take advantage of the rest of the cracking support structure, so that hash filtering will be faster, more portable, and easier to use than it would be anywhere else.

Implementation suggestions

• Allow the user to specify a "hash filter", using existing mask syntax. This would automatically enable specifying one or more desired substrings anywhere in the hash -- beginning, end, or middle -- as well as both non-contiguous strings and loose matching by character set.
• On the command line, consider long options with names like --hash-filter [mask] and --edit-distance [integer]. Or name it something else -- but keep it consistent across projects.
• Implement in the pre-optimization pass, so that the slowdown introduced by examining each hash will only kick in when hash filtering is explicitly requested.
• Add simple sanity checking. If the user supplies a mask that is longer than the target hash, warn rather than silently truncating. Also, warn if the user wants to filter for a mask that isn't possible (for example, if their descrypt filter's last character is not within [.26AEIMQUYcgkosw]).

Potential bounty?

If this proposal is not obviously compelling, I will consider setting up a bounty (or charitable donation of the winner's choosing). The bounty would go to each major natively Linux-based project (John the Ripper or hashcat) that incorporates hash filtering. Edit distance would be optional.

If you want to go in on a bounty, contact me and I'll do the Bountysource setup.

The ask

Bring vanity hashing and its kin into the fold -- generalize it into hash filtering that can be applied to all current and future hashes. I think that the results will bear interesting fruit.

Updated: to use a valid example Bitcoin vanity.

Cyber and information security certification frequency in job descriptions - 2015-10 edition

A rough study of Indeed acronym frequency when coupled with the word "security":

CISSP  12859 ISC main
ITIL  7233 see also ITILv3 below (+162)
CISA  5374 ISACA auditor
CISM  3927 ISACA manager
CompTIA 2857 a+, security+, network+, etc
GIAC  2368 (any)
CEH  2329 EC-Council
GSE  1501 GIAC expert/advanced
SSCP  1328 ISC – CISSP “lite”
GCIH  1279 GIAC incident handling
CRISC  804 ISACA risk
“CCNA Security” 660 Cisco
GPEN  554 GIAC pentester
OSCP  475 Offensive Security
GSLC  332 GIAC's CISSP analog
GWAPT  253 GIAC web pentest
“CCNP Security” 235 Cisco
CCSE  228 Checkpoint
GREM  219 GIAC reverse engineering malware
ITILv3  162 See also ITIL above (+7233)
“CCIE Security” 155 Cisco
GCFE  140 GIAC forensic examiner
OSCE  124 Offensive Security – advanced
CSIH  100 Carnegie Mellon
GXPN  73 GIAC exploit dev and advanced pentest
GCWN  66 GIAC Windows security
“Cisco CSS” 29 Cybersecurity Specialist – hard to search for right
WCAN  4 Wireshark