Padding Oracle Attack PoC in C

I'm a newbie on crypto field. *Unfortunately*, I need to deal with some
open source security stuff( openssl and gnutls) in my day job. Yes,
don't be so sad for me;-) I can handle it so far. I need to know more
knowledge about crypto. The best way to do it is writing xxx-attack
PoC. Then I've heard of Lucky-13 is something. Backport these patches
from upstream drives me crazy. Dude, you known~ 13 openssl upstream
commits( more than 1,700 loc modifies) were only for fix one security
issue what called Lucky-13 Thirteen which was disclosured in Feb 2013. It
was my honor to do this shitload work with very very low salary;-)
After I finished it, a very serious question came out of my mind: What
if another tens of shitload work pop up in the future but with no help
from the upstream community? Well...I have to eat the rocket by my own
hands. F0r preparing to handle such situation, I need to know the
detail of the attack. That's why I wrote the padding oracle attack
PoC( Download here).

I googled "padding oracle attack". I found 3 guys wrote their own
padding oracle attack PoC/tools in 3 differnt languages: perl, ruby
and python. I looked their code and articles. They guys are awesome!

Brian Holyfield( Perl guy) wrote this very good article and more
importantly it's easy to understand:
 
http://blog.gdssecurity.com/labs/2010/9/14/automated-padding-oracle-attacks-with-padbuster.html

Daoge( python one) is a CHiense hacker who are good at web
security:
http://hi.baidu.com/aullik5/item/49ab45de982a67db251f40f6

Ron Bowes( Ruby guy) gave us a great presentation at Shmoocon 2013. I
really thank his practical advice. He wrote two articles about padding
oracle attack. The 1st one introduce the principle and the 2nd is
giving an great example.

http://www.skullsecurity.org/blog/2013/padding-oracle-attacks-in-depth

http://www.skullsecurity.org/blog/2013/a-padding-oracle-example


Well, I'm a kind of old school guy. I decided write it in
C( not old enough as asm). This example is simple:

shawn@shawn-fortress /arsenal-4-sec-testing/libcrypto/lucky-what $ make
gcc -g -o padding_oracle_attack_poc padding_oracle_attack_poc.c -lcrypto
done
shawn@shawn-fortress /arsenal-4-sec-testing/libcrypto/lucky-what $ ./padding_oracle_attack_poc 
Ciphertext is 16 bytes: 83e10d51e6d122ca3faf089c7a924a7b
Decrypting now
205 is done: 00000000000000ce3faf089c7a924a7b
36 is done: 00000000000025cd3faf089c7a924a7b
214 is done: 0000000000d724cc3faf089c7a924a7b
230 is done: 00000000e7d023cb3faf089c7a924a7b
80 is done: 00000051e6d122ca3faf089c7a924a7b
110 is done: 00006f52e5d221c93faf089c7a924a7b
137 is done: 008a6e53e4d320c83faf089c7a924a7b
248 is done: f985615cebdc2fc73faf089c7a924a7b
The original plaintext is: "Hello World"
The one last block of plaintext: 726c6405050505050000000000000000
----> rld

btw: Thanks to Thomas Biege again..who is guiding me in not only one sec field... 

How to enable SELinux in SLES 11 SP2

I've been playing with SELinux for a few days. Once you decide to hack on SELinux, which means a very long hacking journey is begin. The 1st shit you need to do is to enable the SELinux before you dive into the details. Yes, you may already knew these great stuff could help your great SELinux hacking journey:

1, SELinux project wiki
2, The SELinux Notebook - The Foundations - 3rd Edition

The SELinux kernel module has already compiled in SUSE Linux Enterprise Server 11 SP2 but without any specific polices. OK then, I've bullshit a lot, haven't I? Please allow me bullshit a lot more;-)

Firstly, make sure SELS 11 SP2 is working well:
--------------------------------------------------------------------------------
shawn-fortress:~ # cat /etc/issue

Welcome to SUSE Linux Enterprise Server 11 SP2  (i586) - Kernel \r (\l).
-------------------------------------------------------------------------------- 

Install these packages which are needed for SELinux:
--------------------------------------------------------------------------------
zypper in libselinux1 checkpolicy libsemanage1 policycoreutils
--------------------------------------------------------------------------------


Type "yast2 bootloader" in cmdline and add:
-------------------------------------------------------------------------------- 
"security=selinux selinux=1 enforcing=0" into the kernel cmdline
--------------------------------------------------------------------------------
 In GRUB bootloader, these above 3 options are used related to SELinux.
 * security=selinux, tells the kernel to use SELinux and not AppArmor
 * selinux=1, switches on SELinux
 * enforcing=0, puts SELinux in permissive mode( only logging)


Install selinux-tools, choose "SUSE SLE-11 SP2", then "1 Click Install":
--------------------------------------------------------------------------------
http://software.opensuse.org/package/selinux-tools
--------------------------------------------------------------------------------

Install selinux-policy, choose "SUSE SLE-11 SP2", then "1 Click Install":
--------------------------------------------------------------------------------
http://software.opensuse.org/package/selinux-policy
--------------------------------------------------------------------------------

Add  selinux to existing PAM config file:
--------------------------------------------------------------------------------
pam-config -a --selinux
--------------------------------------------------------------------------------

set restorecond service to runlevel 3 in "expert mode":
--------------------------------------------------------------------------------
yast2 runlevel
--------------------------------------------------------------------------------

Finally, reboot your computer/laptop/s*!@#...... and check the SELinux status:

shawn-fortress:~ # sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 26
Policy from config file:        refpolicy-standard

See, it's working!

Thanks to Thomas Biege who is guiding me on this journey! Thomas's article "SELinux on openSUSE 11.1" helped me to understand the config of SELinux in big picture.

May L0rd's hacking spirit guide us!

Vuln assessment for PALADIN forensic tools free version

I went to the China Mac Forensic Conference last week. This was my 1st time I attended a security con about forensic. Some of security guys gave us a few free speech and it's all about forensic. In forenisc field, the only stuff I've know its Lynis which was written by Michael Boelen. They were talking about forensic stuff on Mac/iOS platforms in the morning. That made me a little boring. But what else can I blame about? This conference is called Mac-Forensic*. Fortunately, I found something very interesting at the afternoon. A company named SUMURI providing a forensic solution which based on GNU/Linux. This GNU/Linux distro is called "PALADIN". I got a free Live-DVD and booted it up in scene. Well, I was fuc* exicting because I got tens of shitloads of information about Mac/iOS in that day. Now I had something I'm familiar with: GNU/Linux. I found some potential risks for PALADIN GNU/Linux distro. I've already notified them. Hope they could spend more time on sec stuff.

OK. When PALADIN booted up, you can see the ubuntu-like( Unity?) GUI:

PALADIN provides a lot of open source forensic tools:

In the free version, the only closed-tool is "PALADIN Toolbox" which can be found in the Desktop and the binary file is located in /usr/bin/toolbox. This binary is using many free/open source libraries. The 1st potential issue is violation of free/open source licenses. Then I asked Steve Whalen "are you sure that toolbox has no violation of the free/open source licenses" in the scene. His answer is pretty sure that the toolbox won't be violated any free/open source licenses:

Then, I took a few mins to investigation on the binary. Firstly, the entry address:

And, it doesn't have any anti-debugging features( my examples) in it. If your asset is a closed-source binary. You should do anti-debug. A skilled reverse engineer is able to find the security issue by reversing the binary in very *short* time:

ASLR is turned on. "2" is very good, which means the kernel do the randomize for stack and heap separately. AFAIK, the issue is the ASLR only work with PIE.

Lucky Thirteen Attack is a big issue recently. The current openssl version is affected.

Well, this is it. I've done the investigation when a guy told me it's time to smb break. I'm very happy to see the company like SUMURI brings GNU/Linux into the forensic field.