My journey to astrophotography (part 1)

Astrophotography is an awesome passion that’s a mix of science, technology, history, art and dedication. I’m writing this post to share on my journey, not as a way to teach you anything about astronomy, but to offer a window in my life and also show that it’s possible to get started from zero in a new hobby, provided you invest some time into it.

Three years ago, I wrote a blog post on the reasons why I left my job and was pursuing something better suited to my mindset and where healing some wounds wound be possible. I removed it because a person I’d rather not have read it did (if you think it’s you, please return my calls). One or two years before, I started to notice that not only my job had eaten my hobby, but I was less and less interested in computer security and hacking in general – as doing 2 or 3 hours of hacking at home after having spent the day on a pentest was simply not something I enjoyed anymore. It was time for me to be passionate in something else that didn’t involve reading social media for hours (which is unfortunately one of my other hobbies). Maybe go back to something I always loved without taking the time to explore it, partially because I thought that was out of reach or because I should spend all my time trying to be the best hacker in the world (that didn’t work). A few people may know that I was using the handle “spacewalker” until the mid-2000, it didn’t come out of nowhere but from my fascination for the night sky and poor science-fiction cultural references.

Continue reading “My journey to astrophotography (part 1)”

SSH: Best practices

The comments around the last OpenSSH issue (CVE 2016-0777, you must read excellent Qualys’ analysis if you’re interested with the details), I noticed that many people were not aware of some basic features of OpenSSH. I will attempt to give a few advises, prioritized in feasibility order, and with graphical annotations:

Very easy to set up.

Requires a lot of work to set up.

Will provide you some protections against difficult attacks.

Will protect against very simple or effective attacks.

Continue reading “SSH: Best practices”

TrendMicro CTF 2015 : Poison Ivy (Defense 300) write-up

TrendMicro CTF logo

The challenge

This challenge was one of the 25 (minus a few canceled ones) written and organized by TrendMicro for their TMCTF 2015. I played with the Swiss team “On est pas contents” and I won’t disclose how badly we ranked 🙂 Some challenges were really boring (a crossword where half the solutions come from the commercial product aisle? Not for me). Some were frustrating, and one was really great: Poison Ivy network capture.

TrendMicro was very fast in shutting down the whole CTF website, so I can’t get an hand on the original challenge text. From memory:

A hacker was caught using Poison Ivy on a real system. Please understand what he was doing to get the flag. (ps: password is admin).

With that exciting information I start downloading the pcap. Opening in wireshark, it appears it’s a single TCP connection on the 443 port. This doesn’t look like https and the wireshark dissector doesn’t want to parse it. Right click on a packet, “Decode as…” and check “do not decode” makes us see the raw exchange.

tmctf_wireshark1

Continue reading “TrendMicro CTF 2015 : Poison Ivy (Defense 300) write-up”

OpenSSL and LibreSSL PRNG, what’s different?

openbsdhelpusIn July, a blog post from Andrew Ayer described the new, unsafe behaviour of portable LibreSSL 2.0.1. While it is right to say that it’s unsafe, it is still safer than baseline’s OpenSSL and portable LibreSSL 2.0.2. That’s what I’ll explain in this blog post.

OpenSSL

During March 2014, I released two CVE on OpenSSL consumers, stunnel (CVE-2014-0016) and libssh (CVE-2014-0017). I also wrote a paper about it in the french magazine MISC mag 74. Unfortunately the paper is in french and not yet released in CC-BY-NC, so here are the major points:

  • OpenSSL RAND_bytes() pool can be shared by two processes that are related, e.g. with a fork().
  • OpenSSL mitigates that problem by adding the result of getpid() in the entropy pool during a RAND_bytes() call. That means that two processes that share the same entropy pool and end up with the same PID will generate the same pseudorandom numbers.
  • That’s what happens in stunnel in fork mode: a master process initializes the entropy pool and spawns children. As children die, PID are recycled until a PID is reused and starts generating the same sequences of pseudorandom numbers.
  • Hopefuly OpenSSL uses RAND_seed() with the current unix time (time(NULL)) on every SSL handshake, so there’s only a one-second time spot to exploit that weakness, before having to start from scratch again. OSes with sequential PID generation are then less vulnerable than OSes with random PID (AFAIK only OpenBSD). This is because open OpenBSD it’s likely to have two different children have the same PID reused in the same second.
  • In the end, the exploit I wrote for it didn’t work, because the OpenSSL ECDSA_sign() function calls RAND_seed() with the content of the message to be signed, and the secret number k is different every time, mitigating the exploit:

Continue reading “OpenSSL and LibreSSL PRNG, what’s different?”