Bomb #1

My cur­rent class assign­ment con­sists of reverse engi­neer­ing a piece of code writ­ten by the pro­fes­sor. Basi­cally the pro­gram reads in one line from STDIN at a time and checks to see if it’s the right phrase. If it is, that bomb is defused and it con­tin­ues to the next one. If the phrase is incor­rect that the bomb blows up and I’ll have to try again.

Below is my method­ol­ogy for Phase 1.

** Note that as a stu­dent we were given access to the source code of the “shell” pro­gram that calls the other func­tions that actu­ally do the com­pare. So I know that the func­tions are called phase_1() through phase_6(). The func­tion names could also be guessed by using obj­dump –t bomb.exe and look­ing at the func­tion names.

** Also, solutions.txt con­tains a sin­gle line with con­tent: test­ing

$ gdb bomb
(gdb) b phase_1
(gdb) dis­play /i $pc
(gdb) r solutions.txt

That runs the pro­gram until the break­point is hit. Once it’s hit I run disas to dis­play the assem­bly of the cur­rent func­tion. I notice that there is a call to strings_not_equal and fig­ure that the two val­ues pushed onto %esp are likely the argu­ments, and based on the func­tions name, are likely strings. I then use dis­play /a $eax to take a look at the address con­tained in %eax. Finally, I use x /s 0x405040 and x /s 0x404140 to look at the strings located at those addresses. One is the string I passed in, and the other is the win­ing string. I change my solutions.txt file to have the new string in it and test it to val­i­date. It works! Bomb 1 defused!

Bomb - Phase 1

PGP Whole Disk Encryption — Authentication Bypass

There has recently been some atten­tion to a bypass fea­ture in PGP Cor­po­ra­tion’s Whole Disk Encryp­tion prod­uct line. The gist of it seems to be that it is pos­si­ble for an encrypted vol­ume to be set so that the passphrase require­ment is waived (bypass­ing the authen­ti­ca­tion) for a sin­gle reboot.

While this comes across as con­cern­ing at first, after read­ing the PGP Knowl­edge­base Arti­cle #750, it appears that the risk is min­i­mal. I feel that if I were a gov­ern­ment orga­ni­za­tion, such as the CIA,NSA,FBI, DHS, etc, then I’d be wor­ried about the types of advi­sories the anony­mous author of securol­ogy men­tions. How­ever, most lap­top thefts are by com­mon crim­i­nals look­ing to make some money in a pawn shop or oth­er­wise. I doubt there will be many if any cases of a mali­cious tro­jan that not only replaces PGPs Boot­guard with a mali­cious one to extend the num­ber of unau­then­ti­cated bypasses ad infini­tum, but also infects machines that the attacker can get phys­i­cal access to. This would require being able to reverse engi­neer the PGP Boot­Guard code that so far even the fine folks over at Guid­ance Soft­ware haven’t been able to do.

As part of risk man­age­ment, there is a cer­tain level of risk that has to be accepted. We can not live in a world with­out risks and should only worry about the ones that have a rea­son­able chance of occurring.

The post­ing lists 4 points that he/she would like addressed.

  1. The fea­ture was doc­u­mented clearly, includ­ing a secu­rity warn­ing cov­er­ing the risks of its use/presence in such a way that admin­is­tra­tors must see it.
  2. The fea­ture could be per­ma­nently dis­abled– not just ignored or left seem­ingly unused.
  3. The intended use of the fea­ture did not require the cre­ation of a passphrase with cryp­to­graphic access to the Vol­ume Mas­ter Key.
  4. The intended use of the fea­ture did not require the dis­tri­b­u­tion of plain text scripts with an embed­ded passphrase to N clients each and every time that fea­ture is needed.

The first point I absolutely agree with. How­ever, it’s worth men­tion­ing that PGP doc­u­mented this fea­ture back on July 27th of 2007. I would like to see the secu­rity warn­ing though, as I per­son­ally had no knowl­edge of this fea­ture until I went look­ing for it. Could PGP have back­dated the doc­u­ment? Of course, but I’m hop­ing the com­pany mak­ing my encryp­tion solu­tion isn’t that shady.

PGP Bypass Document

The sec­ond point seems aca­d­e­mic in nature to me. There are plenty of pro­grams used in every com­pany of every nation that have fea­tures which would be inse­cure. For instance, Microsoft Active Direc­tory can allow user accounts to have blank pass­words. Shouldn’t we be sat­is­fied that in our envi­ron­ment the fea­ture is dis­abled? Demand­ing that Microsoft remove the fea­ture from the code base sim­ply because it would be unfa­vor­able if enabled is ridicu­lous. I feel like that’s what’s being demand­ing of PGP here. It might be a risk a 3 Let­ter Agency should worry about, but cer­tainly not your typ­i­cal business.

For the third point I’m inter­ested to see what his pro­posed solu­tion is that doesn’t allow cryp­to­graphic access to the Vol­ume Mas­ter Key. I may be mis­in­formed but I’d think that with­out access to the VMK the lap­top wouldn’t be able to decrypt any­thing and thus it would be impos­si­ble to boot.

I com­pletely agree with this fourth point. I’ve always been against devel­op­ers hard cod­ing pass­words into bina­ries, and espe­cially into plain text script files. PGP should allow an alter­nate form of authen­ti­ca­tion that doesn’t require dis­play­ing the pass­word. I have some thoughts on this but will likely post them later.

Over­all though I’m very impressed with the writ­ing style and depth of thought that the author behind Securol­ogy has shown. I plan to keep read­ing and keep learning.

Customizing bash and vim

Post­ing here for my ref­er­ence the next time I need to con­fig­ure my prompt and vim. I cur­rently do all of my school­work on a CLI only linux box and even though I don’t need a GUI, I do enjoy some color dur­ing my ses­sions. The prompt and vim con­fig pro­vide just that. If you’d like to make your own prompt sim­ply replace the quoted char­ac­ters of PS1 with what you would like using this and this as ref­er­ences.

[email protected]: [~]: uname –a
Linux suse 2.6.18.8–0.5-default #1 SMP Fri Jun 22 12:17:53 UTC 2007 i686 athlon i386 GNU/Linux
[email protected]: [~]: tail –n 2 .bashrc
alias ls=‘ls –color’
export PS1=”\[\033[1;33m\]\u\[\033[0m\]@\h: \[\033[36m\][\w]:\[\033[0m\] “
[email protected]: [~]:

This is a fan­tas­tic .vimrc posted by some­one that knows more about vim con­fig­u­ra­tion than I care to. The main thing I enjoy is the fixed back­space key (it actu­ally works), the col­or­ing, and the 4 spaces inserted for a TAB. I also very much appre­ci­ate that the file is thor­oughly com­mented so that any­one who wants to understand/modify it can. I for instance changed his set­ting of 2 spaces per TAB to 4 spaces per TAB. Thanks for the great infor­ma­tion Stripey!