jducoeur: (Default)

Just came across an article on Ars Technica (yes, I'm behind): The intelligent intersection could banish traffic lights forever. It's neat stuff: basically, a researcher has designed a traffic-control system for autonomous vehicles, and demonstrated that by using such technology we could enormously reduce how often you have to stop at intersections -- not only speeding up travel times, but improving fuel efficiency quite a bit.

All of which is great, but my Security Architect senses are pinging here. This is postulating an external server that talks to the cars on the road and tells them what to do. That is absolutely terrifying if you understand the typical state of Internet-of-Things security.

But let's put a positive spin on this. This system is at least 1-2 decades from deployment as described (since it assumes only autonomous vehicles on the road). We might be able to head off disaster by figuring out the obvious hacks in advance, so they can be designed around.

So here's the challenge: name ways that a hacker could abuse this system, and/or ways to ameliorate those weaknesses.

I'll start with a few obvious ones:

  • Base story: I (the hacker) send out signals spoofing the controller for traffic intersection T, allowing me to cause nightmarish havoc. Possible solution: traffic controllers are listed in some well-known registry, signed with public keys, so that their signals can be authenticated to prevent spoofing.
  • Assuming the above hacking isn't prevented: I time the signals sent to the cars, telling them all to hit the intersection at the same moment. Crash! Solution: as a belt-and-suspenders thing, cars must not completely trust the signal controllers. Their autonomous checks have to override those signals, to prevent crashes.
  • Reverse of the previous: I send out signals telling all the cars, in all directions, that the intersection is currently blocked by opposing traffic. The entire city quickly devolves into gridlock. Solution: good question. I got nothing.

What else? I'm sure we can come up with more nightmarish scenarios, and possible solutions.

Yes, this may seem like overkill to think about now, but history says that, if you don't design the system around abuses, you will hurt forevermore. Security isn't something you add later: it should be baked into the designs from the get-go. (Which is why it accounts for a large fraction of Querki's architecture, despite the fact that we only have a couple hundred users yet...)

jducoeur: (querki)
(This one is for the programmers out there, and especially for security geeks.)

As I was doing some updates yesterday, it occurred to me that Querki now allows you to name your Things pretty much anything you want. Including "javascript:...do something malicious...". Since we generate relative URLs to pages (and therefore, the URL is basically this name), this is Bad.

I've fixed the obvious hack by the simple expedient of screening out any URLs that begin "javascript:", but I'm guessing that that isn't enough -- that there are other ways to be malicious with a URL.

So I'm looking for suggestions. Take it for granted that Querki allows you to specify URLs, and that those URLs can be *fairly* arbitrary relative URLs, so I can't just whitelist a simple legal syntax -- I probably need to think in terms of blacklisting the badness. Do you know a good comprehensive list of the possible syntaxes that could be used for Javascript injection when placed inside an href? (Better yet, do you know an existing regex pattern to detect them?)
jducoeur: (Default)
I just got an email that is clearly from some random spammer, asking for permission to share my spreadsheet "Wedding Stuff". This is the spreadsheet Kate drew up, that outlines the Wedding App that I have to have ready in Querki by April. (Yes, our wedding invitations have a spec. This simply demonstrates that we are well-suited to each other.)

That's not the disturbing part -- I expect random spammers to request random stuff all the time. What's disturbing is that it was even *possible* for him to request this. I mean, this is a private document in Google Docs, shared with nobody except Kate. Nobody else should even be able to see its existence, much less request access to it. So in principle, this email shouldn't have even been possible.

For now, I'm going to be optimistic, and guess that the spammer is simply plugging random numbers into an API -- not targeting any particular documents, just scatter-shotting requests in the hopes that some people will be dumb enough to grant access to something with personally identifying information. (Which, sadly, will probably work.) That wouldn't be *too* big a security hole. (Certainly not as bad as the possibility that Google is actually leaking the structure of my document tree.) But even that is somewhat sadly careless: as this particular phishing scam demonstrates, this approach does make it too easy for the bad guys to do something nasty.

The moral of the story is a basic security principle (which I should remember myself for Querki): simply knowing an object ID shouldn't allow you to do *anything* unless that object is fully public...
jducoeur: (Default)
Well, that’s ruefully amusing. When I went to sign into Facebook a bit ago, IE gave me a warning that the security certificate was from an untrusted signing authority. When I actually dig into the details, the cert has been signed by “cybervillains.com” – which doesn’t have much information, but which *claims* to be an imprint of iSEC Partners (www.isecpartners.com), a security firm.

So I *think* what’s happened here is that Facebook hired iSEC to test their security perimeter, and they found that it’s actually pretty weak – iSEC was able to break into the site and substitute their own cert in place of Facebook’s authentic one. Which makes me happy that Facebook is conducting this sort of security test, but less happy that they appear to publicly failed it…

[ETA: Having already gotten one friend request from posting this, I should note that I don't actually *use* Facebook except for work -- we're doing some sample apps in Facebook. So you're welcome to friend me, but don't expect anything interesting there...]

[ETA 2: I got a note from the fellow who actually wrote the tool in question, which *is* a security tool, but it's intended for interception and monitoring of SSL traffic. His take on it is that Zing is probably being attacked, fortunately by someone too stupid to hack the credentials on the program to something plausible-sounding -- the "Cybervillains" moniker was specifically to alert anyone who gets it that it's fake. So the moral of the story is, pay attention to certs that are presented to you, and if it sounds suspicious, refuse it...]
jducoeur: (Default)
Well, that’s ruefully amusing. When I went to sign into Facebook a bit ago, IE gave me a warning that the security certificate was from an untrusted signing authority. When I actually dig into the details, the cert has been signed by “cybervillains.com” – which doesn’t have much information, but which *claims* to be an imprint of iSEC Partners (www.isecpartners.com), a security firm.

So I *think* what’s happened here is that Facebook hired iSEC to test their security perimeter, and they found that it’s actually pretty weak – iSEC was able to break into the site and substitute their own cert in place of Facebook’s authentic one. Which makes me happy that Facebook is conducting this sort of security test, but less happy that they appear to publicly failed it…

[ETA: Having already gotten one friend request from posting this, I should note that I don't actually *use* Facebook except for work -- we're doing some sample apps in Facebook. So you're welcome to friend me, but don't expect anything interesting there...]

[ETA 2: I got a note from the fellow who actually wrote the tool in question, which *is* a security tool, but it's intended for interception and monitoring of SSL traffic. His take on it is that Zing is probably being attacked, fortunately by someone too stupid to hack the credentials on the program to something plausible-sounding -- the "Cybervillains" moniker was specifically to alert anyone who gets it that it's fake. So the moral of the story is, pay attention to certs that are presented to you, and if it sounds suspicious, refuse it...]
jducoeur: (Default)
The latest buzz is that Microsoft, having entered the consumer-security market, is planning on diving deeply into the enterprise-security one as well, selling their own security software in competition to Symantec and the like. Quoting the article from ZDNet:
"This is a rather safe play," said Charles Kolodgy, an analyst at IDC. "It is easier than building the security into products and not being able to directly capture revenue."
Uh-huh. So let's rephrase this -- Microsoft has decided that it's too expensive and difficult to ship secure products. Okay, yes -- we all knew that they felt that way. But tacitly admitting it, and then charging people extra to get the fixes to those broken products is rather breathtakingly cynical, even by Microsoft standards...
jducoeur: (Default)
The latest buzz is that Microsoft, having entered the consumer-security market, is planning on diving deeply into the enterprise-security one as well, selling their own security software in competition to Symantec and the like. Quoting the article from ZDNet:
"This is a rather safe play," said Charles Kolodgy, an analyst at IDC. "It is easier than building the security into products and not being able to directly capture revenue."
Uh-huh. So let's rephrase this -- Microsoft has decided that it's too expensive and difficult to ship secure products. Okay, yes -- we all knew that they felt that way. But tacitly admitting it, and then charging people extra to get the fixes to those broken products is rather breathtakingly cynical, even by Microsoft standards...

Profile

jducoeur: (Default)
jducoeur

June 2017

S M T W T F S
     123
456 7 8 910
11121314151617
18 192021222324
2526 27282930 

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags