If It Runs OpenBSD, It Has To Be Important

If we are starting to see targeted attacks on OpenBSD systems, the world has become more interesting.

A lazy Sunday turned a tad more interesting when Dragos Rui, a person usually involved in high-quality security work (or somebody with access to his twitter account) tweeted this:

Analysis of recently deleted data on compromised server has turned up an OpenBSD boot sector trojan worm? Volunteer deconstuctors?

There have been no further updates as of this writing, and without access to the actual files in question, we can not offer any real meat on the actual payload, so any preliminary conclusions will be uncertain at best. But it is possible to come up with a threat assessment based on general knowledge of what it would take for a boot sector based OpenBSD exploit to make it into the wild.

OpenBSD is used in a wide range of environments (see the OpenBSD at work page for some examples, the list is by no means exhaustive), and since it is commonly perceived to be one of the most secure general-purpose operating systems available, it should be no surprise to find OpenBSD systems in mission critical roles.

So the motive for trying to forge a way in, past a system that is generally considered trustworthy, is obvious. If you hit the right targets, the potential payoff could be huge.

Then it becomes interesting to consider how you would go about to compromise a system running OpenBSD. If we leave aside social engineering such as bribing the sysadmin or stealing the passwords database for the moment, the traditional, and obvious, way to compromise a system is to find an exploitable, unpatched bug and use that to take control of the system.

The OpenBSD source tree is available to the world (in fact, OpenBSD was the first project to make its CVS repository available via anonymous read-only CVS), but writable only by small group of developers. The developers tend to concentrate on the in-development -current, but they do produce a small number of patches to the released version that become available via the patches page. If you want to study the OpenBSD development process more closely, there are a number of good articles and presentationas available via this page, but the important message is that insisting on code correctness and continuous code audits have yielded quite solid results. Exploiting any bugs you would be lucky enough to find in OpenBSD is harder than elsewhere.

But apart from patches to -stable, OpenBSD users usually do not update their systems by recompiling source. Neither do we usually run automatic system upgrades via an upgrade service. For packages, $ sudo pkg_add -u (assuming your PKG_PATH is set to something sensible) provides binary upgrades. For base system upgrades (the only time the boot sector code is likely to be updated), we tend to run the installer in upgrade mode and point it to a set of known good file sets. If the installer finds that a file set does not match the expected SHA256 checksum, it will warn you in no uncertain terms. The same messages will turn up if you, like me, tend to install snapshots on at least some systems as they become available, but sometimes forget to copy the correct bsd.rd into the right place.

The lesson here is that to taint an OpenBSD system, your most likely way in would be to replace a full set of installation files on your likely target's usual mirror, complete with checksums that makes the installer report your modified file sets as genuine. This has two obvious implications: one, you should never install anything on a mission critical system unless you find identical files on several different mirrors, and you should make sure that checksums from one mirror match the files on another. Watching the errata page for the release you are running is a good idea, too, of course.

This gives the proper context to the suspected exploit Dragos reported. The suspect still has some interesting properties. The boot sector code is very small and any changes would be relatively easy to spot once the system is running, but the code there runs early in the boot process and is there mainly to fetch other code that makes sure the system boots. The only useful modification here for an attacker would be to modify the boot loader code to load something that replaces the OpenBSD kernel and performs actions whatever the attacker wants.

The result of modifying the early stage boot code would more than likely be a trashed system unable to boot, but an appropriately skilled attacker who managed to insert code in the right places might be able to pass off a subtly modified system as a genuine one and keep it running for long enough to matter. That's why it will be very interesting to hear whatever real information becomes available about this suspected OpenBSD-targeting attempt.

If we are starting to see attack attempts specifically targeting OpenBSD systems, it could be an indication that at least some criminals have achieved a level of skill, or at least reached a new level of ambition. I have a strong feeling that the OpenBSD developers' efforts have paid off and creating a workable exploit will be very hard, but in the meantime, now is not the time to be slacking, even if all your critical system run OpenBSD. But you have a head start.

---

If you are curious about the status of the The Book of PF, second edition, preorders have started, and a PDF version is available right away. Physical copies will start shipping as soon as they exist, likely around November 10th. (Update 2015-03-05: For fresh reading material on PF, you're better of with the newer Book of PF, third edition, which became available in late 2014.)