Security Now 328

From The Official TWiT Wiki
Jump to: navigation, search
Security Now
Episode 328

Security Now 328: Listener Feedback #131

News & Errata

SOPA, SCADA hacked, Kindle Fire extended review, your questions, and more

Spinrite Story

David Wright via twitter "SpinRite saves the day again. 2004 laptop back up and running again, ready for another couple years of faithful service."
@blindbites via twitter "Thanks for SpinRite. Saved my PC once again. No exciting story. PC wouldn't boot, and lockup during system recovery. Ran SR, one hour, all okay."
David Ward "Hi, Steve. I've been hearing the testimonials and mentions of SpinRite for a few years now on Security Now!. I thought it sounded nice for those without any options, but I can do a bit of data recovery if I need it. Plus I have backups of all important data. So it's not a problem for me. Plus I thought, how can a reformat/re-zero not solve any problem anyway? Well, I recently had a disk in our MythTV media machine that started acting up. It was a disk in the recording pool of drives, so some of our recordings" - he said, i.e., girlfriends - "were on it. Mounting the disk separately was showing it was empty. Not the end of the world. Well, maybe for me, but not for anyone else. So I did a manufacturer's check on the drive, and it came up fine. I did some other little things, and the disk continued to check out fine. Still no data upon mounting it. Skeptical, I talked a friend out of loaning me his copy of SpinRite, with the promise to him and myself that, if it did anything, I would buy it. But I was also pretty sure it probably wouldn't. Running at Level 4, I saw it seemingly stuck at 41 percent on a spare test Pentium 4. So I changed out the motherboard/CPU, et cetera and resumed from there. A day later, we're done, and we have all our data accessible. So there, Steve. Have my $89. I just purchased it. Well worth it."

Questions & Answers

Question: [ 01 ] Terri Bell


Flash applications are compiled, and compilation produces binaries that take effort to reverse engineer. A Flash application may also be obfuscated to afford "protection" against Flash decompilers. In contrast, the source code for HTML5 applications is there for anyone to grab. It can then be modified and similar competing applications or services set up with a fraction of the original development cost. Although obfuscation and moving application logic to server side will help HTML5 developers protect their work, some developers will not see that protection as adequate and choose Flash instead. Thus HTML5 will replace Flash in many instances, but not all.


I don't think anybody today even, given the anti-Flash position that Apple's mobile products have, if they didn't have to, would use Flash. I think you'd just say okay, HTML5 and JavaScript. We can do what we need to that way. So.

And remember we have our standard - our standard refrain is, if it's going to run on a user platform, then you cannot protect it.

Question: [ 02 ] Rosen Penev


Steve, I've been a listener since the Bitcoin episode, and your Password Haystacks page is fascinating. Your explanation of it was awesome. But a question recently popped up. You mentioned how the bad guys try to use dictionary attacks and then progressively trying out more sophisticated patterns like numbers and symbol combinations. My question is, how likely is it for a bad guy to use a different alphabet to try to crack a password? My guess is highly unlikely since most people don't use alphabets other than the Latin alphabet. But I'd appreciate it if you could comment on this since this could potentially mean that you can have passwords that are short and secure - I guess by using Cyrillic or something. Great podcast, as always.


Well, so, okay. The problem is one of compatibility. We run across it with sites that won't allow special characters, for example, even sort of a little bit off the map, but not even very far off the map characters, or even Unicode in some cases. What you'd really like is a site that will take whatever it is you give it and hash it and store the hash. In which case it's only incumbent upon you to be able to recreate the same thing again. Now, even that can be a problem because not all keyboards are equally capable. It's possible, for example, with a traditional PC keyboard to hold down the Alt key and enter the decimal code into the number pad and have that work. The problem would be, what if you wanted to log in on your iPad to the same site? You wouldn't be able to recreate that same process. So unfortunately we're reduced at this point to a world of least common denominators in order to get cross-site and cross-application and cross-platform compatibility. So while it's tempting to imagine putting some funky characters in from some different language, you need to make sure that you're able to do that wherever you want to be, and of course that the site honors them correctly. For example, if I did that, say that I used a "c" with an umlaut over it or something, or maybe an "o," you'd want to make sure that just typing in a regular "o" didn't also log you in, in which case you wouldn't have achieved anything. It would be reducing the strength of your password without your knowing it. So, yes, the idea is absolutely a good one, that is, of using strange characters and different alphabets. The problem is one of getting sufficient compatibility, which I think would probably be a showstopper.

Question: [ 03 ] Patrick Moran


Is nothing safe anymore? 3DES, the triple use of the Data Encryption Standard -- has now been cracked. Electronics Weekly Article


I looked at the article. There was a reason I chose it, because it had the best analogy I've ever heard of a side channel attack. And I didn't want to forget to mention it to our listeners because it was just so great. A little background: DES was the Data Encryption Standard - thus the acronym DES - which if memory serves was a 56-bit key. And that's not enough bits anymore. And DES itself had some structural problems. So what was recommended was to do it three times. And that might sound like, well, how can you take something that's not secure and just do it more and you get security? But that's exactly what our block ciphers do. Remember that AES runs multiple iterations - they call them "rounds," multiple rounds - using different pieces of key material. No one round is at all secure. And in fact reduced round versions of AES have been cracked because you rely on the successive rounds in order to get the strength. And when you get enough of them, you just can't penetrate it.

So, similarly, taking a block cipher like DES and doing it three times - not using the same key three times but essentially three different keys. So you take 56-bit key times three would be your new key length. And then you use a different 56 bits out of that key for each of the three times. And you end up with something which is still very quick because DES had the benefit of being a pretty quick block cipher, yet you get really strong security. Oh, and in this case it's being used in some electronics-based cards in Europe. And it was one of these cards which was cracked using a side channel attack. And we talked about that recently. In fact, they noted that power consumption being used by the card when it was in use leaked enough information for them to obtain the key.

So, and we've talked about how - yes, isn't that cool? - that just, if you're sharp enough, and of course we're talking about sharp people, just noting variations in the amount of power the card is consuming while it's processing the crypto, if you understand the way the algorithm interacts with its power consumption, that can be enough in order to give it away.

Question: [ 04 ] Joe Campana


Hi Steve,

I don't know about you, but in talking with my non-techie friends, I have found that they are very frustrated (like myself) when updating Adobe's Flash Player.

Primarily, is there any logical reason why we are faced with their user agreement EVERY time we update this? Adobe can't actually be changing the terms for each and every update, can they?

I got into a white heat yesterday when faced with this again for the "hundredth" time. It seems to me that there could be an agreement that would be affirmed when it is installed initially and could [be] re-affirmed occasionally -- maybe annually.

But more importantly, when faced with the Update Flash window, a majority of my friends just click Cancel and move on -- not knowing that an update is a good thing in terms of safety. I beleive that if there is any software that should update quietly in the background, this is it! Of course there should also be the ability to roll-back to an earlier version when an update breaks something, but for the general public I overwhelmingly suggest that Adobe consider this approach.

Sadly, Adobe appears to be following in Microsoft's footprints in that they don't seem to use the software they are writing... Have they ever tried to walk their mother through an update over the phone??

Thanks for everything you do!

Answer: So that caught my eye. This was the question that I mentioned I was going to get to relative to our listeners, who I'm sure are updating Flash, probably in something of a sweat or a panic when they realize that Adobe has just fixed 12 things which are all being actively exploited to install Duqu or the malware du jour on their system. But the idea and, well, the idea that Joe mentioned, that he believes he's got friends who are not doing so just because they're annoyed that they're having to do it all the time...

And at the same time there are all these anecdotal reports of everyone apparently on the planet getting infested with malware all the time. Well, this may very well be one of the ways it's happening. So I just sort of wanted to take a moment, for the holidays, to remind our users to make sure that their less security-savvy friends, everyone they know who isn't listening to this podcast, does take software updating seriously and follows through when Flash is saying it needs to be updated. Don't read the license agreement. No one does.

Question: [ 05 ] Philip Smith


"Apple iOS security is flawed"

It's not as safe as you imply, with the approval process being part of the app publsihing requirement. I know you understand that, but I think it's time to remind our community. Just because it's a closed system does not imply innate security:

Threat Post Article

Love the show! Cheers.


Well, and it's more than that, Leo. And this is why I wanted to entertain this question from Philip. It is impossible. And I don't mean in the sense of Apple couldn't be doing a better job, I mean in the sense of we want an impossible thing. We want our computers to do what we mean, not what we say. It is absolutely the case.

Look at, for example, the clipboard. The clipboard is a massively convenient feature because it was originally maybe designed within an application, you would mark a clause or a paragraph, for example, and then cut or copy it, and then put your cursor somewhere else in the same app, and then paste it. So it made it very convenient to move things around within an app. But then it was realized, wait a minute, let's make that a global resource, that is, the clipboard, so that we can do inter-app cut, copy, and paste. Whoa, and that's really handy. I mean, who isn't copying URLs out of one place and dropping it somewhere else, putting it in notes, putting it in a browser and so forth. And now that we've got super-complex passwords, we're likely using the clipboard in the same way.

The problem is that it's a global resource, and malware has access to the clipboard just as our apps do. So there's a perfect example of something which is a feature which, because it's a global feature of the system, it becomes useful, that is, it's much more useful to us if we can use it for inter-app movement of data. But if we leave sensitive data on the clipboard, and this happens all the time, and it has been widely exploited by malware, then the malware is able to access the clipboard and get whatever we may have happened to leave there. Now, whose fault is that?

Question: [ 06 ] Jason Pritchard


Hi Steve and Leo, You have talked in the past about organizations, such as AV companies, research facielities and such 'monitor[ing]' internet traffic seemingly for statistical analysis or perhaps to see how a virus moves throughout the internet. Knowing the routers send packets to the specified destination and switches only send packets to the port containing the device to which the packet is addressed, how would one monitor anything except the traffice destined for the 'monitoring' device? I know that some broadcast traffic would be detected, but even that should be limited to the network segment on which the device resides. How do research organizations gather information about network traffic? Are they doing it from an internet backbone? If so, why would the owners of those connections let anyone anywhere near them?

Thanks for all the great information throughout years.


I thought that was a great question. And we've never, in all of our years together, addressed it directly. Okay. So there's two ways. First of all, an organization like Symantec is massive. I mean, they're doing - they've got their security research guys. But there's all this other stuff they're doing, and operations, and payables, and receivables, and email, and everybody's on the 'Net, and they're surfing and Googling and browsing. So a large organization only has to monitor itself in order to have a huge beautiful cross-section of spam coming in, and threatening email links, and what people are - where people are going and what's happening on the Internet. So just an organization looking - the security side of an organization looking at its own, considering its own navel, if you will, pondering its own navel, gives it enough. I mean, a huge cross-section of information.

Then the other thing that these organizations do - and it's actually something that I have done in the past. I don't monitor it all the time. But, for example, I myself have a block of 64 IP addresses that are completely unused, unallocated. They exist out there in the 4 billion IPv4 space, yet they have never been associated with anything. And that's just a big honeypot. There is traffic on those 64 IPs for no good reason whatsoever. It's not bound for me. It's not bound for anybody.

It's just stuff out there. It's weird how much traffic there is on this space that never belonged to anybody. It's just things out there. It's like Code Red and Nimda still existing in a closet somewhere out there. Every so often a Code Red or a Nimda packet comes in.

Question: [ 07 ] Terry Zinger


Hi, I'm unsure whether you can help, but here goes:

I recently noted in my Norton AV 11.x for the Mac, some interesting entry(ies):

ARP Cache Poisoning - Incoming. It listed a MAC address that I did not recognize

Further investigation indicated the MAC address was for my "Smart" phone.

I have some tech background with the US Navy (30 years) and another 20 years in tech with the educators. I retired as the Tech Director for a small school districh in Ohio. I had never heard of ARP poisoning until Norton started to report it.

Question: Can we stop this attack?

After lengthy research, I did the following: Changed the wireless router at home to reflect the latest security. I realize this is probably closing the barn door after the cows are halfway to Japan but......

Can I change the MAC address on the phone? and then block the old MAC address.

Is there a clean solution? I assume this attack did not necessarily take place here at home. I use wireless access on the phone whenever possible to help save battery.

Hope you can find a little time to help and old veteran and well used techie.



We have. And my best guess is this is a false positive, which is very possible for the following reason. First of all, a little quick review over on ARP is it's the protocol which is - that is, ARP formatted protocol packets on Ethernet. It's the protocol which is used to bind an Ethernet MAC address, which is the way the packets actually are addressed on the physical Ethernet wire or Ethernet air, to an IP address, which is an entirely unrelated addressing scheme, the way packets are addressed out on the Internet, because the Ethernet and the Internet are completely separate things.

So, for example, Internet IP addresses, as we know, are 32 bits; whereas Ethernet addresses are 48 bits, 24 being the vendor ID and 24 being a unique number within that vendor ID. So there needs to be some way to give an endpoint on the Ethernet that always will have a unique, globally unique MAC address to give it an IP address. And ARP is the way that's done. You can have static IP assignments where the device knows its IP. And so when somebody else on the Internet - I'm sorry, on the Ethernet, I mean the local Ethernet, says, "Hey, who has this IP address?" the device that does will say, "I do." And it responds with its MAC address so that the requester is able to then send IP-oriented traffic to the proper hardware. So that's the IP-to-MAC mapping.

However, most people do not use static IP addressing. They use dynamic IP addressing, using the protocol we've also talked about, DHCP, Dynamic Host Configuration Protocol. In that case, a device which is being asked to connect to the network, like your smartphone would when you bring it into the house - and as Terry said, he tends to use his WiFi wherever possible. So he's got it set up so that his smartphone will get on his local network. With DHCP you are asking the DHCP server, which is almost always someone's router, which also has a DHCP server function built in, it is saying, "Hi there. I'm being asked to use DHCP. I need an IP address." And so the DHCP server looks at its table of available IPs and assigns one which is currently available. And technically they have a lease time, that is, the lease expires, and then it needs to be refreshed.

So now we have the case of Norton AV 11.x running on the Mac. It apparently has a feature where it's going to warn users of ARP cache poisoning. To do that, it would have to be monitoring all the traffic on the network all the time, and essentially see and monitor, build its own table of IP-to-MAC address associations or mappings. And what probably happened, what almost certainly happened, is for some reason that table got out of sync. And it's not hard to imagine that it might have. Maybe the machine was turned off and then back on. Or it was briefly unplugged when some ARP traffic changed the network's awareness of these mappings, but this one Mac machine didn't see that. Anything could happen that could cause this to be desynchronized because there is no good way, there's no perfect way to prevent that desynchronization. Essentially, this is not a feature I am a big fan of, for exactly this reason. You don't want to upset people with false positives of something like this when it's so possible that they would occur.

So one way or another, the Mac ARP table, the Norton AV's ARP table, was no longer synchronized with the DHCP table that is residing in the router. So the smartphone walked in the front door in somebody's pocket, asked for an IP address, and the DHCP server gave it one, which Norton AV had as allocated to somebody else. And that is exactly what ARP poisoning would look like, was if there was a conflict between known and agreed-upon IP addresses and MAC addresses. But with DHCP, you're giving out new IPs all the time. So in a statically assigned environment, where everything has a fixed IP, you wouldn't ever expect there to be a false positive.

But when IPs are floating around, especially with a smartphone coming and going, something else might have received an IP. Maybe the smartphone came back in and tried to use the IP because its lease had not expired, tried to reuse the IP that something else had been given in the meantime. I mean, there's all kinds of scenarios where you could see a collision that would generate a false positive. And I'll bet that's what's happened. So Terry, take a big deep breath and relax a lot. I mean, sure, ARP poisoning does exist. Maybe your phone got some malware installed. But given the way the world is, I'd bet that wasn't the case.

Question: [ 08 ] Keegan Ead


Apple's OS Sandboxing

Should not it be the operating systems responsibility to protect itself from viruses or malware? This sort of behavior seems to be what Apple is suggesting is appropriate. That the average user should not need to acquire third party security packages to keep their computers at baseline. So why are the developers involved at all?

Thanks Steve, you put on a great show. I'm not a security or IT guy, but you manage to keep the program easily accessible for anyone. Thanks again.


So I thought maybe I should simplify this whole thing for anyone else who is a little confused by this because it is, in detail level, it is/can be confusing. But it's simple. Operating systems are responsible for protecting themselves and applications.

Well, exactly as I was saying in the example of the clipboard, the clipboard represents not a defect, but a feature, which can be abused. So a perfect example would be if the application did not need the clipboard. If it didn't use the clipboard ever, then it could enhance the security for everyone by declaring that right off the bat. When it starts up, it says "I do not use the clipboard." Then the OS could remove clipboard access rights from that process. And the beauty would be, then, that if that process ever did misbehave, if it got infected, or it was acting wrongly and tried to use the clipboard or any other feature similar which it had previously declared it had no use for, the operating system would block it, and that's a good thing.

So it makes absolute sense for - I love what Apple's doing, that they have this notion, the notion of entitlements. So the idea would be that clipboard access would be an entitlement defined by Microsoft. The programmer could say, I either need it, I need that entitlement, or I don't. In which case the program would not be entitled to access the clipboard. And if all programs that didn't use things they didn't need declared themselves to be nonusers, security would be a lot better. So I think it's a great thing.

Question: [ 09 ] Bruce Harrison


Hi Steve and Leo

Whilst listening to your description of TCP/IP and how it works, I couldn't help but wonder how Skype and other streaming technologies, work? Does TCP/IP meticulously ensure that packets are re-sent and assembled into order whilst Skype disdainfully discards them?

Deeply appreciate your weekly efforts.


This is a great question. It's something that we've sort of talked about tangentially, but not, again, never addressed directly. And that is, we've looked now at some detail in three separate podcasts, building upon the prior ones about How the Internet Works, we've looked at TCP. And we recognize that it sequentially numbers its bytes, it buffers them as they're being sent, as packets of bytes are being sent on behalf of the applications, until acknowledgment is received from the other end that everything that it has sent has been received, in which case it's free to let go of them. But if packets are lost along the way, acknowledgments aren't received, it will retransmit lost packets. It does all this work for us in order to give us a so-called perfect, a reliable as opposed to a not reliable connection.

But Skype is just wanting to send audio. And what happens with packets being dropped or reordered or anything? What does Skype do? Well, the beauty of Skype is it doesn't use TCP because that would be a big problem, exactly as Bruce has surmised. Skype uses UDP. You and I, Leo, are talking over UDP protocol rather than TCP for exactly this reason. Skype excels at forgiving us, forgiving the Internet for dropping packets. Yet it doesn't worry about a packet dropped a minute ago. We've already moved past that. It sort of fills in, literally, truly fills in the audio as best it can, interpolating the audio of missed packets. So Skype keeps them small so that packets don't carry too much audio because it recognizes they may get lost. But, if so, it doesn't care. So Skype and all other streaming services like this, real-time streaming services, do not use TCP because they don't want TCP in the way, mucking things up, which is what it would do if it stalled the connection and waited for, like, lost packets to get resent before it could move forward again. Instead, UDP being a non-connection-oriented, non-reliable protocol, they just go off, and if they get there, good. And if not, oh, well, that moment passed, and we pretty much understand what we're saying to each other anyway.

Question: [ 10 ] Robert Hickman


From the sound of it, OneID is going to be yet another closed down proprietary silo'd system. And if that's the case, I'm not touching it! Like the Internet as a whole, any kind of widespread authentication system must be open and not tied to any single provider to be trustworthy.


Well, and he's talking about which we talked about last week that came out of the privacy conference. And I have to say, much as I hope something succeeds, I kind of have the same feeling. I mean, I like the concept of it. But I like, maybe, I hope, fingers crossed, what we're about to talk about next week even more. Which leads us into Tom Jones.

Question: [ 11 ] Tom Jones - Next week's indepth topic


Hi Steve!

Please take a look at Mozilla's initiative that is IMHO [a] much superior concept to, at least in the following 5 ways: - it's not centralized -- a requirement for wide success on the web - doesn't depend at all on mozilla (or any other single vendor) - privacy: vendor is not informed of visits to 3rd party - not vaporware: it can actually be used today - it's free! (forever!)

And bonus interest points (for SN) -- it basically uses crypto to solve a hard problem in a demonstrably clever way.

For a very quick introduction, watch this 12 minute video (or at least the first 6 minutes) here: Video and posting

If you are interested in more information check out these links:
Introducing BrowserID: A better way to sign in
Privacy and BrowserID
Introducing BrowserID – easier and safer authentication on the web
BrowserID Design for Privacy
Primary Identity Authorities in BrowserID



If any of our listeners are curious, this is a cool little MP4 video file, 12 minutes long, that sort of - it's a little slide show, gives people sort of a simple, rough overview. It does not in any way preempt the podcast that we'll do next week's in-depth look at how this works. It does a great job, though, of selling its benefits. And this has been on my radar for some time. I've been intending to get to it. We're going to get to it next week. We'll all have digested our Thanksgiving dinners, those of us who celebrate Thanksgiving, and be ready to tackle some nice technology.

I'm excited about this for all the reasons that Tom mentions. And I have to agree with him, too, that any solution to this problem that attempts to be proprietary, to be owned by one organization, as any of these things do, suffers from exactly that. I think that that's a liability for something that sort of really does need to be open. And the Mozilla guys have really done a nice job. So next week we're going to do a propellerhead episode, looking in detail at a very cool, I mean really cool, completely out of your hair sort of solution for this. I can't wait to talk about it.

Notable Quotes

If it's going to run on a user platform, then you cannot protect it.

ARP Happens.

Production Information

  • Edited by:
  • Notes:
Info.png This area is for use by TWiT staff only. Please do not add or edit any content within this section.