Security Now 324

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

Security Now 324: Q&A 129

Security News

Brian Krebs posted a list of organizations apparently also targeted and/or infected by the same network that infiltrated RSA: https://krebsonsecurity.com/2011/10/who-else-was-hit-by-the-rsa-attackers/  More than 760 other organizations have or had networks that were "phoning home" to the same command and control servers. 20% of the Fortune 100 companies appear on the list Among the more interesting names on the list are Abbott Labs, the Alabama Supercomputer Network, Charles Schwabb & Co., Cisco Systems, eBay, the European Space Agency, Facebook, Freddie Mac, Google, the General Services Administration, the Inter-American Development Bank, IBM, Intel Corp., the Internal Revenue Service (IRS), the Massachusetts Institute of Technology, Motorola Inc., Northrop Grumman, Novell, Perot Systems, PriceWaterhouseCoopers LLP, Research in Motion (RIM) Ltd., Seagate Technology, Thomson Financial, Unisys Corp., USAA, Verisign, VMWare, Wachovia Corp., and Wells Fargo & Co. Overwhelming majority of the C&C servers are in or around China. 

  • Two Internets? 

FBI talking about a separate non-anonymous Internet and taking sensitive data back offline Microsoft talking about a "red" and a "green" Internet. "Red" would be exactly what we have now, and "Green" would be *much* more restrictive, difficult to break into and easier to track-down miscreants.

  • Stuxnet variant "DuQu" found and analyzed by Symantec and McAfee. Names its files beginning with "DQ" Portions are identical to Stuxnet Targeting industrial control firms Removes itself after 36 days.

Errata

  • STP - Spanning Tree Protocol Invented by DEC Allows deliberate link redundancy -- and tolerates mistaken "loops" Least-Cost Routes (fewest links traversed)

Questions & Answers

Question [ 01 ] -: James Russell in Australia wonders... "How do programs know when the correct password was entered?"

How do utilities such as TrueCrypt, Disk Utility, 7Zip, etc, know when the user has entered the correct password? The decryption algorithm will run regardless of whether the password was correct, won't it? I assume it will just produce pseudorandom noise for incorrect passwords? Do these programs append some kind of identifying token to the data before encrypting it, and check for the identifier after decrypting? Or would that weaken security somehow? Thanks Steve, love the show!

Question [ 02 ] -: Francois Lagrange in Brussels, Belgium offers some reasons to force periodic password change

Steve, I'm security architect in a large bank, and work daily with people managing security devices. While mandating to change user passwords is a needless annoyance indeed, there definitely are reasons to do so *in some cases*. Passwords for security equipment must be changed regularly - say every 6 months - in the enterprise. Think about engineers sharing passwords, writing them in notepad files, on Post-Its. I've seen passwords of equipment written on a paper next to their keyboards (booh!), shared to colleagues by telling them almost loudly. Or even, think about the many engineers that occasionally have to look up passwords while the project manager is standing just behind them... I know, I know, there are ways around all this. Still, changing passwords from time to time just ensures that the list of those knowing them is just reset from time to time to those that really need-to-know. Thank you for everything.

Question [ 03 ] -: Zach in Madison, WI shares his discovery of a slick Kindle utility

Steve, Not related to the show, but I know you own several Kindle's so I thought I'd pass along this tool I just found that has greatly improved my PDF reading experience. Normally I shy away from reading PDF's on the Kindle since the text is so small and zooming in or rotating the screen is just annoying to me. K2pdfopt is a small exe from willus.com that you simply drag a pdf onto and it will optimize for kindle reading. Though you can tweak many of the settings, I find that the defaults work great. Please take a look and share with your listeners if you'd like. http://www.willus.com/k2pdfopt/ (Windows, Mac & Linux) 

Question [ 04 ] -: An anonymous listener wanted to weigh-in on Lithium Ion battery care

Steve, you mentioned that lithium-ion batteries want to stay charged to get the maximum lifetime. According to batteryuniversity.com (cited by the lithium-ion Wikipedia page), this is not completely accurate. According to Battery University... How To Prolong Lithium-Based Batteries, if you continuously keep lithium-ion batteries fully charged (at 100%), permanent capacity loss is greater than if you keep the lithium-ion battery at half charge. Take a look at "Table 3: Permanent capacity loss of lithium-ion as a function of temperature and charge level." If you keep the battery 100% charged all the time at 25 degrees Celsius, it will lose 20% of the capacity in 1 year! If you let the battery discharge and leave it at about 40% most of the time, it would only lose 4% capacity. It is correct that you shouldn't run lithium-ion batteries down to 0%, but you also shouldn't repeatedly keep charging it which would keep the battery near 100% and cause greater capacity loss.

Question [ 05 ] -: Tom Minnick in Baltimore, also MD wonders about Lithium-Ion VS Lithium-Poly and effects of deep cycling.

Hello Steve, Really love the podcast. In your Q&A you had mentioned that it is bad to deep cycle "Lithium-Ion" batteries. Are "Lithium-Ion" and "Lithium-Poly" the same? The reason I ask is, I have been playing around with R/C aircraft for a time and they all now use "Lithium Polymer" batteries which by the nature of how we run these planes are being deep cycled. There are safety mechanisms in the Speed Controllers to prevent the batteries from being drawn down past a certain threshold, but these devices do not meet your "Keep plugged in and topped off model" I haven't had a chance to look in to this, but thought you would be interested. Regards, -Tom 

Question [ 06 ] -: Geoff Forsyth in Ipswich UK admonishes us "not to blame the IT department for forcing password changes - its not our fault!"

Steve, Please don't blame the poor IT department for forcing password changes - we have an obligation to do it as part of Credit Card compliance rules. Every business that takes credit card payments must comply with the security rules enforced by Visa, MasterCard and Amex. These rules are designed to reduce card fraud, but they do drive all IT departments absolutely nuts. Visa, MasterCard and Amex formed the Payment Card Industry (PCI) security council a few years back (https://www.pcisecuritystandards.org/) and will fine an organization up to $500,000 if it does not meet their rules (called the Data Security Standard) and suffer a breach. The whole world seems to be struggling to implement their IT rules, and although in general they are set with the best intent, they do insist password changes are implemented for all staff every 90 days. PCI DSS states: Question Change user passwords at least every 90 days.

  • Require a minimum password length of at least seven characters.
  • Use passwords containing both numeric and alphabetic characters.
  • Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used.
  • Limit repeated access attempts by locking out the user ID after not more than six attempts.
  • Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.
  • If a session has been idle for more than 15 minutes, require the user to re- authenticate to re-activate the terminal or session. See -: its not my fault!! Love the show, keep up the good work Geoff

Question [ 07 ] -: Keith in St. Louis MO brings up a very good point about password changing.

Hey Steve, Listen to you and Leo all the time, love it. Feedback regarding the password changing policy topic that keeps being brought up. I'm sure this has been thought of, but you keep saying you can't find a good reason as to why users need to change their password every X months. Lets say I attack a user, and get the users password, I've got the clear text password. I want to keep my access, I'm not going to do anything to let the user know that I've compromised his or her account. If the user is forced to change his or her password every so X months I'm screwed. Of course if i had the rights i could create another account, or put in a backdoor, but if those are found i could go back to the users account (unless they are forced to change it). Isn't this a good reason to why we need to force users to change passwords every X months...?

====Question [ 08 ] -: Chris Strzelczyk in Michigan reminds us about "Insecure fingerprints" Hi Steve, I'm a listener in the programming and server administration profession for many years. My brother is somewhat of a clean freak and tends to wipe his iPad screen often. After leaving his iPad at my house one day, I observed that the fingerprints left on the screen could be mapped to his unlock code. Since those were pretty much the only fingerprints on the screen, it was trivial to figure out the actual numbers. Now I just had to write them down and decode. Since my brother is not a SecurityNow listener, I suspected his passcode would be something he could easily remember and probably some number that binds to some personal information. I was right. A couple birthday combinations later, I was inside his iPad. I wanted to bring this to users attention. When you have a code on your iPad you should, well maybe not wipe it as often or have a code that does not bind to any personal information. Thanks for a great show!

Question [ 09 ] -: Fabio Esquivel in Cartago, Costa Rica asks: "Should I be scared of TLS 1.0?"

After listening to your podcast about the SSL v3.0/TLS v1.0 & TLS v1.1 vulnerabilities, I ran to disable Windows support of these protocols from Control Panel / Internet Options / Advanced / Security items... I only left TLS v1.2 checked and so felt safe. Days later my iTunes 10.5 started to fail... I could no longer log in into my iTunes Store using my Apple ID, so I could not download updates for my iPhone! I did not think disabling TLS 1.0 & 1.1 would affect iTunes, so I ran some diagnostics (iTunes: Help / Run diagnostics) and there I could see some "connectivity issues"; the detailed diagnostics showed that iTunes could no longer establish a secure connection to the App Store. So, I guessed what was wrong: Went again to Internet Options, enabled TLS v1.1 and restarted iTunes: Still no luck. I then also enabled TLS v1.0, restarted iTunes and the login was successful! As app downloading worked just fine on the iPhone, I guess its iOS 5 is also using TLS v1.0 internally... Should I be worried about TLS v1.0 vulnerabilities? Should someone cry at Apple's doors to oblige them to update their TLS support to, at least, v1.2? You've got a great show and I really enjoy it every week!

Question [ 10 ] -: Miamiandy in Troy, New York wanted to comment upon iPhone keyboard vibrations:

Steve, I have been an on and off listener for awhile now and enjoy your podcasts. I was attending CCS this past week and heard the Georgia Tech people present their paper about the iPhone detecting typing via the vibrations it produced research paper. During the Q&A that followed, it was pointed out, when they were probed for more detail, was that this was under some very specific circumstances. First, the iPhone was always on the left side of the keyboard in the same spot. Second, they made sure to use a wood desk as it resonated the best. When they tried with another desk or on a concrete floor it did not work. Third, they tried it in an isolated environment. This was pointed out to be an issue since vibrations from other items such as desk fans, or maybe even some speakers would ruin the results. Although this was an interesting paper, I think the flaws in its proof should be pointed out so people aren't suddenly paranoid about leaving their phones on their desk. Please don’t ever stop the podcasts!

Sponsors

Go To Assist Express

Ford

Netflix

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.