Google just released a new set of security features for Gmail. However, you cannot turn on the "always use HTTPS" option if you are also using the older java based Gmail Mobile client for smart phones, like the Blackberry. They have written that app to always fetch new mail and post actions like delete and archive over HTTP instead of HTTPS. With Gmail's new require-HTTPS feature enabled, the mobile client will error out that it cannot fetch mail. The new version (2.0.5 as of right now), is a little quirky with this setting, but it will work with require-HTTPS enabled.
Without the new version, smart phones which can fetch content over local WiFi have a ready made attack vector. Blackberries, which route all traffic through an encrypted tunnel back to the company's BES (Blackberry Enterprise Server), would find themselves vulnerable to eavesdropping and MITM closer to the BES (i.e. the corporate LAN), or, of course, at any hop along the way from the corporate LAN through the ISPs (but ISPs would never snoop on your email ;).
With these embedded devices, how many people stop to think about which protocols these apps use under the hood? It's not like on a traditional browser, where the user can at least monitor link destinations via a status bar. I would also venture to say that not too many people worry about keeping app versions up to date-- there haven't been too many nagging update applications for the majority of smart phones, yet. Google's Mobile Updater requires the user to go in and manually check for new versions. So, it's even more imperative for these app developers to get it right the first time.
Gmail Notifier is also experiencing similar issues.
Saturday, August 23, 2008
Saturday, August 16, 2008
The Case of MIT Subway Hackers
By now, you may have read about a group of MIT Students who were set to present some insecurity details of the "CharlieCard" subway system used in Boston and elsewhere. [I myself had wondered just exactly what data resides on the magnetic stripes of a similar transit card from the Washington DC subway system, just this summer. It doesn't take much hard thinking to realize that a requirement for these machines is that they have to work regardless of whether there is connectivity back to the central office to validate a transit card; ergo, there must be monetary values stored on the card.] The transit authority didn't like it and got a federal judge to issue a gag order. A lot of good that did, because MIT still has the presentation (and other items) posted here. And now the Electronic Frontier Foundation is fighting the legal battle for the students. But the real question here (which stirs the disclosure debate once again) is: Who is at fault here?
Short version: everybody is at fault.
Long version ...
On the one hand, this group of students, led by world renown Ron Rivest (that's right, the "R" in the "RSA" encryption alogorithm), only informed the transit authority a week before the presentation that they were going to give the talk at DEFCON. That's right, just 1 week. And their advisor, Ron Rivest, was out of town for at least part of that time. The CFP (Call For Papers) closed on May 15. DEFCON's policy is to notify submissions of acceptance within two business days. So the MIT undergrads should have known no later than Monday, May 19, that they were going to be giving the talk. This wasn't impromptu. In order to get accepted, they would have had to bring the goods. So, they clearly knew enough to start the communication process with the Transit Authority. Giving the MBTA less than a week to respond (this is the bureaucratic US government we're talking about-- nothing gets done in one week) certainly put them on the defensive. That was a stupid mistake by the MIT crew.
On the other hand, fueled by a stick-your-head-in-the-sand and an I-hate-academic-research pair of attitudes, the Transit Authority's gag order really sets a dangerous precedent. Two Ivy League Computer Science Professors with quite the reputation when it comes to security, Matt Blaze at U Penn and Columbia University's Steve Bellovin, have spoken out against this bad precedent, arguing that it stifles needed future research. They also signed a letter from the EFF in an attempt to overturn the ruling (PDF). Here is the list of Professors and Researchers who signed the letter:
Another fault is that both the Federal courts and the MBTA thought they could control the dissemination of the information solely with a gag order. Have they any clue exactly what sort of people attend Blackhat and DEFCON every August in Las Vegas? The injunction was late; the CDs with presentation materials were already printed and distributed to paying attendees. Good luck getting that content back (even if MIT wasn't bold enough to keep it posted). And there's another HUGE side-effect by gagging presenters at DEFCON: it spurs interest in the roughly 6 or 7 thousand attendees (and all of the others around the world who didn't attend for one reason or another) to take what little knowledge is known (i.e. subway payment system cards can be hacked to get free rides) and make an all-out war against the people trying to withold the information (the MBTA). Even if the talk wasn't one of the best this year, it now holds an elusive status, which is more than enough justification for a bunch of people (who are paid to understand how systems break) to spend extra time figuring out the forboden details. That was plain stupid on the MBTA's part. Even if they thought the students were criminal or inciting criminal fraud, they should have taken another approach (e.g. finding a way to make them financially liable for lost revenue due to fraud committed by these techniques-- not that I condone that action, it just would have been more effective).
How could this have gone better?
Well, Ron Rivest, on behalf of his students, could have contacted the MBTA months in advance. They could have scheduled full briefs with the appropriate audiences without the pressure to immediately act (which is what resulted in the MBTA calling the FBI and pursuing a fraud investigation against the students).
Short version: everybody is at fault.
Long version ...
On the one hand, this group of students, led by world renown Ron Rivest (that's right, the "R" in the "RSA" encryption alogorithm), only informed the transit authority a week before the presentation that they were going to give the talk at DEFCON. That's right, just 1 week. And their advisor, Ron Rivest, was out of town for at least part of that time. The CFP (Call For Papers) closed on May 15. DEFCON's policy is to notify submissions of acceptance within two business days. So the MIT undergrads should have known no later than Monday, May 19, that they were going to be giving the talk. This wasn't impromptu. In order to get accepted, they would have had to bring the goods. So, they clearly knew enough to start the communication process with the Transit Authority. Giving the MBTA less than a week to respond (this is the bureaucratic US government we're talking about-- nothing gets done in one week) certainly put them on the defensive. That was a stupid mistake by the MIT crew.
On the other hand, fueled by a stick-your-head-in-the-sand and an I-hate-academic-research pair of attitudes, the Transit Authority's gag order really sets a dangerous precedent. Two Ivy League Computer Science Professors with quite the reputation when it comes to security, Matt Blaze at U Penn and Columbia University's Steve Bellovin, have spoken out against this bad precedent, arguing that it stifles needed future research. They also signed a letter from the EFF in an attempt to overturn the ruling (PDF). Here is the list of Professors and Researchers who signed the letter:
- Prof David Farber, Carnegie Mellon
- Prof Steven M Bellovin, Columbia University
- Prof David Wagner, UC Berkeley
- Prof Dan Wallach, Rice University
- Prof Tadayoshi Kohno, U Washington
- Prof David Touretzky, Carnegie Mellon
- Prof Patrick McDaniel, Penn State University
- Prof Lorrie Faith Cranor, Carnegie Mellon
- Prof Matt Blaze, U Penn
- Prof Stefan Savage, UC San Diego
- Bruce Schneier
Another fault is that both the Federal courts and the MBTA thought they could control the dissemination of the information solely with a gag order. Have they any clue exactly what sort of people attend Blackhat and DEFCON every August in Las Vegas? The injunction was late; the CDs with presentation materials were already printed and distributed to paying attendees. Good luck getting that content back (even if MIT wasn't bold enough to keep it posted). And there's another HUGE side-effect by gagging presenters at DEFCON: it spurs interest in the roughly 6 or 7 thousand attendees (and all of the others around the world who didn't attend for one reason or another) to take what little knowledge is known (i.e. subway payment system cards can be hacked to get free rides) and make an all-out war against the people trying to withold the information (the MBTA). Even if the talk wasn't one of the best this year, it now holds an elusive status, which is more than enough justification for a bunch of people (who are paid to understand how systems break) to spend extra time figuring out the forboden details. That was plain stupid on the MBTA's part. Even if they thought the students were criminal or inciting criminal fraud, they should have taken another approach (e.g. finding a way to make them financially liable for lost revenue due to fraud committed by these techniques-- not that I condone that action, it just would have been more effective).
How could this have gone better?
Well, Ron Rivest, on behalf of his students, could have contacted the MBTA months in advance. They could have scheduled full briefs with the appropriate audiences without the pressure to immediately act (which is what resulted in the MBTA calling the FBI and pursuing a fraud investigation against the students).
Wednesday, August 13, 2008
Linux SSO to AD
This is a break from the traditional types of posts. It's more of an instructional howto, but I hope that it is valuable nonetheless.
...
Ah, the holy grail of Identity Management: Single Sign On. And in today's enterprise, that likely means Microsoft's Active Directory at the back end. While directions for bringing unix/linux boxes into the AD forest have been out there, they have been sticky at least, requiring random config changes to PAM, Kerberos, Samba, LDAP(S), etc.
Enter likewise-open, which is a great way to package all those up. It's a free software package that also comes with optional enterprise support, which anti-free-and-open-source companies tend to like.
Sure, there are tons of great examples out there that will tell you how to get likewise-open installed (which is a dream compared to the old days of manually configuring Kerberos, PAM, etc.). BUT, they leave you high and dry with any user in the whole domain (possibly the forest) being able to log into the computer, since they focus on "authentication" and not "authorization". Since when is that better than less passwords? They also don't properly show how to manage privileged access once logged in. So the following are some subtle configuration details and nuggets for which I have had to comb the web and anyone who really does enterprise SSO will appreciate.
This will assume you have likewise-open installed, which if you don't, on Ubuntu it's as simple as: sudo apt-get install likewise-open.
For that matter, this entire thing assumes Ubuntu, but would work elsewhere (paths may vary).
Joining to the domain is very easy, too: sudo domainjoin-cli join fully.qualified.domain.name UserID
Now, you probably want to limit who can log on to the shell to just admins. After all, it's Unix; it's not a toy. Use your favorite text editor (as root or sudo) and edit /etc/security/pam_lwidentity.conf. Uncomment this line require_membership_of and add an AD group containing those admins in the Domain\Group format.
Next you'll want to make sure those admins can use sudo otherwise you'll have a root password management problem (the whole point of SSO is to reduce the number of passwords to manage, right?). Edit the /etc/sudoers file by typing sudo visudo and add a line in this format: %DOMAIN\\Group ALL=(ALL) ALL (if you want to allow everything-- follow normal sudo permissions rules to restrict further).
Last, but not least, you'll probably want to get a psychological acceptance from administrators as a security design principle, right? In order to do that, let's get rid of that pesky Domain\UserID format and just use the UserID format. After all, who wants to type in ssh 'domain\userid'@computername when they can just type in ssh computername? This is the coup de grâce in favor of less passwords. Again, as root or sudo, edit /etc/samba/lwiauthd.conf and add winbind use default domain = yes to the end of the file. If you're in a multi-domain forest, you're up a creek (not to mention you probably have a less than simple environment anyway), and at a minimum your users in other domains will have to specify the domain\userid format. But users in the same domain can log in without the domain\ prefix.
One recipe for quick SSO to AD on Unix/Linux in a mere few minutes. Enjoy.
...
Ah, the holy grail of Identity Management: Single Sign On. And in today's enterprise, that likely means Microsoft's Active Directory at the back end. While directions for bringing unix/linux boxes into the AD forest have been out there, they have been sticky at least, requiring random config changes to PAM, Kerberos, Samba, LDAP(S), etc.
Enter likewise-open, which is a great way to package all those up. It's a free software package that also comes with optional enterprise support, which anti-free-and-open-source companies tend to like.
Sure, there are tons of great examples out there that will tell you how to get likewise-open installed (which is a dream compared to the old days of manually configuring Kerberos, PAM, etc.). BUT, they leave you high and dry with any user in the whole domain (possibly the forest) being able to log into the computer, since they focus on "authentication" and not "authorization". Since when is that better than less passwords? They also don't properly show how to manage privileged access once logged in. So the following are some subtle configuration details and nuggets for which I have had to comb the web and anyone who really does enterprise SSO will appreciate.
This will assume you have likewise-open installed, which if you don't, on Ubuntu it's as simple as: sudo apt-get install likewise-open.
For that matter, this entire thing assumes Ubuntu, but would work elsewhere (paths may vary).
Joining to the domain is very easy, too: sudo domainjoin-cli join fully.qualified.domain.name UserID
Now, you probably want to limit who can log on to the shell to just admins. After all, it's Unix; it's not a toy. Use your favorite text editor (as root or sudo) and edit /etc/security/pam_lwidentity.conf. Uncomment this line require_membership_of and add an AD group containing those admins in the Domain\Group format.
Next you'll want to make sure those admins can use sudo otherwise you'll have a root password management problem (the whole point of SSO is to reduce the number of passwords to manage, right?). Edit the /etc/sudoers file by typing sudo visudo and add a line in this format: %DOMAIN\\Group ALL=(ALL) ALL (if you want to allow everything-- follow normal sudo permissions rules to restrict further).
Last, but not least, you'll probably want to get a psychological acceptance from administrators as a security design principle, right? In order to do that, let's get rid of that pesky Domain\UserID format and just use the UserID format. After all, who wants to type in ssh 'domain\userid'@computername when they can just type in ssh computername? This is the coup de grâce in favor of less passwords. Again, as root or sudo, edit /etc/samba/lwiauthd.conf and add winbind use default domain = yes to the end of the file. If you're in a multi-domain forest, you're up a creek (not to mention you probably have a less than simple environment anyway), and at a minimum your users in other domains will have to specify the domain\userid format. But users in the same domain can log in without the domain\ prefix.
One recipe for quick SSO to AD on Unix/Linux in a mere few minutes. Enjoy.
Subscribe to:
Posts (Atom)