Recently, due to laptop thefts at work and the risk of Personally Identifiable Information (PII) loss, I had to make the difficult choice to start a project to force encrypt our user laptops. So, due to “what do we already own?” , I chose Microsoft Bitlocker for the Windows 7 computers, and FileVault for the Macintosh OSX 10.7 computers.
That seems fine, however, one “snag”… I use a dual boot Backtrack 5 and Windows 7 machines DAILY at work. So, being the guy who lives by the rule “Don’t give an order that you’re not willing to follow yourself” kind of guy, I had to figure out how to encrypt my windows side and still boot Backtrack 5.
I got it to work. I was painful.
take a second to re-read that. yes, it works, and yes, it caused me pain to make it work.
So, here are the steps I used to make this work:
Step 1: Wipe the drive. (you should have backed it up if you needed to save something… I shouldn’t have to tell you that.)
Step 2: Create a partition for the Win7 to be housed. Make it the first partition. Leave unallocated space for BackTrack. (I left 30 gigs for backtrack… you probably want more, I have a lot of scripts that always put captured data on something external that I mount and encrypt with Truecrypt…)
Step 3: Install Windows7 (or dump your standard image) to that partition. Mine created a 100MB boot thing before the windows 7 partition, let it do whatever it wants to do, except use that unallocated space you already saved for Backtrack.
Step 4: Boot Windows 7 and test. Make sure Windows 7 works first! (Well, functions as well as one could expect for Windows)
Step 5: In Windows, run this command from a command prompt: “%windir%\System32\BdeHdCfg.exe” -target default (this command preps the drive for Bitlocker.)
Step 6: Encrypt the drive via Bitlocker with your pin. (record the recovery key. this is the single more important long string of numbers you’ll ever deal with in Windows. Preserve it, protect it. This key is your life, young padawan…)
Step 7: When it’s done, Boot Windows 7 and test. Make sure Windows 7 still works! (Well, functions as well as one could expect for Windows)
Step 8: Pause Bitlocker. I turned it off. (this seems to make no sense, but I had a problem testing this that if I tried to encrypt the drive after installing Linux, forget it, it died.)
Step 9: Boot Backtrack 5 DVD/USB key.
Step 10: Install backtrack 5 to that new unallocated partition. I configured /dev/sda3 as my /boot partition and /dev/sda5 as my root and /dev/sda6 as my swap. /dev/sda1 was the windows 7 boot partition and /dev/sda2 was my windows 7 system partition)
Step 11: make sure when you install grub, you install it to /dev/sda3. DO NOT PUT IT IN THE MBR or /dev/sda or /dev/sda1. If you do, you just screwed yourself.
Step 12: This will only boot to Windows 7 still. Grab BCDEDIT for windows, and add a boot option to boot linux on /dev/sda3.
Step 13: Boot Windows 7 and test. Make sure Windows 7 still works! (Well, functions as well as one could expect for Windows)
Step 14: Boot Backtrack 5 from the windows boot menu. it should shell to grub, boot it. Make sure Backtrack 5 works.
Step 15: Boot Windows 7 and turn Bitlocker back on. (record the recovery key. this is the single more important long string of numbers you’ll ever deal with in Windows. Preserve it, protect it. This key is your life, young padawan…)
Step 16: It should present you the windows 7 boot menu, where option 1 is Windows 7 and option 2 is Backtrack Linux then it should now prompt you for your Bitlocker pin.
I can’t stress two things: #1) this took me weeks of wiping the drive to figure this out. Don’t be shocked if you have to tweek the steps for your specific situation. #2) that recovery key is the most important thing in this process…
a few notes: (things that make you go Hmmmm…)
1) It asks you to pick which OS first, then prompts you to enter your Bitlocker pin… You can’t boot linux unless you unlock bitlocker first. Not sure why, but I’ll call it an “added feature!” Remember, the linux side is NOT ENCRYPTED! That means don’t be an *idiot* what you store there, assume it’s accessible if someone takes your laptop.
2) After you update-grub, plan on having your recovery password around for Bitlocker… it always keeps asking me for it after I update grub, even though it’s installed to the /boot partition. (/dev/sda3 in my case) Don’t leave your recovery key in your laptop bag, because that defeats the purpose of encrypting it, duh. I can’t stress that enough. The whole “point” is to protect the windows side in case anyone takes your laptop from getting any useful info off it…. Don’t forget the goal while you’re having so much fun messing with this nightmare.
–Bill (General Major Webelo Captain Zapp Brannigan)
So, being someone who used Backtrack daily for my career, I routinely make sure I’m current with Backtrack. So Backtrack 5 is out, I went and grabbed x64 KDE version, backedup up my PSKL directory on BT4R2, and blew it away…
First thing, startx didn’t load from the DVD until I removed some cache files…
So finally startx loaded and I was able to use the graphical installer to install it to my hard drive on my laptop.
When I rebooted, I did startx, and got a kernel panic (blinking caps lock light). So I’m like, “M’kay, x64 kde is borked…” so I grabbed x64 gnome, repeat process, same things, x32 gnome, repeat process, same thing. ok, it’s NOT borked, I’m just not doing it right.
so I searched and searched, found nothing immediately useful. (I could bore the heck out of anyone with some of the searches I did to get at this one…)
Finally, I found this kernel parameter: i915.modeset=1
they should rename that to “setbrokentofixed=1”
So, put that at the end of your GRUB_CMDLINE_LINUX_DEFAULT in your /etc/default/grub and update-grub!
Boom, I appended that and now startx works and I can enjoy the BT5 goodness… Now I just gotta configure my metasploit account on there and put my pskl directory back with all out awesome scripts.
Enjoy BackTrack 5!
Update (June 15th 2011): Talking with a few others, including the great comments here, you might need this like in your /etc/default/grub
Alternative line from Daveonator:
GRUB_CMDLINE_LINUX_DEFAULT=”text splash vga=791 i915.modeset=1″
Try it, and let us know.
We are all so busy applauding facebook for adding an “always use HTTPS” setting (thanks for finally responding to firesheep, folks), but maybe we should look a little more closely at it before telling the moms of the world to just set it and forget it. The stupid thing turns itself off (and doesn’t turn itself back on) when you go to a non-HTTPS facebook page.
In case you haven’t seen it described on 50,000 websites at this point, here’s the deal with the new “feature:”
Click on “Account” at the upper right of your facebook page and choose “Account Settings” … you’ll get something like this:
Click on “Account Security” and you’ll be able to check the new https box, illustrated here:
note that it says “whenever possible” … this implies that there are some parts of the facebook site that are NOT capable of being served up via https. I have no idea why this is still the case, but it clearly is. The wording would also imply that once you check this box, you will get a https connection “whenever possible” and a http connection when https is not possible. What it DOESN’T say is that the first time you view a non-https page, the box will simply uncheck itself and next time you go to a https-capable page, it’ll be back in vanilla http mode.
So what are these non-https-capable pages? I can’t speak for all of them, but I’d be willing to bet that most of them are “facebook applications.” The only facebook app I use is Scrabble. After checking the https box, I tried to go to Scrabble and I got this page first:
Excellent, right? It is warning me that I’m leaving the safe-and-cozy https-zone. What this warning SHOULD say is “if you hit ‘continue,’ you are permanently turning off the https option.”
Yes, that’s right, once I’m done playing my turn in the http-only-danger-zone of the Scrabble application, I go back to facebook home and I’m back to http.
I went back to check my account settings and I see this:
Well, that’s just fantastic. What’s the point of saying “whenever possible” when it means “until impossible?” This has to be a mistake, and I hope they fix it… then we can all tell our moms to go and re-check the box as it has probably been turned off when they went to play farmville or whatever the hell other pages are non-https.
This was discussed on Tech News Today (first 5 minutes)
Well, it’s that time of year again: ShmooCon is right around the corner. Unfortunately, after attending every single ShmooCon thus far (also presenting at two of them, not to mention the commercials we made), we’re not going to be there this year.
Our spirits have finally been completely broken by the travesty that is the ShmooCon ticket purchasing process. Every year was a battle, but we really really thought they’d have it worked out by now.
We’re fed up and we’re simply not going.
Before I go any further, I want to get a few points out of the way. This entire diatribe is based on a few assumptions. If these assumptions are not correct (or if you simply don’t agree with them), don’t bother reading any more. Also, if somebody from the Shmoo group were to tell me that these assumptions are absolutely not correct, then the con is not what I thought it was and it is not for me.
Assumption 1: The Shmoo group would like to build a community around ShmooCon. A lot of familiar faces (both presenters and attendees) make this small con special. While we understand perfectly well that ShmooCon will go on happily without us, we’d like to think that we’re part of that community (and valued as such).
Assumption 2: The Shmoo group’s motivation for selling tickets the way they do is that they want to keep the price down and allow people of all income levels to attend. Their motivation is NOT to create ridiculously over-inflated demand, force people to hoard tickets so that all their friends can attend, and then have an ebay market created around the hoarded tickets that are left over.
We tried to get tickets this year at all 3 chances. Only one of us succeeded. Others were foiled by the crappy captcha system, the link showing up at random places on the page, coding errors on the website, and general problems just connecting to the site while it is being crushed by traffic. Some of these problems were documented here http://ow.ly/RJOm
Many people seem amused that acquiring tickets has become a hacking contest or even a lottery of sorts. We are not amused. Shmoocon should not be amused. We have jobs, we have lives, we don’t need more challenges just to get friggin’ tickets to attend a con we’ve been supporting for the past 5 years. So what are the real problems here?
There are many.
- The Shmoo Group should just give up trying to run the ticket sales themselves. They don’t have the hardware, the expertise, or the attention to detail needed to make the process fair. Let professionals handle it.
- The idealistic “we’ll keep the price down” philosophy goes against all the rules of supply and demand. The size of the venue limits supply to a level significantly lower than demand. This is not natural. Nature abhors this kind of inequity and it should be remedied.
- If a group of people would like to attend, they have no choice but to have every member try to buy as many tickets as possible in the hopes that they’ll have enough total tickets once the dust settles. Usually they end up having a few too many and the extras end up on ebay. Tickets on ebay often sell for $300 to $400. Many people have figured out that proper hoarding of tickets + ebay sales ends up netting enough profit to pay for their own ticket along with travel expenses. This high-demand, high-profit market should not exist.
We’re not just about bitching, we’re also about solutions. So here are our pie-in-the-sky ideas to address the problems:
Option 1: The Shmoo Community
Each November, email the prior year’s attendees with a unique code. That code can be used one time within 30 days to purchase a barcode for the upcoming conference. The attendee can choose to pay either $150 for a normal ticket or $300 for the “I Love ShmooCon” package. Tickets that are not sold after 30 days go up on ebay. Profits go to ShmooCon, not to Joe Tickethoarder. Sure, some people would buy tickets using their code and then sell them on ebay…but at least they can’t buy a BUNCH of tickets and sell them on ebay.
This would ensure that a community builds around ShmooCon. The downside is that lots of people can’t get in..which brings me to:
Option 2: The Venue
The Wardman Park Mariott has been a great venue for ShmooCon, but the available space really limits the number of attendees. As I mentioned before, demand for tickets is significantly higher than supply. You can fix this in one of two ways: decrease demand (by raising the price) or increase supply (by changing to a larger venue). Personally, I’d like to see the venue grow rather than the price. I understand, however, the Shmoo group’s hesitance to do so. They have a good relationship with the WPM and the size is “manageable” for their staff. A larger venue would introduce a number of logistical nightmares they would rather avoid (this is an assumption on my part).
So raise the price.
Option 3: The Price
I know, I know. You want to keep the prices down. Honestly, all you are doing is making the profits bigger for the people who buy the cheap tickets and sell them on ebay for the REAL going rate….and forcing the stampede at ticket release time.
The problem is: you can’t have it both ways. You can’t have a limited venue AND get everybody in who wants to come. This is why they didn’t hold Woodstock at Radio City Music Hall. By holding the conference in a small-ish venue, you have CREATED the exclusivity. There is nothing wrong with exclusivity. Use it. Profit from it….and use the profits to make the Con even BETTER.
One way to find the REAL going rate of your tickets is to let the open market determine it. Just list ALL the tickets on ebay, in waves, and see how much they go for. I’m willing to bet they would go for $250-$300 on average. Certainly cheaper than they sell for now, and I’d feel more confident buying them directly from the Shmoo Group rather than some shady seller. There’s nothing stopping some sneaky ass from selling the same barcode over and over again on ebay (or barcodes from previous years)…might be happening right now. Nobody would know anything was wrong until all the buyers showed up at the Con and tried to get in.
I’m genuinely disappointed that we won’t be attending this year. We really like ShmooCon and we really like the people who make it happen. I hope that they can find a way to keep it the Con they always wanted it to be, yet still be fair to the people who are willing to pay to attend.
Feb 3 UPDATE: ShmooCon 2010 tickets have sold on eBay for as much as $667. The 20+ tickets I can see that sold on eBay since late January (as far back as their history goes) have sold for an average of $443.
Here’s my message to Steve Gibson and Leo Laporte (from the fantastic Security Now podcast) regarding Steve’s endorsement of SSH tunnels as an viable alternative to IPSEC VPNs. Enjoy!
Podcast Transcript: http://www.grc.com/sn/sn-188.txt
— snip —
In episode #188, you discussed the use of SSH tunnels as an alternative to IPSec and SSL VPNs. I am writing to point out a few flaws in this “poor man’s VPN” that make it significantly weaker and prone to attacks that do not affect a true IPSec tunnel.
In the scenario described, the user establishes an SSH session to a remote host using the “-D 1080” option, which automatically forms a SOCKS v5 proxy to the remote host. Configuring your browser to use Socks V5 on localhost, port 1080, does in fact work quite elegantly to tunnel all browser-generated traffic through the socks proxy, making it immune to snooping and tampering.
Great! So, what’s the problem?
The problem is that only browser-generated traffic goes through the tunnel. DNS requests are not generated by the browser; they are generated by the host operating system and are not tunneled. Consider the following scenario as an example:
1) You’re seated at the local hostile internet cafe and you connect to their wireless network. You establish an SSH tunnel and prepare to do some online banking.
2) You enter http://www.my-bank.com into your browser and hit enter.
3) Your browser asks your OS to perform a DNS lookup of www.my-bank.com. What server is it going to ask? The DNS server learned via DHCP from the internet cafe’s unencrypted wireless network.
4) Bad guy intercepts your DNS request, spoofs a reply and redirects you to his version of your bank’s login page.
5) You kindly provide your bank credentials to the bad guy through your encrypted SSH tunnel.
Many Java and Flash applications initiate their own network connections — meaning they would not use the Socks proxy — leaving their conversations open to attack as well.
In an IPSec tunnel, all traffic — including DNS lookups — are routed through the tunnel to the remote network, making them immune to this attack.
One last rant, then I will step down from my soap box. TCP-based VPNs, such as SSH or SSL, are susceptible to tcpkill attacks, whereby an attacker send s TCP Reset packets to each end, tearing down the tunnel. (The very same shenanigans that many ISPs use to throttle bittorrent sessions.) Since your email client has no knowledge of the state of your VPN connection, an attacker can tear down your tunnel and wait for the next POP3 or IMAP check interval, then snag your username and password from the unencrypted hostile network. IPSec tunnels, which typically use UDP, are immune to this type of attack.
Thanks as always for a fantastic podcast.