Joshua Mason

English shellcode

History indicates that the security community commonly takes a divide-and-conquer approach to battling malware threats: identify the essential and inalienable components of an attack, then develop detection and prevention techniques that directly target one or more of the essential components. This abstraction is evident in much of the literature for buffer overflow attacks including, for instance, stack protection and NOP sled detection. It comes as no surprise then that we approach shellcode detection and prevention in a similar fashion. However, the common belief that components of polymorphic shellcode (e.g., the decoder) cannot reliably be hidden suggests a more implicit and broader assumption that continues to drive contemporary research: namely, that valid and complete representations of shellcode are fundamentally different in structure than benign payloads. While the first tenet of this assumption is philosophically undeniable (i.e., a string of bytes is either shellcode or it is not), truth of the latter claim is less obvious if there exist encoding techniques capable of producing shellcode with features nearly indistinguishable from non-executable content. In this paper, we challenge the assumption that shellcode must conform to superficial and discernible representations. Specifically, we demonstrate a technique for automatically producing English Shellcode, transforming arbitrary shellcode into a representation that is superficially similar to English prose. The shellcode is completely self-contained---i.e., it does not require an external loader and executes as valid IA32 code)---and can typically be generated in under an hour on commodity hardware. Our primary objective in this paper is to promote discussion and stimulate new ideas for thinking ahead about preventive measures for tackling evolutions in code-injection attacks.

An Internet-wide view of ICS devices

Industrial control systems have become ubiquitous, enabling the remote, electronic control of physical equipment and sensors. Originally designed to operate on closed networks, the protocols used by these devices have no built-in security. However, despite this, an alarming number of systems are connected to the public Internet and an attacker who finds a device often can cause catastrophic damage to physical infrastructure. We consider two aspects of ICS security in this work: (1) what devices have been inadvertently exposed on the public Internet, and (2) who is searching for vulnerable systems. First, we implement five common SCADA protocols in ZMap and conduct a survey of the public IPv4 address space finding more than 60K publicly accessible systems. Second, we use a large network telescope and high-interaction honeypots to find and profile actors searching for devices. We hope that our findings can both motivate and inform future work on securing industrial control systems.

Security Challenges in an Increasingly Tangled Web

Over the past 20 years, websites have grown increasingly complex and interconnected. In 2016, only a negligible number of sites are dependency free, and over 90% of sites rely on external content. In this paper, we investigate the current state of web dependencies and explore two security challenges associated with the increasing reliance on external services: (1) the expanded attack surface associated with serving unknown, implicitly trusted third-party content, and (2) how the increased set of external dependencies impacts HTTPS adoption. We hope that by shedding light on these issues, we can encourage developers to consider the security risks associated with serving third-party content and prompt service providers to more widely deploy HTTPS.