Friday, December 19, 2014

Now that we officially know that 3G can be broken and thatit makes sense to place particular (passive) hardware on theroof top of embassies (the cellar is already stuffed withtorture equipment and you have better gain at the roof),my threat analysis here was correct. In particular thelast paragraph should be repeated, as you can start sendingyour QI before the victim packet is even close to thetarget if you just captured the SYN packet on air.As a bonus, you dont need to deploy evil hardware in thetarget network.Nevermind, I am not going to torture you with more threatanalysis posts. There are enough of them. :)

Thursday, October 30, 2014

Not just because they are ugly but also because lophttpdnever was affected by POODLE, since SSLv3 wasdisabled for a reason in favor of TLSv1. I think about droppingTLSv1 too and just allowing TLSv1.1+ in future.To my knowledge lophttpd is also the first webserverutilizing Linux seccomp sandbox.I also added SO_REUSEPORT support today, since Googletold us that when handling c10k, their processesare un-evenly distributed across the cores (what the hellare they doing there?)lophttpd wins again, since even without SO_REUSEPORT,such problem never existed for you:

which shows running it on 4 cores, handling c10k. Couldthere be a smaller footprint?Update:After carefully reading the commit for the Linux kernelthat introducedSO_REUSEPORT, I came to the conclusion thatfor Linux there was an entirely different reason to introduceit than there was for 4.4BSD at the time. According to thegit commit message, uneven distribution among the coresonly happen when the "number of listener sockets bound to aport changes (new ones are added, or old ones closed)".So its clear that it never affected lophttpd and it "leaks"interesting info about the architecture of the googlewebserver, why it had such problems before the patchand which kernel they are using. OSINT for the win.(Such architecture where new listeners are created or removeddo not make much sense to me anyway, so there are somequestions left.)So in theory, I could remove SO_REUSEPORT again but I willleave it as is for now, in case more webserver instancesare started later. Note that it doesn't make sense to havemore lophttpds running than there are cores onyour machine. I do not support hyperthreading yet, so-n 0 is what you want, if you have such heavy load at all.

sshttp btw also uses the same multi/single-thread architecturewithout SO_REUSEPORT (yet).

Monday, October 13, 2014

So you are safe, because you updated your bash, run your policy in enforcing mode, enabled NX and ASLR and boot using a cryptographically signed shim bootloader.Well, you actually failed by the first step.Here is why:

Even if thats hard to believe, but there might beremotely exploitable buffer overflows in your securebootloader. The 90's party of today just happendownstairs. Bootloaders make use of UEFI network stacksto implement PXE and PXEv6 and sometimes fail to do so:

The issue however is not so severe because a lot of UEFIfirmwares fail to verify what they get via PXEv6 anyway,sodelivering an overflow payload is overkill. :)Thats actually why you see 'schlimm' debug output insecure mode in the PoC demo screenshot at all.

There were some twists necesarry to actually achieve *ptr = valueas seen above, mainly due to protocol specifics. If you are interested, we can discuss this privately.

Thursday, August 7, 2014

I updated some of my github stuff recently.First, I added SNI support to lophttpd for better supportingvirtual hosting with TLS. Its straight forward to use. Pleaserefer to the updated README.Next, I pushed my POSIX realtime AIO implementation forLinux to github. The glibc aio implementation is creatingan own thread for each aio_read/write that you submit,not utilizing the kernels io_ syscalls. Clearly, for a large number of AIO contexts this performs badly to not at all.I am using the io_ syscalls and an event-fd to getnotified about operations that became ready. I alsomade sure that it works on Android. :p

Monday, July 7, 2014

Lets have a look on how our traffic is XKey-scored and whetherits done with efficiency.The XKS source seems to be some kind of mangled-C++, just likea lot of C/C++-based languages exist for big/paralleldata processing (CUDA or other parallelizing extensions).Given that, DB is obviously some kind of nested std::map or apparently of a derived type, as can be seen by the apply()member which is not part of a STL map.Its probably not a multimap either, as denoted by the clear()and in that [][] assignments are not possible with multimaps [1].These types (as well as a multimap) are sorted associativecontainers (dictionaries) who's lookup complexity is guaranteedto be O(log(N)) at worst [2], where N denotes the numberof keys in the map. DB has at least 3 keys as seen from the snippet, but chances are that the number is much larger.Thelarger it is, the more need is for optimizing the map access.I doubt that XKS has their own implementation of dictionariesthat have a better O() and are optimized in a way thatDB["tor_onion_survey"]["onion_count"]access could be O(1). After all (look at the boost include), itlooks pretty much like STL-C++ code.Given that, inside a loop the following XKS code is ratherinefficient:

coder out there.Edit: Meanwhile I found another reason to avoid operator[]for assignments in a row inside one of Scott Meyers excellentbooks on C++ effectiveness [3] which I really recommend readingto any XKS developers (there are also classes for it).

[1] The clear() is important for our later optimization, asinsert() has the same semantics like operator[] assignment only if the key doesn't already exist - otherwise the assignment-step after finding the key won't happen with insert().

Thursday, May 22, 2014

(SIGILL//FVPNS//NOPORN//FORNFCK//MRKLBANG)I made quantum-dns available in my github.Its simple to use (non-recursive) DNS server forIPv4 and IPv6 and also works without having anIP address assigned to the interface (i.e. it cananswer any DNS query).Similar to my writeup on QUANTUMINSERT it also containsa demo FoxAcid script for HTTP. Theoretically it'd also quite easy to make STARTTLS disappear with quantum-dns if its notenforced on the sender side. While with QUANTUMINSERTyou need to see the TCP sequence# and port, with DNS youneed the XID and port, so it makes entirely sense tohave good passive capabilities for e.g. 3G/4G.A monitor port on a large peering point is enough capability though.Thats a sample run from my lab (please forgive me :)

And yes thats trivially to implement, but so isQUANTUMINSERT which is so easy that I never considered itan attacking scenario either. It was fun to code thoughto get hands on DNS again. For DNSSEC support, you needto purchase special license. :)

Friday, May 16, 2014

After cleaning up the sources a bit and makingsure it compiles on current Linux distros, I uploadedmy old IPv4/IPv6 load balancer to my github.I started this project in 2004, back in the daysat university. 10 years ago, it was the first load balancer available for IPv6 and in 2006 I finally presented the project atsome balancing conference in Silicon Valley.(Even though you see some other names of my CS departmentthere, the whole code is written by me. In academics howeveryou form research groups and you are not going to rockthe world single-core.)It works on IP level, so its suitable to balanceSSL/VPN/tor traffic etc too. For IPv4 it has integratedfailover/hotplug support for the backend nodes.

Thursday, March 27, 2014

Fixed a bug in enabler which is part of pam_schroedingerthat made it exit() when no more pty's could be allocated.That's wrong of course, we just need to continue dictumerating(enumerating via dictionary) the account. 500 parallelsu/sudo are of no problem.enabler allows you to mount dictionary attacks using su,sudo, passwd or alike. You can stop this by usingpam_schroedinger, or something like introducing anenforced RLIMIT_PTY and having su, sudo etc. callisatty(0), otherwise socketpairs etc could be used too.I also went ahead, signing my github stuff withthis key. Any release tag containing an s at the endof the version is a signed tag. Also, all commits willbe signed in future.You can verify this via git log --show-signature orgit tag --verify TAG after having above DSA keyimported into your gpg keyring.

Friday, March 7, 2014

I recently imported crash into my github. It featuresIP6-ready SSH-like remote shell, using strong public keyauthentication and TLS-encrypted transport. It does notrely on SSL/TLS internal X509 cecking but compareshostkeys bit-wise. It runs on Linux and embedded derivates,Android, BSD, Solaris and OSX/Darwin. It does not require rootand has back-connect and trigger modes built in. It canalso be invoked as a CGI.Update: Pushed a fix into git to use SHA512 rather thanSHA1 for signing authentication requests. That makesit incompatible with earlier versions. Also fixed a bugwhere crashc did not properly distribute SIGWINCH to theremote peer. Now you can use your ncurses porn and resizeyour xterm and it gets properly adjusted! Also testedauthentication RSA keys of up to 7500 bit in size. Thatshould resist upcoming (TS//SI//REL) QUANTUMFUCK computers.I need to find the time to enforce cipher-lists and addephemeral keying though. (done)Also good news: crash also integrates with sshttp!

Friday, February 28, 2014

I ported lophttpd to OSX/Darwin (10.8 tested).As OSX/Darwin is almost POSIX-compliant (live_free() || die())and I already separated the low-level stuff to the -flavorfiles, this was not overly complicated.Now it pays that I chose to do it that way, rather thanhaving a dozen of #ifdef stacked around.lophttpd now cleanly builds on BSD (untested for some time),Linux, Android and OSX/Darwin.What nerves most is the various integer-size issues youhave with size_t, off_t, suseconds_t etc. and the correspondingformat specifiers with the *printf() family. However you do it,one OS shouts at you for passing wrong sized parameters to*printf(). Despite of any standards. Live free or die.You can easily build it on OSX/Darwin by installing Xcodeand then installing its command-line tools. Thats notgcc AFAIS, but it should also build if you manage to installgcc toolchain there.I had to disable warnings about deprecated use of OpenSSLin OSX and I have hard times not commenting on that in lightof gotofail.Live free and die. :)

Thursday, January 16, 2014

I've been experimenting with mass DNS resolving lately.Imagine you have some large list of DNS names (FQDN's)which you want to map to its IPv4 or IPv6 address.That could be a GB sized zone-file or an enumerated list ofnames for some double-flux network when you researchhow you can take down a botnet. In either way, sometimesyou need to do that in finite time and clearlygethostbyname() in a loop is not the way to go!For asynchronous resolving the glibc already hasgetaddrinfo_a() but it turns out that this function isentirely useless because its using threads. So, forevery request you send, a thread is cloned() which doesnot scale well. [The glibcaio_ functions also use threads,its a pitty that glibc async support is so toast!]So I hacked up something from scratch that works for me.Its on my github. The output resembles that from digand from the zone files you know.The problem is to find right parameters for the amountof requests to send in a row and the amount of usecs youwant to usleep before doing that again. Otherwise you willjust hammer the DNS server and gain no response. The defaultvalues are sane enough that it yields some good result.The better your uplink to your recursive DNS, thesmaller amount of time you need to usleep().You can also distribute the requests across multiple DNSservers by using more than one -N switch. The more reliableDNS servers you have, the better because you do not runin any rate limiting.