Security Now 282

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

Security Now 282: Q&A #108

Security Updates

3:37 - 10:09

  • Microsoft's acknowledgement of the bad new IE problem...
    • Vulnerability exists within CSS @import rule processing and affects all releases of Internet Explorer on XP, Vista & Win7.
    • Since on module of IE, "mscorie.dll" was not compiled with /DYNAMICBASE, it occupies a fixed location in memory.
    • ASLR is therefore not supported and DEP is bypassed by using "ROP" - Return Oriented Programming "gadgets" to allocate memory then copy and execute exploit shellcode.
    • Exploit code is in the wild
    • Microsoft does not plan to issue an out-of-band fix for the issue.

10:10 - 10:27

Security News

10:28 - 18:28

  • Hacking GSM phones with $15 and 180 seconds
    • On Tuesday, 12/28 @ Chaos Computer Club (CCC) Congress, Berlin
    • Two guys from Security Research Labs. ( & showed why the GSM association was wrong in saying the threat from hackers to the GSM network was minimal
    • There is a huge amount of known plain text in the protocol, so when it is XOR'D with the bit stream from the shift registers it is known what a lot of the cipher text corresponds to
    • GSM Association claimed that the threat was minimal due to the high cost and complexity of carrying out an attack
    • These guys carried out the attack with 4 modified $15 phones plus two terabytes of rainbow tables
    • Second generation rainbow tables are available via Bittorrent

24:06 - 30:19

  • WikiLeaks - several sources reporting:
    • "Net-Centric Diplomacy" System
    • CIA - Was asked to put their data into SIPRNet and refused, stating that too many (2.5 million) users had access.
    • NSA - Proactively taking the stance that their entire network and systems have been compromised
  • Washington Post: by Joby Warrick
    • "SIPDIS" flags the document to be routed to the Net-Centric database.
    • Embassy staff were just putting SIPDIS on everything since no clear policy existed.
    • So the Net- Centric database ended up with huge amounts of improper information.
    • "Partly because of its design but also because of confusion among its users, the database became an inadvertent repository for a vast array of State Department cables, including records of the U.S. government's most sensitive discussions with foreign leaders and diplomats. Unfortunately for the department, the system lacked features to detect the unauthorized downloading by Pentagon employees and others of massive amounts of data, according to State Department officials and information-security experts."

30:20 - 39:10

  • Stuxnet Update:
    • Report from ISIS - Institute for Science and International Study
    • As many as 10% -- 1,000 of 10,000 -- centrifuges taken off line.
    • IR-1 centrifuges want to run at 1,064 Hz but Iran was running theirs at 1,007 Hz to reduce stress.
    • Stuxnet instructs the centrifuges to run at 1,410 Hz which would physically damage the centrifuge's rotor either immediately or within about 15 minutes.
    • 27 days between "attacks" of changing the frequency
    • Stuxnet disguises its activity by sending commands to shut off warning and safety controls that would normally alert plant operators.

39:11 - 41:25


41:26 - 42:22

  • The "How the Internet Works" series is coming soon !


42:23 - 43:44 Rick Shepherd (Nevada)

Spinrite fixed many broken hard drives

Questions & Answers

45:59 - 01:44:56

Question [ 01 ] - Ranga Reddy in Asbury Park, NJ wonders about SSDs and full drive encryption:

45:59 - 51:49
Question: You recently stated that SSD don't need defragging, because the excessive writes would ruin the drive. How about full drive encryption (TrueCrypt, BitLocker, File Vault, etc)?

Does full drive encryption affect SSDs similarly?

Answer: Steve's advice is to defrag an SSD once after you have set it up. Do not do it all the time though as you can wear a drive out. With whole drive encryption it would run over the entire drive once to encrypt it but it makes no difference during use. Do not use a swap file on a SSD.

Comment [ 02 ] - Kevin Ottum in Des Moines, Iowa offers some comments on Peter F. Hamilton Books:

51:50 - 55:33
Listener Comment:I was listening to the recent SN episode where you were talking about some of the science fiction you've been reading. I really appreciate your suggestions, and I have read several. I started with Fallen Dragon and then the Pandora's Star/Judas Unchained books, and enjoyed them very much.

Just a few weeks ago, I completed listening to the audio versions of the Void trilogy, and they were FANTASTIC. I really think you should give them another look. I, too, was a bit put off by the mysticism and religious cult aspects in the synopsis, but in actually reading the books, I was pleasantly surprised. In the effort to remain spoiler-free, I will simply recite one of Arthur C. Clarke's laws: “Any sufficiently advanced technology is indistinguishable from magic.” Being a fan of “hard science”, I don't think you will be disappointed.

Also, this takes place in the same universe as the Pandora's Star series, and since technology allows humans to live practically forever, many characters from that series return for the Void trilogy.

Steve's Comment: Steve has already read this. And is currently reading the 4th book in the health and wars series

Audible References
Pandora's Star by Peter F. Hamilton (Unabridged)
Narrated by John Lee
#2 in the series "The Commonwealth Saga" [1]
Judas Unchained by Peter F. Hamilton (Unabridged)
Narrated by John Lee
#3 in the series "The Commonwealth Saga" [2]
The Dreaming Void by Peter F. Hamilton (Unabridged)
Narrated by John Lee
#1 in the "The Void Trilogy" [3]
The Temporal Void by Peter F. Hamilton (Unabridged)
Narrated by John Lee
#2 in the "The Void Trilogy" [4]
The Evolutionary Void by Peter F. Hamilton (Unabridged)
Narrated by John Lee
#3 in the "The Void Trilogy" [5]

Comment [ 03 ] - Dusan Maletic in Babylon NY suggests that “Do Not Call” is fundamentally different than “Do Not Track”.

55:34 - 01:04:33
Listener Comment:In Episode 278 of Security Now, you talked briefly about "Do not track" idea for the Internet browsing and its similarities with the "Do not call" list and systems for telephones.

One fundamental difference has not been mentioned: The "Do not call" list applies to the system where every single individual is precisely defined and numbered. Identifiable by their unique phone number. Hence, "Do not call" can be implemented without any conundrums.

But the “Do Not Track” idea on the Internet unfortunately has built-in conundrum. To be tracked one needs to be identified in some manner. But NOT to be tracked also involves identification first - then a demand not to be tracked under that identity (you can't not track who you do not know not to track).

So, unfortunately, the very act of identifying yourself not to be tracked accomplishes what tracker wants the most: establishing your unique identity. Couple that with the inability to easily determine what the other party is doing with your information. (With “Do not call” you and the government can positively track who called whom and when.) But what the back-end server does with info harvested by scripts from your browser is unknown to you and the government. The offender can claim whatever they will. So, the whole system is fundamentally flawed.

The best “Do not track” option is an educated user.

Steve's Comment: In the past all you had to do was turn off third party cookies but now there are many more ways to be tracked using things like flash cookies, HTML 5 storage and scripting. Opt out cookies are bad if they are unique as you can be identified but if everyone who opts out gets the same cookie it isn't as bad. Browser manufactures could add a do not track header but it is not clear how websites would handle such a request without legislation.

Comment [ 04 ] - Pete Burtis in New Hampshire suggests: One more thing for your list of "must haves" before you'll implant a chip...

01:04:34 - 01:08:58
Listener Comment:Quick and simple: I want any implanted chip I have to able to authenticate the remote device that's trying to authenticate ME before it does anything else!

Let me load the public keys of devices I trust onto my implanted chip, or better yet, let me load my company's root certificate onto my chip, and then I'll automatically trust every RFID door lock at my company.

If done correctly, this makes tracking you from a distance by your chip impossible -- because it will ignore queries from any devices IT doesn't trust -- and also addresses things like replay attacks.

Sure, device memory might be an issue, but if it's implanted anyway, why not just make it a little bigger? I think a 16 gig microSD card would implant nicely between my thumb and forefinger.

Steve's Comment: That is a great idea but the problem is that public key crypto needs a lot of processing power

Comment [ 05 ] - Scott in Winters, CA had a comment about DDoS and spoofing the source IP

01:08:59 - 01:16:17
Listener Comment: In last week's listener feedback you mentioned the DDoS methods and software being used by the WikiLeaks related attacks, and how the IP addresses of the attackers are not hidden with the method they are using.

One of the more popular tools for DDoS is a network utility called hping ( It lets you send a flood of packets (a DoS) and spoof the originating ip address if desired.

You can literally say you are, or, or whatever you want with a single command line option:

-a --spoof hostname: Use this option in order to set a fake IP source address, this option ensures that target will not gain your real address. However, replies will be sent to spoofed address, so you can't see them. In order to see how it's possible to perform spoofed/idle scanning see the HPING3-HOWTO.

Steve's Comment: This uses raw sockets and so is not possible on windows

Question [ 06 ] - Jim Stevens in Massachusetts suggests TWO stacks to prevent unintended code execution

01:18:45 - 01:25:00
Listener Question: Thanks for the incredible podcast. I've been a big fan since the beginning. In a not-so-distant episode, Steve described his frustration regarding the losing battle we all face attempting to keep our machines secure. I personally am sick of spending half my life making sure friends and families computers receive the latest updates for all software, educating them about Sandboxie and Noscript, and trying to explain why anti- malware software in general is a *reactive* approach to problems, not a proactive one. Life is too short for this. The analogy I use for malware is cancer: Once you have it, it's almost impossible to get rid of. It's much better not to get it in the first place.

My question: You recently spoke about completely re-architecting our machines to *prevent* security problems in the first place. It seems that a major cause of our problems are caused by buffer overruns in stack space. In your stack episode, you described how the stack is used both for the return address for functions and for local variables. If too much data is written to a local variable, it can overwrite the return address of the function, and if carefully designed, could cause undesired code to be executed.

Why don't we use two stacks? One stack contains only return addresses for functions, and would allow recursion and all the other functionality we use today. The second stack would contain data for local variables. Overflowing a buffer, while bad, would just cause data corruption, and not unintended code execution. Of course we'd have to synchronize the two stacks, so that the correct local variables are popped when a function returns, but this problem seems minor compared to the frustration we have to deal with now. What do you think?

Steve's Comment: This is a useful idea and similar to the 'Harvard' architecture. There are small chips these days that do, do this.

Question [ 07 ] - Daniel in Provo, UT, USA comments about known plaintext attacks and encrypting ransomware...

01:25:01 - 01:30:14
Question: You mentioned in episode 278 that hard disk-encrypting ransomware is making a comeback, this time with public key encryption. It seems that for something like an entire hard drive, known plaintext attacks may be helpful in determining the decryption key even if cipher block chaining is used. The potential quantity of known plaintext on a whole hard drive makes it very likely that enough information can be determined to make a strong attack and get back the original data, especially given good reverse engineering of the code that did the encryption in the first place.

Obviously the best remedy is to avoid getting snared by these guys and to use whatever governmental remedies may exist to get their operation shut down and provide the necessary disincentive against similar operations in the future, but the technological approach may still be helpful for someone.

Answer: If the criminals are implementing the cryptography properly using something like cipher block chaining then due to the inter block dependencies a known plain text attack wont work

Question [ 08 ] - Charles in Houston, Texas wonders: FHSS - Secure or not secure?

01:30:15 - 01:35:16
Question: I just purchased a Lorex Live Snap wireless video baby monitor because I found it on sale at a local store and it looks really convenient. I haven't opened it yet because I'm not very sure about the security of the wireless video feeds from the cameras and I get no response from the company when I ask for more information.

For example, the fellow I spoke with on the phone sounded like he was reading over the information for the first time himself and was, ostensibly, in a call center -- not a company employee. They also have NOT responded to my email.

The only information I find about the product from their website is that it uses FHSS technology and they advertise that "The long-range digital wireless signal has a range of up to 450ft. (with clear line of sight) and is secure and interference-free. It won't interfere with your cordless phone, microwave, or router, and no nosey neighbors will be able to eavesdrop on you and your family."

Their lack of response or specific details violates my TNO policy! I NEED MORE INFORMATION!

My look into FHSS doesn't give me much of a warm fuzzy. But on the other hand, it isn't just a simple broadcast on one frequency that anyone can tune in to. The convenience factor for this system is why I haven't just returned it and moved on.

What are your thoughts? Is FHSS secure enough to keep weirdos from looking at the inside of my house?

Here's to hoping you can help me before it is too late to return the system!

Answer: As long as the bad guy doesn't have the same receiver or key you will be fine. Frequency hoping is not really for security but to avoid interference. Steve is not 100% sure but expects that someone else with a receiver could view your monitor unless they are paired in some way

Question [ 09 ] - Aaron in Oregon says: "About 154 nonillion years"

01:35:17 - 01:40:51
Question: “About 154 nonillion years” is how long the website says a desktop PC would take to crack a GRC generated password.

How does one calculate something like this?

Answer: This site does a nice job but not a fantastic one. It looks at the type of characters you enter to calculate the size of the alphabet being used. It then raises the alphabet size to the length of your password to get the number of possible combinations. It assumes your desktop PC can guess 10 million passwords a second (Steve notes this is VERY fast).

Question [ 10 ] - Jared in Australia doesn't understand why software flaws are so hard to find?

01:40:51 - 01:44:56
Question: Regarding the possible trouble with BSD's security from as far back as ten years ago: I don't understand how it's even reasonable for something that might be wrong to exist within BSD's code for that long.

Why wouldn't people know?

Why aren't these sorts of problems just seen and fixed if they exist?

What am I not getting about this?

Answer: Hackers throw random data at the program to try and get it to do something unexpected and then work back from this when it breaks. Humans often miss things when looking at the source code especially when its not well written.



Production Information

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