Author Archives: Robert Hansen

About Robert Hansen

Robert Hansen is the Vice President of WhiteHat Labs at WhiteHat Security. He's the former Chief Executive of SecTheory and Falling Rock Networks which focused on building a hardened OS. Mr. Hansen began his career in banner click fraud detection at ValueClick. Mr. Hansen has worked for Cable & Wireless doing managed security services, and eBay as a Sr. Global Product Manager of Trust and Safety. Mr. Hansen contributes to and sits on the board of several startup companies. Mr. Hansen has co-authored "XSS Exploits" by Syngress publishing and wrote the eBook, "Detecting Malice." Robert is a member of WASC, APWG, IACSP, ISSA, APWG and contributed to several OWASP projects, including originating the XSS Cheat Sheet. He is also a mentor at TechStars. His passion is breaking web technologies to make them better. Robert can be found on Twitter @RSnake.

#HackerKast 37: More router hacking, StegoSploit, XSS Polyglot and Columbia Casualty Insurance refuses to pay Cottage Health

One more lonely week without Matt Johansen as Jeremiah and I have braved another HackerKast on our own. Thankfully we were comforted by some very interesting stories. Most of them were technical but one of them was around insurance.

First up was about router hacking – one of Jer and my favorite topics. It turns out someone has been automating intranet hacking using the browser to attack various different SOHO routers and firewalls. This is neat because it’s actually in the wild, being used. It attempts various passwords, and ultimately tries to re-write DNS or route users to another location. Pretty nasty. I had a brief conversation with NoScript’s author, Giorgio Maone who is considering writing Application Boundary Enforcement into a stand-alone plugin.

Then we talked about two stories, StegoSploit and something called XSS Polyglot. They’re different takes on the same issue. If you need to do some hosting of content on another domain for some reason (typically payloads) you can do so in an image or using Flash. Both are great articles and they both do a pretty good job of breaking CSP in certain implementations.

Lastly we talked about an insurance provider called Columbia Casualty Insurance who refuses to pay out Cottage Health due to lax security. Namely, Cottage Health allegedly failed to do the things their policy required of them. If you don’t do what you say you’re doing, it’s hard to see why they would be obligated to pay out. Either way, it’s an interesting case, and probably the first of many to come.

Resources:

An Exploit Kit Dedicated to CSRF
StegoSploit – Metasploit in an SVG image
Using Ads To Bypass CSP
Insurer Cites Lax Security in Challenge to Cottage Health Claim

Notable stories this week that didn’t make the cut:
Disconnect.Me Files Antitrust Case Against Google In Europe Over Banned Anti-Malware Android App
The Efficacy of Google’s Privacy Extension
AppSec USA: Full List of Accepted Talks
Criminals use IRS website to steal data on 104,000 people
Weaponizing code: America’s quest to control the exploit market
The Security Issue of Blockchaininfos and Android
Thousands of Websites Block Congress in Protest of NSA Surveillance and this Naked campagin
SourceForge Grabs Gimp For Windows And Wraps It With AdWare
I Fooled Millions Into Thinking Chocolate Helps Weight
AdBlock Wins in Court Twice in Weeks
Ross Ulbricht Pleads For Leniency
CareFirst Breached
St. Louis Federal Reserve Had DNS Hijacked
LaZagne – Password Recovery Tool
How Many Million BIOSes Would You Like To Infect
Facebook Supports PGP
Airbus confirms software brought down A400M transport plane

#HackerKast 36: Moose Router Worm, Adult Friend Finder male users hacked, Firefox and advertising, WHS Stats Report, and IRS Data Breach

It was just Jeremiah and me again today, as Matt is shamelessly galavanting around Europe at various security conferences (I think it’s safe to hate him for it, isn’t it?). But we had a ton of interesting stories this week to cover and didn’t have much time to do it.

The first up was the Moose Router Worm – similar to the Internet Census Project, it used default usernames and passwords to compromise remote routers. We don’t know how many routers were compromised but it was a lot, I’m sure. Jer seems to think that routers shouldn’t even have this feature at all – and I’m inclined to agree.

It was a bad week for Adult Friend Finder, but an even worse week for their users, who had user account data stolen and published on the Internet. The data dump was incomplete and only comprised about 300M worth of data. Also, interestingly enough, it seemed to contain only data from the male users, which implies that it’s probably more about who is most easily blackmailed and less about what the actual adversaries have.

Next up we discussed Firefox and their rather strange move to build an advertising platform into the browser. Their reasoning is complicated, but it seems to revolve around a mix of making money and doing right by their users – except I don’t recall a user ever asking for this. Meanwhile one of Mozilla’s own employees wrote up a great paper on how users with ad blocking and privacy protection can save up to 40% bandwidth and page load time on the top Alexa sites. Shortly after, that same employee promptly left the company under somewhat mysterious circumstances.

Then we covered the stats report. You’ll have to download it to see for yourself, but there are a great number of interesting findings in there. For instance it appears to refute the idea of a best practice. There just doesn’t seem to be any one security factor that will prevent people from being hackable. Maybe they work in some combination, but not in a vacuum. Check it out.

Lastly, we briefly touched on the IRS data breech (if you can call it that) where north of 100k people’s tax data were stolen. This is almost certainly the result of stealing user data through something like Zeus or other public places and combining data to attempt to log in as the user. Jer’s point couldn’t be more clear – Social Security Numbers aren’t a good password, stop using them. If you are, you’re site is hackable.

That’s it for the week, I hope you enjoyed it! We’ll be back next week. Rate, subscribe, and give us feedback on things you’d like us to cover.

Resources:
Moose Router Worm
Adult Friend Finder Compromised
Firefox Will Soon Get Sponsored Suggested Tiles Based On Your Browsing History
Tracking Protection for Firefox at Web 2.0 Security and Privacy 2015
Website Security Statistics Report 2015
100k+ Tax Records Breached from the IRS

Notable stories this week that didn’t make the cut:
Android Chrome ARC Welder
Chrome Extension Transmits Information Via Sound
Phuctor – RSA Super Collider
Two Diablo III players stole virtual armor and gold — and got prosecuted IRL
New Cyber Security Legislation On Export of Cyber Weapons (Wassenaar) article 1
New Cyber Security Legislation On Export of Cyber Weapons (Wassenaar) article 2
New Cyber Security Legislation On Export of Cyber Weapons (Wassenaar) article 3
FCC Warns Internet Providers That They’re On the Hook For User Privacy
Adblock Browser for Android
Hacking Starbucks for unlimited coffee
Logjam Attack against the TLS Protocol article 1
Logjam Attack against the TLS Protocol article 2
Specially Crafted Message Crashes iPhones article 1
Specially Crafted Message Crashes iPhones article 2
40% of Docker Images Are Vulnerable to High Severity CVEs

#Hackerkast 35: Airplane hacking, United bug bounty, and SEA hacks Washington Post

Hey Everyone! It was just Jeremiah Grossman and me today, as Matt Johansen is overseas this week attending various security conferences. So we braved on and did a short one with just three major articles.

First we covered Airplane hacking and a bit of drama that has been unfolding in the mainstream press related to hacking an airplane while on one. Jeremiah made the point that it’s not just illegal it’s also dangerous from a personal safety perspective. Rule number 1 of hacking – don’t hack the airplane while you’re still on it.

Then we discussed a bit about the United bug bounty program that was just announced. Although it’s interesting, it still doesn’t cover the major thing the public is worried about. Learning who is flying is bad, but doing something bad to an airplane is much much worse. And it does beg the question, why does the bounty program not cover the airplane if there are no flaws in airplanes?

Lastly we covered the latest SEA hack of Washington Post by way of their CDN provider, InstartLogic. Jer made the point that hacking InstartLogic is just the canary in the coal mine: it’s the other hacks that you don’t see until a year or two down the road that are really troubling. In some ways, the SEA is doing us a huge favor by letting us know about the issues without causing any real harm in the process.

Resources:
Airplane Hacking?!?!
United Rewards Bug Bounties with United Miles
SEA hacked Washington Post’s CDN InstartLogic

Notable stories this week that didn’t make the cut:
Firefox is going to Depreciate HTTP
Anti-gay demonstrators advertise gay porn site after their domain expires
Adblockers are immoral vs
Priority of Cnstituencies
Why a Law Firm is Baiting Cops With A Tor Server
VENOM Exploit Against QEMU and Xen Floppy Discs
Safari address-spoofing bug could be used in phishing, malware attacks

Magic Hashes

For more than the last decade, PHP programmers have been wrestling with the equals-equals (==) operator. It’s caused a lot of issues. This has a particular implication for password hashes. Password hashes in PHP are base16 encoded and can come in the form of “0e812389…”. The problem is in == comparison the 0e means that if the following characters are all digits the whole string gets treated as a float. This was pointed out five years ago by Gregor Kopf, two years ago by Tyler Borland and Raz0r and again a year ago by Michal Spacek and Jos Wetzels but this technique is making more waves this past week.

Below is a list of hash types that when hashed are ^0+e\d*$ which equates to zero in PHP when magic typing using the “==” operator is applied. That means that when a password hash starts with “0e…” as an example it will always appear to match the below strings, regardless of what they actually are if all of the subsequent characters are digits from “0-9″. The implication is that these magic numbers when hashed are treated as the number “0” and compared against other hashes, the comparison will evaluate to true. Think of “0e…” as being the scientific notation for “0 to the power of some value” and that is always “0”. PHP interprets the string as an Integer.

<?php
if (hash('md5','240610708',false) == '0') {
  print "Matched.\n";
}
if ('0e462097431906509019562988736854' == '0') {
  print "Matched.\n";
}
?>

What this practically means is that the following “magic” strings are substantially more likely to evaluate to true when hashed given a completely random hash (E.g. a randomly assigned password, nonce, file hash or credential). Likewise if a straight guess of a hash is required the associated hashes are proven to be typed into the float “0” with the “==” comparison operator in PHP, and if another hash in a database also starts with a “0e…” the comparison will evaluate to true. Therefore, the hashes can also be substantially more likely to evaluate to true when compared with a database of hashes, even if they don’t actually match. Many cookies, as an example are simply hashes, and finding a collision becomes much more likely depending on how many valid credentials are in use at the time of test (See: Birthday paradox).

Use Case 1: Use the “Magic” Number below as a password or as a string that you expect to be hashed. When it is compared against the hash of the actual value, and if they both are treated as “0” and therefore evaluated as true, you will be able to log into the account without the valid password. This could be forced to happen in environments where automatic passwords are chosen for users during a forgot password flow and then attempting to log in immediately afterwards, as an example.

https://example.com/login.php?user=bob&pass=240610708

Use Case 2: The attacker can simply take the example in the Hash column in the table below and use it as a value. In some cases these values are simply done as a look-up against known values (in memory, or perhaps dumped from a database and compared). By simply submitting the hash value, the magic hash may collide with other hashes which both are treated as “0” and therefore compare to be true. This could be caused to happen

https://example.com/login.php?user=bob&token=0e462097431906509019562988736854

Hash Type

Hash Length

“Magic” Number / String

Magic Hash

Found By
md2 32 505144726 0e015339760548602306096794382326 WhiteHat Security, Inc.
md4 32 48291204 0e266546927425668450445617970135 WhiteHat Security, Inc.
md5 32 240610708 0e462097431906509019562988736854 Michal Spacek
sha1 40 10932435112 0e07766915004133176347055865026311692244 Independently found by Michael A. Cleverly & Michele Spagnuolo & Rogdham
sha224 56
sha256 64
sha384 96
sha512 128
ripemd128 32 315655854 0e251331818775808475952406672980 WhiteHat Security, Inc.
ripemd160 40 20583002034 00e1839085851394356611454660337505469745 Michael A Cleverly
ripemd256 64
ripemd320 80
whirlpool 128
tiger128,3 32 265022640 0e908730200858058999593322639865 WhiteHat Security, Inc.
tiger160,3 40 13181623570 00e4706040169225543861400227305532507173 Michele Spagnuolo
tiger192,3 48
tiger128,4 32 479763000 00e05651056780370631793326323796 WhiteHat Security, Inc.
tiger160,4 40 62241955574 0e69173478833895223726165786906905141502 Michele Spagnuolo
tiger192,4 48
snefru 64
snefru256 64
gost 64
adler32 8 FR 00e00099 WhiteHat Security, Inc.
crc32 8 2332 0e684322 WhiteHat Security, Inc.
crc32b 8 6586 0e817678 WhiteHat Security, Inc.
fnv132 8 2186 0e591528 WhiteHat Security, Inc.
fnv164 16 8338000 0e73845709713699 WhiteHat Security, Inc.
joaat 8 8409 0e074025 WhiteHat Security, Inc.
haval128,3 32 809793630 00e38549671092424173928143648452 WhiteHat Security, Inc.
haval160,3 40 18159983163 0e01697014920826425936632356870426876167 Independently found by Michael Cleverly & Michele Spagnuolo
haval192,3 48 48892056947 0e4868841162506296635201967091461310754872302741 Michael A. Cleverly
haval224,3 56
haval256,3 64
haval128,4 32 71437579 0e316321729023182394301371028665 WhiteHat Security, Inc.
haval160,4 40 12368878794 0e34042599806027333661050958199580964722 Michele Spagnuolo
haval192,4 48
haval224,4 56
haval256,4 64
haval128,5 32 115528287 0e495317064156922585933029613272 WhiteHat Security, Inc.
haval160,5 40 33902688231 00e2521569708250889666329543741175098562 Michele Spagnuolo
haval192,5 48 52888640556 0e9108479697641294204710754930487725109982883677 Michele Spagnuolo
haval224,5 56
haval256,5 64

To find the above, I iterated over a billion hashed integers of each hash type to attempt to find an evaluation that results in true when compared against “0”. If I couldn’t find a match within the billion attempts I moved on to the next hashing algorithm. This technique was inefficient but it was reasonably effective at finding a “Magic” Number/String associated with most hash algorithms with a length of 32 hex characters or less on a single core. The one exception was “adler32″ which is used in zlib compression as an example and required a slightly different tactic. The moral of the story here is for the most part the more bits of entropy in a hash the better defense you will have. Here is the code used I used (adler32 required a lot of special treatment to find a valid hash that didn’t contain special characters):

<?php
function hex_decode($string) {
  for ($i=0; $i < strlen($string); $i)  {
    $decoded .= chr(hexdec(substr($string,$i,2)));
    $i = (float)($i)+2;
  }
  return $decoded;
}
foreach (hash_algos() as $v) {
  $a = 0;
  print "Trying $v\n";
  while (true) {
    $a++;
    if ($a > 1000000000) {
      break;
    }
    if ($v === 'adler32') {
      $b = hex_decode($a);
    } else {
      $b = $a;
    }
    $r = hash($v, $b, false);
    if ($r == '0') {
      if(preg_match('/^[\x21-\x7e]*$/', $b)) {
        printf("%-12s %s %s\n", $v, $b, $r);
        break;
      }
    }
  }
}
?>

I didn’t have to just use integers as found in most of the results but it was slightly easier to code. Also, in hindsight it’s also slightly more robust because sometimes people force the passwords to upper or lowercase, and numbers are uneffected by this, so using integers is slightly safer. However, in a practical attack, an attacker might have to find a password that conforms to password requirements (at least one upper case, one lower case, one number and one special character) and also is evaluated into zero when hashed. For example, after 147 million brute force attempts, I found that “Password147186970!” converts to “0e153958235710973524115407854157″ in md5 which would meet that stringent password requirement and still evaluate to zero.

To round this out, we’ve found in testing that a 32 character hash has collisions with this issue in about 1/200,000,000 of random hash tests. That’s thankfully not that often, but it’s often enough that it might be worth trying on a high volume website or one that generates lots of valid credentials. Practically this is rather difficult to do, thankfully, without sending a massive amount of attempts in the most likely instances. Note: there are similar issues with “0x” (hex) and “0o” (octal) as well but those characters do not appear in hashes, so probably less interesting in most cases. It’s also worth mentioning that “==” and “!=” both suffer from the same issue.

Are websites really vulnerable to this attack? Yes, yes, they are. This will surely cause issues across many many different types of code repositories like this and this and this and this to name just a few. Similar confusion could be found in Perl with “==” and “eq”, as well as loosely cast languages like JavaScript as well. (Thanks to Jeremi M Gosney for help thinking this through.) I wouldn’t be surprised to see a lot of CVEs related to this.

Patch: Thankfully the patch is very simple. If you write PHP you’ve probably heard people mention that you should be using triple equals “===”. This is why. All you need to do is change “==” to “===” and “!=” to “!==” respectively to prevent PHP from attempting to guess the variable type (float vs string). Some people have also recommended using the “hash_equals” function.

WhiteHat will now be testing this with both our dynamic scanner and static code analysis for WhiteHat customers. If you want a free check please go here. This is rather easily found using static code analysis looking for comparisons of hashes in PHP. Lastly, if you have some computing horsepower and have any interest in this attack, please consider contributing to any value/hash pairs that we haven’t found samples for yet or for hash algorithms we haven’t yet listed.

Speaking of Government Backdoors

After Alex Stamos’ stand off with Admiral Mike Rogers, I got to thinking about what the Admiral must be saying when he insisted that government “front doors” were technically possible to create in a way that didn’t give them ultimate access. Then a story came out about a split-key approach that is being studied. Let me explain to you why that is a bad idea and propose a technically less dangerous one.

Barring any conversations about the ethics, the legal conundrums, the loss of trust, the weakening of freedoms, the chilling effect, or the future where we have to provide similar access to any government that asks, there are some legitimate reasons this design is bad. First a brief primer on how split-keys work.

Let’s take a simple encryption algorithm that just uses the password “Will Wheaton” to decrypt the plaintext. Now let’s say government agency A (the FBI/NSA or some similar organization) has access to the first half of the password “Will”. “Will Wheaton” is a very weak password, but it’s made significantly weaker when one party knows at least half of the secret. But it gets worse. Let’s say government agency B (the FISA court) has the second half of the password “Wheaton”. Eventually they need to combine the password somewhere. That physical place is a place where both halves of the password have to be typed in at the same time. Let’s call it a SCIF for argument’s sake.

In this example the SCIF is now the one place where all secrets go, and makes it a prime target to attack. Now both parties can see the data, instead of it just being one party. There may be situations where truly only one party should see the data. If the password is always the same for every piece of encrypted information for all conversations, it practically guarantees abuse once both halves are known. Not only is it significantly easier to break the original encryption since both parties have half the key material, but it has also created a single place where two parties now have to combine their two halves and it is far more likely to be abused.

What happens when access to that user’s data is no longer deemed useful? Does the key no longer become useful? What if they find out they were mistaken and the data they were looking at is benign? Is there a way to disable their password? No – that’s not how passwords or keys work when they have to work everywhere all the time. All they can do is tell Apple, or Google or whoever created the backdoor to change the user’s keys and/or create a different backdoor password to be created. That’s one of the major drawbacks of this model. It could also inadvertently tip off the suspect in the process if they notice a new key being issued as well, depending on how it was implemented.

Now let’s take a slightly different scenario where Apple/Google had a rolling window where passwords changed every day, say. One day it was “Will Wheaton” the next it was “Darth Vader” and so on. That way the FBI/NSA and the FISA courts could subpoena any piece of information but it had to be marked with a certain time period (say ten days and they would use their corresponding 10 keys split into two parts each for a grand total of 20 key-halves). That way, they only had access to certain pieces of information and only for that one conversation, and nothing after that time period. That has a better chance of being successful, but still relies on the parties to come together at some point and allows them both to see the resultant classified material.

A more useful approach would be to have four sets of keys for each time-slice of one day. Key 1 and 2 belonged to the FBI/NSA and Key 3 and 4 belonged to the FISA court. Key 1 would decrypt to a blob of further encrypted material that would only be decrypted fully by Key 3 (think of Key 1 as the outer slice of an onion and Key 3 the inner slice to get to the center). Also Key 4 would decrypt a blob of decrypted material that could only be fully decrypted by key 2. That way you could guarantee that neither individual key could be subverted to fully decrypt without the other’s involvement. It would also allow either or both to see the resultant material should they need it but not without each other’s approval. It would also guarantee that the key material wouldn’t be abused beyond the time slice for the conversation in question.

So here is how it would break down. FBI/NSA ask FISA for approval to decrypt User A’s conversation with User B. FISA agrees, and FBI/NSA request Apple/Google give them the time slice of Tuesday and Wednesday. Apple/Google respond with corresponding numbers 1234 and 1235 with corresponding blobs of encrypted text (if the FBI/NSA don’t already have it).. FBI/NSA request that FISA decrypt the blobs with Key 4(Tuesday) and Key 4(Wednesday) corresponding with conversation 1234 and 1235. FISA returns two encrypted blobs that won’t be useful until the FBI/NSA use their Key 2(Tuesday) and Key 2(Wednesday) corresponding with the time slice Tuesday and Wednesday for conversation 1234 and 1235. The FBI/NSA decrypt the final encrypted blobs and are able to read the conversation. At this point Apple/Google know nothing about the data, only that it was subpoena’d. The FISA court was aware of and complicit in the decryption but never saw the data, and the FBI/NSA got only the data they requested and nothing more. If the Court also needs to see the data, corresponding keys 1 and 3 are used for the same time-slice against the corresponding blobs of data.

Of course this is a huge burden, because now each user has four keys that need to be created for each day. Assuming there are 3 billion people in the world, and they use probably 3 different types of chatting systems per day, that would require something like 36 billion keys to be shared by two government agencies (18 billion each) per day. That’s a lot. Not to mention that keys wouldn’t just be short passwords, but presumably something like x509 or GPG certs, which can be quite large. And that also assumes that they can somehow get access to those keys in a way that the other (or malicious 3rd parties) can’t intercept or see. The devil lies deep in those details.

Ultimately though, I think Alex Stamos is right to press the government. Our industry thrives on trust, and if people believe that the government is spying on them, they are significantly less likely to transact or act normally – as themselves. Even if we can solve for the technical problems we have to be extremely thoughtful on how or even if we deploy it at all. Even when one’s only crime is one of thought or ideas, this kind of system dramatically increases the likelihood that the idea of freedom of expression will be lost in the annals of time. We all have to decide: would we rather have security in the form of big brother, or would we rather have privacy? We can’t have both, so we had better make up our minds now before the decisions are made on our behalf.

Please check out a similar and wonderfully written post by Matthew Green as well.

The Perils of Privacy Personas

Privacy is a complex beast, and depending on who you talk to, you get very different opinions of what is required to be private online. Some people really don’t care, and others really do. It just depends on the reasons why they care and the lengths they are both willing and able to go through to protect that privacy. This is a brief run-down on some various persona types. I’m sure people can come up with others, but this is a sampling of the kinds of people I have run across.

Alice (The Willfully Ignorant Consumer)

  • How Alice talks about online privacy: “I don’t have anything to hide.”
  • Alice’s perspective: Alice doesn’t see the issues with online advertising, governmental spying and doesn’t care who reads her email, what people do with her information, etc. She may, in the back of her mind, know that there are things she has to hide but she refuses to acknowledge it. She is not upset by invasive marketing, and feels the world will treat her the same way she treats it. She’s unwilling to do anything to protect herself, or learn anything beyond what she already knows. She’s much more interested in other things and doesn’t think it’s worth the time to protect herself. She will give people her password, because she denies the possibility of danger. She is a danger to all around her who would entrust her with any secrets.
  • Advice for Alice: Alice should do nothing. All of the terrible things that could happen to her don’t seem to matter to her, even when she is advised of the risks. This type of user can actually be embodied by Microsoft’s research paper So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users, which is to say that spending time on security has a negative financial tradeoff for most of the population when taken in a vacuum where one person’s security does not impact another’s.

Bob (The Risk Taker)

  • How Bob talks about online privacy: “I know I shouldn’t do X but it’s so convenient.”
  • Bob’s perspective: Bob knows that bad things do happen, and is even somewhat concerned about them. However, he knows he doesn’t know enough to protect himself and is more concerned about usability and convenience. He feels that the more he does to protect himself, the more inconvenient life is. He can be summed up with the term “Carpe Diem.” Every one of his passwords is the same. He choses weak security questions. He uses password managers. He clicks through any warning he sees. He downloads all of the programs he finds regardless of origin. He interacts on every social media site with a laissez-faire attitude.
  • Advice for Bob: He should pick email/hosting providers and vendors that naturally take his privacy and security seriously. Beyond that, there’s not much else he would be willing to change.

Cathy (The Average Consumer)

  • How Cathy talks about online privacy: “This whole Internet thing is terrifying, but really, what can I do? Tax preparation software, my utilities and email are essential. I can’t just leave the Internet.”
  • Cathy’s perspective: Cathy knows that the Internet is a scary place. Perhaps she or one of her friends has already been hacked. She would pick more secure and private options, but simply has no idea where to start. Everyone says she should take her security and privacy seriously, but how and who should she trust to give her the best advice? Advertisers are untrustworthy, security companies seem to get hacked all the time – nothing seems secure. It’s almost paralyzing. She follows whatever best practices she can find, but doesn’t even know where to begin unless it shows up in whatever publications she reads and happens to trust.
  • Advice for Cathy: Cathy should try to find options that have gone through rigorous third party testing by asking for certificates of attestation, or attempt to self-host where possible (E.g. local copies of tax software versus Internet-based versions), and follow all best practices for two-factor authentication. She should use ad-blocking software, VPNs and logs out of anything sensitive when finished. Ideally she should use a second browser for banking versus Internet activities. She shouldn’t click on links out of emails, shouldn’t install any unknown applications and even shouldn’t download trustworthy applications from untrustworthy websites. If a site is unknown, has a bad or nonexistent BBB rating or seems to not look “right”, she should avoid it. It may have been hacked or taken over. She should also do reputation checking on the site using Web of Trust or similar tools. She should look for the lock in her browser to make sure she is using SSL/TLS. She shouldn’t use public wifi connections. She should install all updates for every software that is already on her computer, uninstall anything she doesn’t need and make sure all services are disabled that aren’t necessary. If anything looks suspicious, she should ask a more technical person for help, and make sure she has backups of everything in the case of compromise.

Dave (The Paranoid Reporter)

  • How Dave thinks about online privacy: “I know the government is capable of just about anything. So I’ll do what I can to protect my sources, insomuch as that it enables me to do my job.”
  • Dave’s perspective: Dave is vaguely aware of some of the programs the various government agencies have in place. He may or may not be aware that other governments are just as interested in his information as the US government. Therefore, he places trust in poor places, mistakenly thinking he is somehow protected by geography or rule of law. He will go out of his way to install encryption software, and possibly some browser security and privacy plugins/add-ons, like ad-blocking software like Disconnect or maybe even something more draconian like NoScript. He’s downloaded Tor once to check it out, and has a PGP/GPG key that no one has ever used posted on his website. He relies heavily on his IT department to secure his computer. But he uses all social media, chats with friends, has an unsecured phone and still uses third party webmail for most things.
  • Advice for Dave: For the most part, Dave is woefully unequipped to handle sensitive information online. His phone(s) are easily tapped, his email is easily subpoenaed and his social media is easily crawled/monitored. Also, his whereabouts are always monitored in several different ways through his phone and social media. He is at risk of putting people’s lives in danger due to how he operates. He needs to have complete isolation and compartmentalization of his two lives. Meaning, his work computer and personal email/social presence should not intertwine. All sensitive stuff should be done through anonymous networks, and using heavily encrypted data that ideally becomes useless after a certain period of time. He should be using burner phones and he should be avoiding any easily discernible patterns when meeting with sources in person or talking to sources over the Internet.

Eve (The Political Dissident)

  • How Eve thinks about online privacy: “What I’m doing is life or death. Everyone wants to know who I am. It’s not paranoia if you’re right.”
  • Eve’s perspective: Eve knows the full breadth of government surveillance from all angles. She’s incredibly tuned in to how the Internet is effectively always spying on her traffic. Her life and the lives of her friends and family around her are at risk because of what she is working on. She cannot rely on anyone she knows to help her because it will put them and ultimately, herself, in the process. She is well read on all topics of Internet security and privacy and she takes absolutely every last precaution to protect her identity.
  • Advice for Eve: Eve needs to got to incredible lengths to use false identities to build up personas so that nothing is ever in her name. There should always be a fall-back secondary persona (also known as a backstop) that will take the fall if her primary persona is ever de-anonymized instead of her actual identity. She should never connect to the Internet from her own house, but rather travel to random destinations and connect into wifi at distances that won’t make it visually obvious. Everything she does should be encrypted. Her operating system should be using plausible deniability (E.g. VeraCrypt) and she should actually have a plausibly deniable reason for it to be enabled. She should use a VPN or hacked machines before surfing through a stripped down version of Tails, running various plugins that ensure that her browser is incapable of doing her harm. That includes plugins like NoScript, Request Policy, HTTPS Everywhere, etc. She should never go to the same wifi connection twice, and should use different modes of transportation whenever possible. She should never use her own credit card, but instead trade in various forms of online crypto-currencies, pre-paid credit cards, physical cash and barter/trade. She should use anonymous remailers and avoid using the same email address more than once. She should regularly destroy all evidence of her actions before returning to any place where she might be recognized. She should avoid wearing recognizable outfits, and cover her face as much as possible without drawing attention. She should never carry a phone, but if she must, it should have the battery removed. Her voice should never be transmitted due to voice-prints and phone-line/background noise forensics. All of her IDs should be put into a Faraday wallet. She should never create any social media accounts under her own name, never upload a picture of herself or surroundings, and never talk to anyone she knows personally while surfing online. She should avoid using any jargon, slang or words that are unique to her location. She should never talk about where she is, where she’s from or where she’s going. She should never tell anyone in real life what she’s doing and she should always have a cover story for every action she takes.

I think one of the biggest problems in our industry is the fact that we tend to give generic one-size-fits-all privacy advice. As you can see above, this sampling of various types of people isn’t perfect but it never could be. People’s backgrounds are so diverse and varied, that it would be impossible to precisely fit any one person into any bucket. Therefore privacy advice must be tailored to people’s ability to understand their interest in protecting themselves and the actual threat they’re facing.

Also, we often are talking at odds with regards to privacy vs security. Even if we didn’t have to worry about the intentions of those giving advice, as discussed in that video, we still can’t rely on the advice itself necessarily. Nor can we rely on the advice being well taken by the person we are giving it to. One party might fully believe that they’re doing all they need to be doing, while they are in fact making it extremely dangerous for those around them who have higher security requirements.

Anything could be a factor in people’s needs/interest/abilities with regards to privacy – age, sex, race, religion, cultural differences, philosophies, their location, which government they agree with, who they’re related to, how much money they have, etc. Who knows how any of those things might impact their privacy concerns and needs? If we give people one-size-fits-all privacy advice it is guaranteed to be a bad fit for most people.

#HackerKast 29 Bonus Round: Formaction Scriptless Attack

Today on HackerKast, Matt and I discussed something called a Formaction Scriptless Attack. Content Security Policy (CSP) has put a big theoretical dent in cross site scripting. I say theoretical because relatively few sites are taking advantage of it yet; but even if it is implemented to prevent JavaScript from loading on the page, that doesn’t necessarily remove the possibility of attack from HTML injection.

For example, let’s say you have a site that has CSP set up to prevent inline and remote JavaScript from loading using the nonce feature, which requires all script tags to include the nonce before they will load. The nonce is probably based on some locally known secret XOR’d with the user’s credential or something similar. Whatever the case the CSP nonce is not known. But what they really want to do is submit some form. Now the form itself might protect itself in a different way, using a server-generated nonce (a second one) to prevent cross site request forgeries. Barring any side channel attacks, MitM attacks or attacks against the server itself, it seems like this might stop you in your tracks.

HTML5 to the rescue! Let’s say the form has an id set of id=”form1″. HTML5 has a feature where any input field anywhere on the page (yes, even outside of the form block) can say that it belongs to any form using the “form” parameter (e.g. form=”form1”). That might be somewhat bad, because perhaps I can include an extra form field and make the user do something they didn’t mean to do. But worse yet, HTML5 also has a feature called formaction. Formaction allows me to change the location where the form is being submitted.

So if the attacker submits an input field that associates itself with the form that contains the secret nonce and also with the formaction directive which points the form to the attacker’s website, it’s pretty much game over if the user clicks on that button. So now the trick is to get the attacker to click on the button. Oh, if only there was a way to get people to click on arbitrary places on a page from another domain… oh wait! Clickjacking!

So if the site is using CSP but not using X-Frame-Options or similar techniques to prevent the site from being framed, the attacker can frame the page and force the user to click on the evil button that has set a formaction which points the form back to the attacker’s site. The attacker then takes that nonce, creates a page that automatically uses the nonces and forces a CSRF request with the secret nonce. So much for CSRF protection! Here is the original vulnerable page and here is the clickjacked version of it with semi-opacity enabled to make it easier to see (tested in Firefox only).

Scriptless attacks aren’t new, Mario Heiderich for example has been working on them for years, but they are deadly. It’s not quite the same thing as a cross domain read in this case, but it has the same effect – allowing the attacker to read information from the target domain for use in an attack. I highly recommend using X-Frame-Options on all your pages. But that only stops one form of the attack. It’s still possible to social engineer people and so on. Why devs need to associate input fields with forms outside of the form block is still a bit of a mystery to me and why they need to change the form action after the fact — even overriding the original location — is also a puzzle. But with every new feature comes a new way to abuse it. HTML5 is an interesting beast, that’s for sure!

Update: As mentioned on Twitter, you can use CSP to block formaction, but you have to do that or the attack will still work with other CSP rules. Also you can do the equivalent of X-Frame-Options in CSP as well. So a properly configured CSP might actually save you – very cool!

Hillary Clinton’s Emails And The Internet Services Supply Chain

Do you want the blue pill? Then leave. Up for the red pill? Then keep reading.

There has been a lot of talk about Hillary Clinton’s emails lately, and for good reason. People are genuinely concerned about national secrets falling into the hands of those who might hurt people. Regardless of the merit of the claims of how her private email address was used, I wanted to spend some time talking about something that hasn’t been talked about enough – the Internet Services Supply Chain (a made up term, like all the others). 😉

What is the Internet Services Supply Chain? Whenever you build a website or email account that you host yourself, there are a number of things that you need to rely on. First, you need to rely on the physical hardware and its components – that’s called the Hardware Supply Chain and is a well understood (although not at all solved) issue. Then you have software components that your site utilizes – that’s called the Software Supply Chain and is also a well understood (although not at all solved) issue. Lastly, there are a number of service providers that are incredibly important for the continuity and security of your site, and that is the Internet Services Supply Chain. Those can include – but are not limited to – hosting providers, DNS providers, email providers and registrars.

For example, Hillary Clinton’s email MX records are actually on two separate IP addresses:

clintonemail.com.inbound10.mxlogic.net - 208.65.144.3
clintonemail.com.inbound10.mxlogicmx.net - 208.65.144.2

Unfortunately, it’s not that easy. Mxlogic relies on companies too. And those companies rely on other companies, and so on. Here’s just a simple mapping of all of the companies who could theoretically have taken over her domain as a result of that supply chain:

clintonemail.com
	Relies on ns16.worldnic.com for DNS
		Relies on netsol.com for NS
			Relies on mx.myregisteredsite.com for Mail
				Relies on droneteam@web.com for Domain Admin Control
	Relies on networksolutions.com for Registrar
		Relies on netsol.com for NS
			Relies on mx.myregisteredsite.com for Mail
				Relies droneteam@web.com for Domain Admin Control
	Relies on mxlogicmx.net for Email
		Relies on hostmaster@mcafee.com for Domain Admin Control
			Relies on akam.net for DNS
				Relies on hostmaster-billing@akamai.com for Domain Admin Control
		Relies on pdns3.ultradns.org for DNS
			Relies on Godaddy.for DNS
				Relies on domains@neustar.biz for Domain Admin Control
					Relies on pphosted.com for Mail
						Relies on proofpoint.com for DNS
						Relies on dns@proofpoint.com for Domain Admin Control
					Relies on NEUSTARREGISTRY.BIZ for Registrar
						Relies on Godaddy for Registrar
							Relies on outlook.com for Mail
								Relies on msft.net for DNS
									Relies on domains@microsoft.com for Domain Admin Control
								Relies on o365filtering.com for DNS
								Relies on hotmail.com for Mail
								Relies on domains@microsoft.com for Domain Admin Control
						Shares Host with dominios.com.co
						Shares Host with ddosattacks.com
						Shares Host with startknowing.biz
						Shares Host with neustarportingxpress.biz
						Shares Host with neustartcpa.biz
						Shares Host with dset.net
						Shares Host with m.dset.com
						Shares Host with neustar.tw
						Shares Host with neustarportingxpress.com
						Shares Host with mydotnyc.info
						Shares Host with neustarpartners.org
						Shares Host with npac4america.net
						Shares Host with neustarintelligentcloud.org
						Shares Host with ipenablers.biz
						Shares Host with ddosattacks.info
						Shares Host with extranet.sipix.neustar.biz
						Shares Host with neustarinfoservices.us
						Shares Host with socialscoop.us
						Shares Host with buy.us
						Shares Host with themobilecloud.us
						Shares Host with neustarportxpress.com
						Shares Host with dset.biz
						Shares Host with neustarreferrals.us
						Shares Host with neustarxpressport.biz
						Shares Host with getonlinewith.us
						Shares Host with intelligentcloud.us
						Shares Host with neustaripenablers.biz
						Shares Host with betterintelligence.com
						Shares Host with usblog.neustar.us
						Shares Host with themobilecloud.co
						Shares Host with identitymatters.biz
						Shares Host with campaignadministrator.biz
						Shares Host with neustarportxpress.biz
						Shares Host with npacforamerica.biz
						Shares Host with advantageoptout.com
						Shares Host with mobilecloudsolutions.us
						Shares Host with themobilecloud.biz
						Shares Host with npac4america.biz
						Shares Host with neustaripenablers.net
						Shares Host with campaignadministrator.org
						Shares Host with portxpress.biz
						Shares Host with themobilecloud.org
						Shares Host with www.neustarultraservices.biz
						Shares Host with kickstartamerica.net
						Shares Host with www.neustarregistry.biz
						Shares Host with kickstartamerica.info
						Shares Host with account.neustar.us
						Shares Host with portxpress.neustar.biz
						Shares Host with nic.us
						Shares Host with neulevel.biz
						Shares Host with neustarregistry.biz
						Shares Host with neustar-creative.biz
						Shares Host with neustarinfoservices.biz
						Shares Host with simpleportportal.biz
						Shares Host with kickstartamerica.us
						Shares Host with neustargovsolutions.biz
						Shares Host with neustargovsolutions.co
						Shares Host with ddosattacks.co.uk
						Shares Host with kickstartamerica.org
						Shares Host with neustarreferrals.net
						Shares Host with archerdev.neustar.biz
						Shares Host with getonlinewith.biz
						Shares Host with neustaraffiliates.biz
						Shares Host with nic.biz
						Shares Host with neustarpartners.eu
						Shares Host with neustarpartners.com
						Shares Host with neulevel.com
						Shares Host with neustarultraservices.com
						Shares Host with neustar-registry.com
						Shares Host with neustarsummit.biz
						Shares Host with billing.neustar.com
						Shares Host with archer.neustar.biz
						Shares Host with neustarmobilecloudsolutions.biz
						Shares Host with neustarplatformone.biz
						Shares Host with neustar.cn
						Shares Host with billing.neustar.biz
						Shares Host with neustaraffiliates.net
						Shares Host with neustarpartners.us
						Shares Host with neustarpartner.us
						Shares Host with uvvu.com
						Shares Host with neustaraffiliate.org
						Shares Host with gomocode.co
						Shares Host with gomocode.net
						Shares Host with getmy.us
						Shares Host with neustarpartner.org
						Shares Host with gomocode.com
						Shares Host with neustaraffiliates.us
						Shares Host with neustarintelligentcloud.com
						Shares Host with loadtesting.biz
						Shares Host with neustarpartners.cn
						Shares Host with neustarpartners.asia
						Shares Host with neustarmobilecloudsolutions.net
						Shares Host with neustar.biz
						Shares Host with neustaraffiliate.us
						Shares Host with neustarinfoservices.info
						Shares Host with neustarreferrals.biz
						Shares Host with neustarintelligentcloud.co
						Shares Host with mobilecloudsolutions.co
						Shares Host with dotyou.biz
						Shares Host with neustaradadvisor.us
						Shares Host with mobilecloudsolutions.net
						Shares Host with neustarmedia.biz
						Shares Host with neustar-registry.biz
						Shares Host with intelligentcloud.biz
						Shares Host with socialscoop.biz
						Shares Host with neustaradadvisor.info
						Shares Host with npac4america.us
						Shares Host with mobilecloudsolutions.biz
						Shares Host with neustarpartner.com
						Shares Host with neustarreferrals.org
						Shares Host with neulevel.cn
						Shares Host with library.us
						Shares Host with nightfire.com
						Shares Host with neulevel.net
						Shares Host with neustarultraservices.biz
						Shares Host with neustaradadvisor.biz
						Shares Host with neustarplatformone.com
						Shares Host with neustarmobilecloudsolutions.co
						Shares Host with npacforamerica.com
						Shares Host with redirect.neustar.biz
						Shares Host with mydotnyc.org
						Shares Host with neustarintelligentcloud.net
						Shares Host with registry.neulevel.biz
						Shares Host with ownit.nyc
						Shares Host with neustarpartner.net
						Shares Host with rfc2916.net
						Shares Host with agile.neustar.biz
						Shares Host with platformone.biz
						Shares Host with npac4america.com
						Shares Host with enum.org
						Shares Host with neustarplatformone.us
						Shares Host with neustaradadvisor.com
						Shares Host with neustarmobilecloudsolutions.us
						Shares Host with gomocodes.com
						Shares Host with my.biz
						Shares Host with neustaraffiliate.net
						Shares Host with parks.us
						Shares Host with dset.com
						Shares Host with gomocode.org
						Shares Host with neustarpartners.net
						Shares Host with neustarmobilecloudsolutions.org
						Shares Host with neustarlocaleze.info
						Shares Host with www.betterintelligence.com
						Shares Host with neustarmobilecloudsolutions.com
						Shares Host with neustaripenablers.com
						Shares Host with campaignadministrator.us
						Shares Host with campaignadministrator.com
						Shares Host with gomocodes.biz
						Shares Host with mydotnyc.biz
						Shares Host with neustaripenablers.org
						Shares Host with payment.neustar.biz
						Shares Host with campaignadministrator.net
						Shares Host with npac4america.co
						Shares Host with mobilecloudsolutions.org
						Shares Host with neustarsecretariat.biz
						Shares Host with mydotnyc.us
						Shares Host with neustarpartner.biz
						Shares Host with mydotnyc.net
						Shares Host with totalview.biz
						Shares Host with neustarreferrals.com
						Shares Host with platformone.neustar
						Shares Host with interactiveinsightssummit.com
						Shares Host with neustarinfoservices.com
						Shares Host with neustarlocaleze.us
						Shares Host with portingxpress.biz
						Shares Host with decellc.com
						Shares Host with support.neustar
						Shares Host with npacforamerica.us
						Shares Host with gomocode.biz
						Shares Host with mobilenextbigthing.biz
						Shares Host with npac4america.org
						Shares Host with vote.us
						Shares Host with neustarultraservices.net
						Shares Host with neustarintelligentcloud.us
						Shares Host with portingxpress.com
						Shares Host with dset.mobi
						Shares Host with loadtesting.us
						Shares Host with about.us
						Shares Host with neustaraffiliate.biz
						Shares Host with www.whobiz.biz
						Shares Host with stateofddos.biz
						Shares Host with ddosattacks.us
						Shares Host with xpressport.biz
						Shares Host with lookup.neustar.biz
						Shares Host with neustarpartners.biz
						Shares Host with portdr.org
						Shares Host with neustaraffiliates.com
						Shares Host with portdr.biz
						Shares Host with dotbiz.biz
						Shares Host with blog.neustar.biz
						Shares Host with identitymatters.co
						Shares Host with identitymatters.com
						Shares Host with kickstartamerica.biz
						Shares Host with kickstartamerica.co
						Shares Host with redir.neustar.biz
						Shares Host with identitymatters.us
						Shares Host with portdr.com
						Shares Host with neustaraffiliates.org
						Shares Host with portdr.us
						Shares Host with neustar.com.cn
						Shares Host with portdr.net
						Shares Host with neustarsimpleportportal.biz
						Shares Host with cloudnames.biz
						Shares Host with neusentry.biz
						Shares Host with etns.org
						Shares Host with dset.us
						Shares Host with neustar.com
						Shares Host with neustarlife.biz
						Shares Host with neustarintelligentcloud.biz
						Shares Host with payment.neustar.com
						Shares Host with neustarxpressport.com
						Shares Host with ddosattacks.biz
						Shares Host with mydotnyc.com
						Shares Host with neustargovsolutions.us
						Shares Host with neustargovsolutions.net
						Shares Host with neustartechnology.biz
						Shares Host with startwithus.biz
						Shares Host with www.neustarultraservices.com
						Shares Host with startwithus.net
						Shares Host with startwithus.us
						Shares Host with startwithus.org
						Shares Host with neustar.us
						Shares Host with dset.org
			Relies on PDNS196.ULTRADNS.BIZ for DNS
			Relies on PDNS196.ULTRADNS.CO.UK for DNS
			Relies on DNS196.ULTRADNS.COM for DNS
			Relies on PDNS196.ULTRADNS.INFO for DNS
			Relies on PDNS196.ULTRADNS.NET for DNS
			Relies on PDNS196.ULTRADNS.ORG for DNS
		Relies on pdns2.ultradns.net for DNS
		Relies on pdns5.ultradns.info for DNS
		Relies on pdns6.ultradns.co.uk for DNS
		Relies on dnsadmin@mxlogic.com for Domain Admin Control
		Relies on register.com for Registrar
			Relies on NS-1119.AWSDNS-11.ORG for DNS
				Relies on hostmaster@amazon.com for Domain Admin Control
					Relies on dynect.net for DNS
						Relies on dynamicnetworkservices.net for DNS
							Relies on dynamicnetworkservices.net@secretregistration.com for Domain Admin Control
						Relies on mailhop.org for Mail
							Relies on tucowsdomains.com for Registrar
								Relies on tucowsdomains.com@contactprivacy.com for Domain Admin Control
								Relies on TUCOWS.COM on DNS
						Relies on hostmaster@dyn.com for Domain Admin Control
					Relies on markmonitor.com for Registrar
						Relies on psmtp.com for MX					
							Relies on google.com for MX
							Relies on google.com for DNS
	                                        Shares Host with allwhois.co.uk
	                                        Shares Host with allwhois.com
	                                        Shares Host with bannermonitor.com
	                                        Shares Host with brandseyeview.com
	                                        Shares Host with collectivetrust.com
	                                        Shares Host with collectivetrust.net
	                                        Shares Host with collectivetrust.org
	                                        Shares Host with collectivetrustsolutions.com
	                                        Shares Host with dtecnet.com
	                                        Shares Host with dtecnet.dk
	                                        Shares Host with dtecnet.net
	                                        Shares Host with dtecnetusa.com
	                                        Shares Host with emarkmonitor.biz
	                                        Shares Host with emarkmonitor.cn
	                                        Shares Host with emarkmonitor.com
	                                        Shares Host with emarkmonitor.info
	                                        Shares Host with emarkmonitor.net
	                                        Shares Host with emarkmonitor.org
	                                        Shares Host with emarkmonitor.us
	                                        Shares Host with idaworks.com
	                                        Shares Host with insiderforum07.com
	                                        Shares Host with mark-monitor.at
	                                        Shares Host with mark-monitor.biz
	                                        Shares Host with mark-monitor.fr
	                                        Shares Host with mark-monitor.info
	                                        Shares Host with mark-monitor.it
	                                        Shares Host with mark-monitor.net
	                                        Shares Host with mark-monitor.org
	                                        Shares Host with mark-monitor.ru
	                                        Shares Host with markmonitor.am
	                                        Shares Host with markmonitor.at
	                                        Shares Host with markmonitor.be
	                                        Shares Host with markmonitor.biz
	                                        Shares Host with markmonitor.ca
	                                        Shares Host with markmonitor.ch
	                                        Shares Host with markmonitor.ci
	                                        Shares Host with markmonitor.cn
	                                        Shares Host with markmonitor.co.kr
	                                        Shares Host with markmonitor.co.nz
	                                        Shares Host with markmonitor.co.uk
	                                        Shares Host with markmonitor.com
	                                        Shares Host with markmonitor.com.au
	                                        Shares Host with markmonitor.com.br
	                                        Shares Host with markmonitor.com.kh
	                                        Shares Host with markmonitor.com.py
	                                        Shares Host with markmonitor.com.ru
	                                        Shares Host with markmonitor.cz
	                                        Shares Host with markmonitor.de
	                                        Shares Host with markmonitor.dk
	                                        Shares Host with markmonitor.es
	                                        Shares Host with markmonitor.eu
	                                        Shares Host with markmonitor.fi
	                                        Shares Host with markmonitor.fr
	                                        Shares Host with markmonitor.gr
	                                        Shares Host with markmonitor.gy
	                                        Shares Host with markmonitor.hu
	                                        Shares Host with markmonitor.in
	                                        Shares Host with markmonitor.info
	                                        Shares Host with markmonitor.it
	                                        Shares Host with markmonitor.jp
	                                        Shares Host with markmonitor.la
	                                        Shares Host with markmonitor.lt
	                                        Shares Host with markmonitor.lu
	                                        Shares Host with markmonitor.lv
	                                        Shares Host with markmonitor.name
	                                        Shares Host with markmonitor.net
	                                        Shares Host with markmonitor.nl
	                                        Shares Host with markmonitor.nu
	                                        Shares Host with markmonitor.org
	                                        Shares Host with markmonitor.pl
	                                        Shares Host with markmonitor.pt
	                                        Shares Host with markmonitor.ro
	                                        Shares Host with markmonitor.se
	                                        Shares Host with markmonitor.sk
	                                        Shares Host with markmonitor.su
	                                        Shares Host with markmonitor.tc
	                                        Shares Host with markmonitor.tv
	                                        Shares Host with markmonitor.us
	                                        Shares Host with markmonitor.vg
	                                        Shares Host with markmonitorglobal.com
	                                        Shares Host with mm-test-08c.info
	                                        Shares Host with mmdomain53.biz
	                                        Shares Host with mmdomain53.net
	                                        Shares Host with mmdomain53.org
	                                        Shares Host with wwwmarkmonitor.ch
	                                        Shares Host with wwwmarkmonitor.it
	                                        Shares Host with wwwmarkmonitor.ru
			Relies on NS-1887.AWSDNS-43.CO.UK for DNS
			Relies on NS-226.AWSDNS-28.COM for DNS
			Relies on NS-948.AWSDNS-54.NET for DNS

And this doesn’t even cover the Supply Chain for her hosting providers for mail.clintonemail.com or sslvpn.clintonemail.com. Now step back for a minute and ask yourself not “how easy would it be to break into all of these,” but “how easy would be for someone to break into any one of these domains?” I know both Rackspace and Google are on the list, and they were both targeted in the Aurora attacks that were allegedly attributed to the Chinese military (as an example). So it’s not a matter of whether it is possible to break into a domain, it’s just a matter of how hard someone is willing to try. Can you have a secure website without secure email? (Spoiler no you cannot).

We are putting all our eggs in a very small basket that hundreds of thousands of people could potentially have access to. The real issue isn’t Hillary Clinton and her blackberry. The real problem is that everyone everywhere who is on the public Internet is subject to this Internet Service Supply Chain. It’s inescapable because the Internet isn’t a bunch of islands; it’s far more interconnected, with consolidated power resting with a handful of service providers. We are all just as vulnerable as Hillary is, if we use the same Internet that she does.

Hillary is no different from anyone else. I could have done this same analysis on any company anywhere, and gotten roughly the same results. Let’s say the target was actually secure (Hillary’s email in this case); it doesn’t matter. If there is any vulnerability in any one of the companies the target relies on, the target is vulnerable. That is what happened with Lenovo, whose Registrar (Webnic) was hacked. And that’s just one example from less than a month ago.

That’s the problem with the Internet Services Supply Chain – any weak link in the chain can cause a cascade/ripple effect. It also means the stakes are getting even higher for those service providers and those who use them as power is consolidated to a few mega-companies that have the reach and access to control so many other companies. At some point no company and no individual will be able to ensure their own or their partners’ security.

And now you’re probably asking yourself, “Why, oh why did I pick the red pill?”

#HackerKast 25: Email Tripwire – How to Tell if My Email Has Been Hacked Into

How can you tell if someone is reading your email? Recently there has been concern about not just hacker but also employees of companies, administrators and so on who can access your account. Even in a non-nefarious situation it’s still important to know that someone has been looking through your inbox.

Jer took me on a trip down memory lane and asked me to look into an old blog post he had written a while back about how you can detect if your webmail account has been hacked into. The theory is simple, send yourself an HTML encoded MIME email, attach a reference to an image, and when the image is called you know someone has read that email.

By looking through your logs and identifying if the image ever loads, you’ll be able to tell that someone has looked through your email. It’s not bullet-proof and doesn’t work on all types of mail clients, for a number of reasons, but it’s a solid idea.

So I went back and wrote a little Perl script called “emailtripwire” that sends just such an email. I tested it on Yahoo mail and it worked perfectly. Google had delivery issues that I never got around to diagnosing. Outlook works great if you allow the image to load once – Outlook remembers that and will continue to do so, however that setting may be dependent on your local setup and may not carry over to other Outlook installs. But it does appear to work, and that’s the important part.

Using your own server to host the image is naturally the best solution if you already have a server, but a lot of people don’t have access to their own server. Instead, people interested in this technique can use an image-based tracking server like Fraudlog that can show you when someone has visited the image after reading the email.

So it is still possible to use this method to detect if your email has been compromised or detect when someone like an administrator has been in your account, even without the ability to host your own image. Sometimes it’s the simple tricks that work the best!

Resources:
Facebook explains when employees can access your account without your password
How to check if your WebMail account has been hacked
emailtripwire
Fraudlog

dnstest – Monitor Your DNS for Hijacking

In light of the latest round of attacks against and/or hijacking of DNS, it occurred to me that most people really don’t know what to do about it. More importantly, many companies don’t even notice they’ve been attacked until a customer complains. Especially for smaller companies who may not have as many customers, or only accept comments through a website, they may never know unless they randomly check, or the attacker releases the site and the flood of complaints comes rolling in after the fact.

So I wrote a little tool called “dnstest.pl” (yes a Perl script) that can be run out of cron and can monitor one or more hostname-to-IP-address pairs of sites that are critical to you. If anything happens it’ll send you an alert via email. There are other tools that do this or similar things, but it’s another tool in your arsenal; and most importantly dnstest is meant to be very lightweight and simple to use. You can download dnstest here.

Of course this is only the first step. Reacting quickly to the alert simply reduces the outage and the chance of customer complaints or similar damage. If you like it but want it to do something else, go ahead and fork it. Enjoy!