SOLDIERX.COM Nobody Can Stop Information Insemination

Over the past year, HardenedBSD has been hard at work in integrating the Cross-DSO CFI implementation in llvm. We have reached a point where we can release an early (pre-alpha) public Call For Testing (CFT) of this work.

For reasons which will be described below, we recommend this CFT be used by those using root-on-ZFS with boot environments. We recommend testing in a dedicated boot environment.

This initial round of testing is best suited for development server installations. Production servers and desktops/laptops are not advised for testing at this time. We're looking for feedback on what works and doesn't work.

Introduction

Control Flow Integrity, or CFI, is an exploit mitigation that aims to make it harder for an attacker to hijack the control flow of an executable image. llvm's CFI implementation provides forward-edge protection, meaning it protects call sites and non-return code branches. llvm includes basic and incomplete backward-edge protection via SafeStack.

CFI in llvm consists of two flavors:

1. Non-Cross-DSO CFI
2. Cross-DSO CFI

For over a year now, HardenedBSD has adopted non-Cross-DSO CFI in 12-CURRENT/amd64. Support for non-Cross-DSO CFI was added for 12-CURRENT/arm64 on 01 July 2018. Non-Cross-DSO CFI applies CFI to the applications themselves, but not on the shared objects they depend on. Cross-DSO CFI applies CFI to both applications and shared objects, enforcing CFI across shared object boundaries.

When an application or shared object is compiled, its source files typically get compiled first to intermediate object files. Enabling Cross-DSO CFI requires compiling and linking both static and shared libraries with Link Time Optimization (LTO). When LTO is enabled, these object files are no longer ELF object files, but rather LLVM IR bitcode object files.

As usual, many of the crew members of soldierx.com will be at Defcon 26. Blake has also informed me that the chat software (for anonymous conversations) that is heavily used by folks at Defcon is feature complete. There's more information about this at https://en.wikipedia.org/wiki/Mojave_phone_booth. I would like to point out that the Mojave Phone Booth is in no way ran by soldierx.com despite some of the rumors online. The only relationship is that one of our crew members, Blake, wrote the software that powers the SMS and Signal portions of it. If you want to join it, please send SUBSCRIBE <ALIAS> to 760-733-9969 via SMS or Signal. <ALIAS> should be replaced with your desired alias.

If you're going to Defcon 26 and you'd like to meet up with members of soldierx.com, please follow this. You can also track us down in IRC and get more information that way. We look forward to seeing new and old faces in the desert this year.

Yesterday afternoon, children at a mall in Ohio where shocked to find that instead of the Easter Bunny - they found a man dressed as the pickle from the now infamous Pickle Surprise video (directed by Tom Rubnitz) was waiting for them. For a ten minute period, the individual, who has since been identified as Durandal, did nothing but yell "Pickle Surprise" and "HAI2U" at the children. He was also offering "free candy" before he fled the facility once mall security arrived. When asked about the incident, mall-goer Chad Newsom stated that, "I had no clue what was going on and thought it had something to do with Adult Swim." Currently, no charges are planned on being filed as despite the disturbing event that took place, no children were abducted thanks to mall security. A photo was captured of Durandal in his getup, which can be seen below:

If you happen to see him in your area, please contact the local authorities.

My Thotcon presentation has been accepted! Below is the presentation abstract:

Without exploit mitigations and with an insecure-by-default design, writing malware for FreeBSD is a fun task, taking us back to 1999-era Linux exploit authorship.

Several members of FreeBSD's development team have claimed that Capsicum, a capabilities/sandboxing framework, prevents exploitation of applications. Our in-depth analysis of the topics below will show that in order to be effective, applying Capsicum to existing complex codebases lends itself to wrapper-style sandboxing. Wrapper-style sandbox is a technique whereby privileged operations get wrapped and passed to a segregated process, which performs the operation on behalf of the capsicumized process. With a new libhijack payload, we will demonstrate that wrapper-style sandboxing requires ASLR and CFI for effectiveness. FreeBSD supports neither ASLR nor CFI.

Tying into the wrapper-style Capsicum defeat, we'll talk about advances being made with libhijack, a tool announced at Thotcon 0x4. The payload developed in the Capsicum discussion will be used with libhijack, thus making it easy to extend.

We will also learn the Mandatory Access Control (MAC) framework in FreeBSD. The MAC framework places hooks into several key places in the kernel. We'll learn how to abuse the MAC framework for writing efficient rootkits.

Attendees of this presentation should walk away with the knowledge to skillfully and artfully write offensive code targeting both the FreeBSD userland and the kernel.

This presentation dives in depth regarding:
1) defeating wrapper-style Capsicum sandboxing with ret2sandbox_open (re-usable template exploit provided)
2) easy runtime process infection on amd64 and arm64
3) abusing the MAC framework to write rootkits (rootkit code will be released)

It is with pride and pleasure that SoldierX's libhijack was featured in PoC||GTFO 0x17. Shawn Webb, the author of both libhijack and the article, spent months writing the article and going through a private peer review process.

The unedited version is posted below. The full issue can be found here (warning: large polyglot PDF). I hope you enjoy the article.

Hijacking Your Free Beasties
============================

In the land of red devils known as Beasties exists a system devoid of
meaningful exploit mitigations. As we explore this vast land of
opportunity, we will meet our ELFish friends, [p]tracing their very
moves in order to hijack them. Since unprivileged process debugging is
enabled by default on FreeBSD, we can abuse PTrace to create anonymous
memory mappings, inject code into them, and overwrite PLT/GOT entries.
We will revive a tool called libhijack to make our nefarious
activities of hijacking ELFs via PTrace relatively easy.

Nothing presented here is technically new. However, this type of work
has not been documented in this much detail, tying it all into one
cohesive work. In Phrack 56, Silvio Cesare taught us ELF research
enthusiasts how to hook the PLT/GOT. The Phrack 59 article on Runtime
Process Infection briefly introduces the concept of injecting shared
objects by injecting shellcode via PTrace that calls dlopen(). No
other piece of research, however, has discovered the joys of forcing
the application to create anonymous memory mappings in which to inject
code.

This is only part one of a series of planned articles that will follow
libhijack's development. The end goal is to be able to anonymously
inject shared objects. The libhijack project is maintained by the
SoldierX community.

It's been awhile since we've posted a news update. I'm not going to lie, 2017 has been a busy year for most of us and a slow year for SX. I'm happy to announce that Jerbo has returned from his hiatus and is taking up the reigns on OFACE. Expect an updated release on that soon. We're also examining the site and our private tools collection to see where we should clean things up and what things we might be willing to share with the public. Expect 2018 to be much better, as near the end of it (October to be exact) - soldierx.com will be 20 years old. Quite a long time for a hacking group and honestly I'm surprised we've been around so long. After all of the arrests in the late 1990s and early 2000s, I honestly didn't know how much more we could take.

While you wait for various updates, please visit us in our IRC and get to know the community. We also welcome any suggestions on how we can do things better as I know much of the site is pretty dated at this point.

As discussed in A Hijack Revival, libhijack is under active development again. Today, I'm announcing version 0.8.0, which breaks both API and ABI from 0.7.0. The breakage is worth it, though. With version 0.8.0, libhijack now works on arm64. This marks a milestone achievement in libhijack: the first port to a non-x86 architecture.

It's interesting to note that during development, a local kernel DoS for arm64 was found, reported upstream, and subsequently fixed..

Download the source from GitHub here.

Here's the highlights of libhijack 0.8.0:

• New architecture supported: arm64
• Add ERROR_NOTSUPPORTED error code
• Make the memory mapping code architecture-dependent
• Add API for getting/setting various registers in an architecture-agnostic fashion
• Add API for querying instruction alignment
• Detect the base address better
• Switching from ptrace(PT_READ_D) to ptrace(PT_IO) for reading data
• Add sample exit(55) shellcode for arm64
• Add various sanity checks and clean up a bit of code

Next item to knock off the TODO list: anonymous injection of shared objects.

Over a decade ago, while standing naked and vulnerable in the comfort of my steaming hot shower, I gathered my thoughts as humans typically attempt to do in the wee hours of the morning. Thoughts of a post-exploitation exercise raced in my mind, the same thoughts that made sleeping the night before difficult. If only I could inject into Apache some code that would allow me to hook into its parsing engine without requiring persistance. Putting a file-backed entry into /proc/pid/maps would tip off the security team to a compromise.

The end-goal was to be able to send Apache a special string and have Apache perform a unique action based on the special string.

FelineMenace's Binary Protection Schemes whitepaper provided inspiration. Silvio Cesare paved the way into PLT/GOT redirection attacks. Various Phrack articles selflessly contributed to the direction I was to head.

Alas, in the aforementioned shower, an epiphany struck me. I jumped as an awkward stereotypical geek does: like an elaborate Elaine Benes dance rehearsal in the air. If I used PTrace, ELF, and the PLT/GOT to my advantage, I could cause the victim application to allocate anonymous memory mappings arbitrarily. In the newly-created memory mapping, I could inject arbitrary code. Since a typical operating system treats debuggers as God-like applications, the memory mapping could be mapped without write access, but as read and execute only. Thus enabling the stealth that I sought.

The project took a few years to develop in my spare time. I ended up creating several iterations, taking a rough draft/Proof-of-Concept style code and rewriting it to be more efficient and effective.

I had toyed with FreeBSD off-and-on for over a decade by this point, but by-and-large I was still mostly using Linux. FreeBSD gained DTrace and ZFS support, winning me over from the Linux camp. I ported libhijack to FreeBSD, giving it support for both Linux and FreeBSD simultaneously.

Due to some changes to google voice, RoboAmp 1.0.2 stopped working. RoboAmp has been updated to adapt to these changes, as well as a few other minor changes. You can get the new version here. If you would like to see more changes to RoboAmp or any of our other SX Labs releases, please drop by our IRC.

Congratulations everybody, our community is finally at over 15,000 active user accounts. Technically speaking we just had our 22,006 sign up - but over 7,000 of those were determined to be inactive/spammers and have had their accounts removed. We actively prune accounts that spam as well as accounts that never log into the site. We believe that our hardware upgrades have accounted for the increased traffic. Our next goal is to have over 20,000 active members. Thanks to everybody who has been active in our community and to everybody that has helped to spread the word about soldierx.com.