Mittwoch, 23. April 2014

Heartbleed revisited

So, now the Heartbleed Bug is some days old and the work is nearly done.

So letst talk a bit about the history.
  1. on Sun, 1 Jan 2012 00:59:57 +0200 somebody committed an heartbeat extension to the openssl git repository.
  2. on last sunday/monday google found a bug within these extension, or at least finally reported about the bug.
  3. On late monday and early tuesday we had a tiny little website which could identify if your server is affected by these bug
  4. Some hours later a golang code was available , so we can check even more systems
  5. Finally a nmap plugin was available, and now we can scan the full ip range and every port
  6. Most SSL ca's were unable to handle the re-certification (or re-signing) of the certs via api, a solution was available on early thursday.
So what have we done within these lovely days (and what you should have done too)?
  1. We started to close the ssl vulnerability by patching all our systems
  2. We recreated our private ssl keys and recertificated these
  3. We started to call the Bug "Fingerbleed"-Bug
  4. We exchanged all of our certs
  5. We talked to some customers and helped them identify the bug and provided solutions
  6. We changed all our passwords

So finally i guess we can say it with Atkins lyrics

If you're goin' through hell keep on going
Don't slow down, if you're scared don't show it
You might get out before the devil even knows you're there

Mittwoch, 9. April 2014

Yet Another Heartbleed post

Well, as i spended hours on the heartbleed bug currently, i just need to tell you this:

Update your openssl libary now!

I guess the bug could be one of the most urgent bugs we had.

What you should do:

And dont forget to restart your apache/nginx/lighttpd/postfix/whatever server. 

As i normally maintain a higher range of ip addresses i just wrote a short script

Step 1: fping -g IPRANGE > ips.txt
Step2:  sh > test.txt 
for line in `cat ips.txt | cut -d ' ' -f1`
        ./heartbleeder $line:443
Step 3: login to the server and solve the issue

have fun!

Donnerstag, 3. April 2014

[Note to myself] Raspberry PI, playing around (Android, Chromeos)

So, now i have my raspberry pi for more than a week. I am still looking for something "awesome" to do with it. There are two operating systems which i really would like to us on it.
  • Chrome OS
  • Android
Well, as Android is normally build to run on ARM systems i thought it should be the first try. Sad enough the first try yesterday failed, and i still dont know why. The screen just stays black and the light on my raspi stay red. 

So, this blog post is mainly a "Note to myself" so i can find all the links again :-) Maybe some of you find it useful too 


So, so its a mix of link (1) and link (2). 
While doing all teh needed chroot stuff you can easily see that its a gentoo underneath, well okay, i can live with that. The compilation for the cross compiler takes a while.  Okay, actually everything takes a while.


Some useful links which i might need again
Well i tried the mentioned version, but it failed, it does not even boot with only a black screen. So i played around a bit more and took the kernel from my pidora SD card. So the kernel boots but goes into an endless boot loop.
As i know now, there are a lot of prerequisites you need for the Android Kernel, so the pidora kernel is just to "small". Well, i will try to compile it on my own. But without an working config to import it will be the hell of a work.
While i am writing my Blog entry, broadcom has given the source for acceleration drivers to the community and someone already solved the Quake II Quest and ported it
So, whats next?

Conclusion, as everything seems to be strange i guess best idea would be to take the pidora build (or maybe something smaller, we will see) and add the new dma driver (see broadcom link in Android) and build an own system. 

I think about something which includes
  • chrome
  • fvwm
Okay, so that's my link list,