<![CDATA[[SecurityRatty] tag: secret]]> http://securityratty.com/tag/secret Wed, 20 Aug 2008 09:00:00 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[The Analyzer Is Among The Suspects In $1.8 Million Theft From A Canadian Company]]> http://securityratty.com/article/1a3f2a8d883dec31c59c3fe3a24e0d4d http://securityratty.com/article/1a3f2a8d883dec31c59c3fe3a24e0d4d Fri, 05 Sep 2008 13:42:04 +0000 calgary company calgary municipal police secret service million ehud tenenbaum suspects allegedly analyzer montreal The Analyzer Is Among The Suspects In $1.8 Million Theft From A Canadian Company <![CDATA[Contest: Cory Doctorow's Cipher Wheel Rings]]> http://securityratty.com/article/5bf9715088e83f021dd3a8a86d47bb52 http://securityratty.com/article/5bf9715088e83f021dd3a8a86d47bb52 Cory Doctorow wanted a secret decoder wedding ring, and he asked me to help design it. I wanted something more than the standard secret decoder ring, so this is what I asked for: "I want each wheel to be the alphabet, with each letter having either a dot above, a dot below, or no dot at all. The first wheel should have alternating above, none, below. The second wheel should be the repeating sequence of above, above, none, none, below, below. The third wheel should be the repeating sequence of above, above, above, none, none, none, below, below, below." (I know it sounds confusing, but here's a chart.)

So that's what he asked for, and that's what he got. And now it's time to create some cryptographic applications for the rings. Cory and I are holding an open contest for the cleverest application.

I don't think we can invent any encryption algorithms that will survive computer analysis -- there's just not enough entropy in the system -- but we can come up with some clever pencil-and-paper ciphers that will serve them well if they're ever stuck back in time. And there are certainly other cryptographic uses for the rings.

Here's a way to use the rings as a password mnemonic: First, choose a two-letter key. Align the three wheels according to the key. For example, if the key is "EB" for eBay, align the three wheels AEB. Take the common password "PASSWORD" and encrypt it. For each letter, find it on the top wheel. Count one letter to the left if there is a dot over the letter, and one letter to the right if there is a dot under it. Take that new letter and look at the letter below it (in the middle wheel). Count two letters to the left if there is a dot over it, and two letters to the right if there is a dot under it. Take that new letter (in the middle wheel), and look at the letter below it (in the lower wheel). Count three letters to the left if there is a dot over it, and three letters to the right if there is a dot under it. That's your encrypted letter. Do that with every letter to get your password.

"PASSWORD" and the key "EB" becomes "NXPPVVOF."

It's not very good; can anyone see why? (Ignore for now whether or not publishing this on a blog makes it no longer secure.)

How can I do that better? What else can we do with the rings? Can we incorporate other elements -- a deck of playing cards as in Solitaire, different-sized coins to make the system more secure?

Post your contest entries as comments to Cory's blog post -- you can post them here, but they're not going to count as contest submissions -- or send them to cryptocontest@craphound.com. Deadline is October 1st.

Good luck, and have fun with this.

]]> Fri, 05 Sep 2008 08:01:09 +0000 wheel letter two-letter key middle wheel dot cory doctorow cory rings top wheel Contest: Cory Doctorow's Cipher Wheel Rings <![CDATA[Judges consider whether FBI violated free speech in ISP case]]> http://securityratty.com/article/58b69eb9b923fa1f29e78ca973002976 http://securityratty.com/article/58b69eb9b923fa1f29e78ca973002976 Thu, 28 Aug 2008 19:20:52 +0000 internet service providers remain secret fbi letters government lawyer answer information panel wednesday Judges consider whether FBI violated free speech in ISP case <![CDATA[Blue Box #82: Asterisk & Skype security vulnerabilities, new VoIP security tools, VoIP steganography, VoIP security news and much, much more...]]> http://securityratty.com/article/ab8e0e22ebb1851ff664c3be0a3baa7d http://securityratty.com/article/ab8e0e22ebb1851ff664c3be0a3baa7d

Synopsis:  Blue Box #82: Asterisk & Skype security vulnerabilities, new VoIP security tools, VoIP steganography, VoIP security news and much, much more...

Welcome to Blue Box: The VoIP Security Podcast #82, a 47-minute podcast  from Dan York and Jonathan Zar covering VoIP security news, comments and opinions.   

Download the show here (MP3, 21MB) or subscribe to the RSS feed to download the show automatically. 

NOTE: This show was originally recorded on June 21, 2008.

You may also listen to this podcast right now:

Show Content:

  • 00:20 - Intro to the show, contact information and how to provide comments.  Welcome to all the new listeners - and to all those listeners who have been here for so long!
  • Programming notes:
    • Note about the production team – new special editions coming soon.
    • Note about URLs for the media files
  • AST-2008-008 – Remote Crash Vulnerability in SIP channel driver when run in pedantic mode
  • AST-2008-009 – Remote crash vulnerability in ooh323 channel driver
  • Skype-SB-2008-003 – Skype File URI Security Bypass Code Execution Vulnerability

  • New version of SIPvicious

  • Sipflanker – tool to find SIP devices with web GUIs

    • Comments, suggestions and feedback are welcome either as replies to this post  or via e-mail to blueboxpodcast@gmail.com.  Audio comments sent as attached MP3 files are definitely welcome and will be played in future shows.  You may also call the listener comment line at either +1-415-830-5439 or via SIP to 'bluebox@voipuser.org' to leave a comment there. 

    Thank you for listening and please do let us know what you think of the show.

    ]]> Wed, 27 Aug 2008 16:53:17 +0000 voip security voip security news voip voip security tools voip steganography voip services security skype security vulnerabilities voip security podcast Blue Box #82: Asterisk & Skype security vulnerabilities, new VoIP security tools, VoIP steganography, VoIP security news and much, much more... <![CDATA[Blue Box #82: Asterisk & Skype security vulnerabilities, new VoIP security tools, VoIP steganography, VoIP security news and much, much more...]]> http://securityratty.com/article/48c1a58b9d39348008877ad191ffcfea http://securityratty.com/article/48c1a58b9d39348008877ad191ffcfea

    Synopsis:  Blue Box #82: Asterisk & Skype security vulnerabilities, new VoIP security tools, VoIP steganography, VoIP security news and much, much more...

    Welcome to Blue Box: The VoIP Security Podcast #82, a 47-minute podcast  from Dan York and Jonathan Zar covering VoIP security news, comments and opinions.   

    Download the show here (MP3, 21MB) or subscribe to the RSS feed to download the show automatically. 

    NOTE: This show was originally recorded on June 21, 2008.

    You may also listen to this podcast right now:

    Show Content:

    • 00:20 - Intro to the show, contact information and how to provide comments.  Welcome to all the new listeners - and to all those listeners who have been here for so long!
    • Programming notes:
      • Note about the production team – new special editions coming soon.
      • Note about URLs for the media files
    • AST-2008-008 – Remote Crash Vulnerability in SIP channel driver when run in pedantic mode
    • AST-2008-009 – Remote crash vulnerability in ooh323 channel driver
    • Skype-SB-2008-003 – Skype File URI Security Bypass Code Execution Vulnerability

    • New version of SIPvicious

    • Sipflanker – tool to find SIP devices with web GUIs

      • Comments, suggestions and feedback are welcome either as replies to this post  or via e-mail to blueboxpodcast@gmail.com.  Audio comments sent as attached MP3 files are definitely welcome and will be played in future shows.  You may also call the listener comment line at either +1-415-830-5439 or via SIP to 'bluebox@voipuser.org' to leave a comment there. 

      Thank you for listening and please do let us know what you think of the show.

      ]]> Wed, 27 Aug 2008 15:53:18 +0000 voip security voip security news voip voip security tools voip steganography voip services security skype security vulnerabilities voip security podcast Blue Box #82: Asterisk & Skype security vulnerabilities, new VoIP security tools, VoIP steganography, VoIP security news and much, much more... <![CDATA[Full Disclosure and the Boston Farecard Hack]]> http://securityratty.com/article/40a098c4c848de62a0921d68f8cef2e7 http://securityratty.com/article/40a098c4c848de62a0921d68f8cef2e7 In eerily similar cases in the Netherlands and the United States, courts have recently grappled with the computer-security norm of "full disclosure," asking whether researchers should be permitted to disclose details of a fare-card vulnerability that allows people to ride the subway for free.

      The "Oyster card" used on the London Tube was at issue in the Dutch case, and a similar fare card used on the Boston "T" was the center of the U.S. case. The Dutch court got it right, and the American court, in Boston, got it wrong from the start -- despite facing an open-and-shut case of First Amendment prior restraint.

      The U.S. court has since seen the error of its ways -- but the damage is done. The MIT security researchers who were prepared to discuss their Boston findings at the DefCon security conference were prevented from giving their talk.

      The ethics of full disclosure are intimately familiar to those of us in the computer-security field. Before full disclosure became the norm, researchers would quietly disclose vulnerabilities to the vendors -- who would routinely ignore them. Sometimes vendors would even threaten researchers with legal action if they disclosed the vulnerabilities.

      Later on, researchers started disclosing the existence of a vulnerability but not the details. Vendors responded by denying the security holes' existence, or calling them just theoretical. It wasn't until full disclosure became the norm that vendors began consistently fixing vulnerabilities quickly. Now that vendors routinely patch vulnerabilities, researchers generally give them advance notice to allow them to patch their systems before the vulnerability is published. But even with this "responsible disclosure" protocol, it's the threat of disclosure that motivates them to patch their systems. Full disclosure is the mechanism (.pdf) by which computer security improves.

      Outside of computer security, secrecy is much more the norm. Some security communities, like locksmiths, behave much like medieval guilds, divulging the secrets of their profession only to those within it. These communities hate open research, and have responded with surprising vitriol to researchers who have found serious vulnerabilities in bicycle locks, combination safes (.pdf), master-key systems and many other security devices.

      Researchers have received a similar reaction from other communities more used to secrecy than openness. Researchers -- sometimes young students -- who discovered and published flaws in copyright-protection schemes, voting-machine security and now wireless access cards have all suffered recriminations and sometimes lawsuits for not keeping the vulnerabilities secret. When Christopher Soghoian created a website allowing people to print fake airline boarding passes, he got several unpleasant visits from the FBI.

      This preference for secrecy comes from confusing a vulnerability with information about that vulnerability. Using secrecy as a security measure is fundamentally fragile. It assumes that the bad guys don't do their own security research. It assumes that no one else will find the same vulnerability. It assumes that information won't leak out even if the research results are suppressed. These assumptions are all incorrect.

      The problem isn't the researchers; it's the products themselves. Companies will only design security as good as what their customers know to ask for. Full disclosure helps customers evaluate the security of the products they buy, and educates them in how to ask for better security. The Dutch court got it exactly right when it wrote: "Damage to NXP is not the result of the publication of the article but of the production and sale of a chip that appears to have shortcomings."

      In a world of forced secrecy, vendors make inflated claims about their products, vulnerabilities don't get fixed, and customers are no wiser. Security research is stifled, and security technology doesn't improve. The only beneficiaries are the bad guys.

      If you'll forgive the analogy, the ethics of full disclosure parallel the ethics of not paying kidnapping ransoms. We all know why we don't pay kidnappers: It encourages more kidnappings. Yet in every kidnapping case, there's someone -- a spouse, a parent, an employer -- with a good reason why, in this one case, we should make an exception.

      The reason we want researchers to publish vulnerabilities is because that's how security improves. But in every case there's someone -- the Massachusetts Bay Transit Authority, the locksmiths, an election machine manufacturer -- who argues that, in this one case, we should make an exception.

      We shouldn't. The benefits of responsibly publishing attacks greatly outweigh the potential harm. Disclosure encourages companies to build security properly rather than relying on shoddy design and secrecy, and discourages them from promising security based on their ability to threaten researchers. It's how we learn about security, and how we improve future security.

      This essay previously appeared on Wired.com.

      EDITED TO ADD (8/26): Matt Blaze has a good essay on the topic.

      ]]>       Tue, 26 Aug 2008 02:04:49 +0000 computer security improves security improves computer security security mit security researchers security devices security holes disclosure security properly Full Disclosure and the Boston Farecard Hack       <![CDATA[Open Letter to Verizon Wireless]]> http://securityratty.com/article/33861048df9fa12f13bd8d46690d0a5b http://securityratty.com/article/33861048df9fa12f13bd8d46690d0a5b After receiving no support from agents at the Verizon Wireless store or by agents on the phone, I decided to write them and make it an open letter.  It’s no secret that Verizon has a great network, but it’s also no secret that their phone selection stinks.  I don’t want to leave them and am hoping that whatever little bad press I can cause will encourage them to resolve the issue.  If not, I’m tapping out.  For 3 years I have hated my phone and loved their network.  I’m ready to feel mediocre about both.  Here it goes:

      I am currently without a phone and would appreciate a speedy reply.

      I have been a Verizon Wireless customer for over 5 years and my monthly bill easily averages over $200 during that time frame.  While I love your network, I have been completely unsatisfied by your selection of phones.  It is a stretch to say that my last phone worked—it had a feature called a battery that allowed me to switch from the car charger to my office charger without dying.  And I waited—under duress—until I was allowed to purchase a new phone with the discount.

      My current phone has a wonderful battery life, but this is the 4th time the charger has snapped off in the phone.  The phone is fine, but I keep paying $30 for new chargers.  I refuse to purchase another or wait until February when I will be eligible for a new phone.  You sold a phone with a design flaw, and I’m not even asking for a refund or a free phone.  Just allow me to take a chance on a new one at the 2 year contract renewal rate. 

      If not, I will gladly pay the early termination fee and leave Verizon.  On general principle, I will spend more money canceling my account with you than I would likely receive as a discount on a new phone.  As a customer, I consider it unacceptable that you sell inferior phones and leave me with no recourse.

      The first time I waited haplessly to become eligible for a new phone.  I will not suffer a second time.  If you don’t like the fact that you will end up losing money by allowing me to purchase a new phone early, I suggest you take it up your vendors who supply you with awful products.  I can promise you that we will both lose more money if you don’t.

      Sincerely,

      Eric Marvets

      ]]>       Mon, 25 Aug 2008 11:43:00 +0000 phone phone workedit free phone current phone verizon phone selection stinks verizon wireless store time verizon wireless customer Open Letter to Verizon Wireless       <![CDATA[Are you hiding secret messages in LOLCAT photos?]]> http://securityratty.com/article/2a68d795d9fc63b1eeb111699b8c2535 http://securityratty.com/article/2a68d795d9fc63b1eeb111699b8c2535 Thu, 21 Aug 2008 05:04:33 +0000 sensitive financial data data image files exfiltration method department tricky steganography student justice Are you hiding secret messages in LOLCAT photos? <![CDATA[Boston Court's Meddling With 'Full Disclosure' Is Unwelcome]]> http://securityratty.com/article/b65bde3bbcffdced12efa1287ce8e1e0 http://securityratty.com/article/b65bde3bbcffdced12efa1287ce8e1e0 In eerily similar cases in the Netherlands and the United States, courts have recently grappled with the computer-security norm of "full disclosure," asking whether researchers should be permitted to disclose details of a fare-card vulnerability that allows people to ride the subway for free.

      The "Oyster card" used on the London Tube was at issue in the Dutch case, and a similar fare card used on the Boston "T" was the center of the U.S. case. The Dutch court got it right, and the American court, in Boston, got it wrong from the start -- despite facing an open-and-shut case of First Amendment prior restraint.

      The U.S. court has since seen the error of its ways -- but the damage is done. The MIT security researchers who were prepared to discuss their Boston findings at the DefCon security conference were prevented from giving their talk.

      The ethics of full disclosure are intimately familiar to those of us in the computer-security field. Before full disclosure became the norm, researchers would quietly disclose vulnerabilities to the vendors -- who would routinely ignore them. Sometimes vendors would even threaten researchers with legal action if they disclosed the vulnerabilities.

      Later on, researchers started disclosing the existence of a vulnerability but not the details. Vendors responded by denying the security holes' existence, or calling them just theoretical. It wasn't until full disclosure became the norm that vendors began consistently fixing vulnerabilities quickly. Now that vendors routinely patch vulnerabilities, researchers generally give them advance notice to allow them to patch their systems before the vulnerability is published. But even with this "responsible disclosure" protocol, it's the threat of disclosure that motivates them to patch their systems. Full disclosure is the mechanism (.pdf) by which computer security improves.

      Outside of computer security, secrecy is much more the norm. Some security communities, like locksmiths, behave much like medieval guilds, divulging the secrets of their profession only to those within it. These communities hate open research, and have responded with surprising vitriol to researchers who have found serious vulnerabilities in bicycle locks, combination safes (.pdf), master-key systems and many other security devices.

      Researchers have received a similar reaction from other communities more used to secrecy than openness. Researchers -- sometimes young students -- who discovered and published flaws in copyright-protection schemes, voting-machine security and now wireless access cards have all suffered recriminations and sometimes lawsuits for not keeping the vulnerabilities secret. When Christopher Soghoian created a website allowing people to print fake airline boarding passes, he got several unpleasant visits from the FBI.

      This preference for secrecy comes from confusing a vulnerability with information about that vulnerability. Using secrecy as a security measure is fundamentally fragile. It assumes that the bad guys don't do their own security research. It assumes that no one else will find the same vulnerability. It assumes that information won't leak out even if the research results are suppressed. These assumptions are all incorrect.

      The problem isn't the researchers; it's the products themselves. Companies will only design security as good as what their customers know to ask for. Full disclosure helps customers evaluate the security of the products they buy, and educates them in how to ask for better security. The Dutch court got it exactly right when it wrote: "Damage to NXP is not the result of the publication of the article but of the production and sale of a chip that appears to have shortcomings."

      In a world of forced secrecy, vendors make inflated claims about their products, vulnerabilities don't get fixed, and customers are no wiser. Security research is stifled, and security technology doesn't improve. The only beneficiaries are the bad guys.

      If you'll forgive the analogy, the ethics of full disclosure parallel the ethics of not paying kidnapping ransoms. We all know why we don't pay kidnappers: It encourages more kidnappings. Yet in every kidnapping case, there's someone -- a spouse, a parent, an employer -- with a good reason why, in this one case, we should make an exception.

      The reason we want researchers to publish vulnerabilities is because that's how security improves. But in every case there's someone -- the Massachusetts Bay Transit Authority, the locksmiths, an election machine manufacturer -- who argues that, in this one case, we should make an exception.

      We shouldn't. The benefits of responsibly publishing attacks greatly outweigh the potential harm. Disclosure encourages companies to build security properly rather than relying on shoddy design and secrecy, and discourages them from promising security based on their ability to threaten researchers. It's how we learn about security, and how we improve future security.

      ---

      Bruce Schneier is Chief Security Technology Officer of BT Global Services and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World. You can read more of his writings on his website.


      ]]>       Thu, 21 Aug 2008 00:00:00 +0000 computer security improves security improves computer security security mit security researchers security devices security holes disclosure security properly Boston Court's Meddling With 'Full Disclosure' Is Unwelcome       <![CDATA[Opera patches 7 bugs, but keeps one secret]]> http://securityratty.com/article/4b997653100bca02cc00354a6ada4462 http://securityratty.com/article/4b997653100bca02cc00354a6ada4462

      ]]>       Wed, 20 Aug 2008 09:00:00 +0000 opera software asa software remains flagship browser cross-site information fixes vulnerabilities vulnerability risk Opera patches 7 bugs, but keeps one secret