Jordan Wright

For this challenge, we were given an HDD image and asked to find the flag on it.

This challenge starts off with the following hint:

I was sniffing some web traffic for a while, I think i finally got something interesting. Help me find flag through all these packets.

This challenge started off with a pcap. Let’s take the cheap way out and do a basic Wireshark filter for frame contains flag:

Web 200 was a fun challenge that required us to chain together a few basic concepts to get the flag. When navigating to the URL given, we see that the challenge is based on a “Lawn Care Simulator 2015”.

This one was surprisingly easy if you knew where to look.

Introduction

This post is long overdue.

Back in May 2013, I released a Twitter bot called @dumpmon whose sole purpose was to track and report password dumps and other sensitive information shared on paste sites such as Pastebin. Since that time, dumpmon has proven - to my excitement - to be valuable to researchers, being featured in news articles, Defcon slides, and HIBP!

After two years, it’s time to post an overdue status update providing some insight into the data dumpmon has collected over this time.

Note: This is a pretty long post, so feel free to skip here if you just want the data.

Introduction

Welcome to the third post in my series on how Tor works! In the past two posts, we talked about how clients tunnel traffic through relays, as well as introduced the idea of unpublished relays called bridges.

But how do clients know what relays are active? How is the Tor network actually organized and maintained? This post will answer this question by talking about a living document called the consensus as well as introducing a few very important Tor nodes that run the show behind the scenes.

Introduction

Welcome back to my series on how Tor works! In the last post, we took a look at how Tor operates from a very high level. In this post, we’ll dive a bit deeper, taking a look at a potential issue with relays in order to introduce a new concept: bridges.

Introduction

Two months ago, one of my DigitalOcean instances started attacking another host with massive amounts of bogus traffic. I was notified by the abuse team at DO that my VPS was participating in a DDoS attack. I managed to track down that the attackers leveraged an RCE vulnerability in Elasticsearch to automatically download and run malware.

After re-building the box from scratch (with many improvements!), I created a honeypot called Elastichoney to measure how much this vulnerability is being exploited in the wild. Since then, I’ve had multiple sensors silently logging all attempts to exploit this vulnerability.

Here are the results.

Introduction

I recently wrote about an Elasticsearch RCE vulnerability that is being heavily exploited in the wild. To see what kind of attacks are taking place, I decided to write a simple honeypot designed to mimic a vulnerable Elasticsearch (ES) instance. Say hello to elastichoney!

TL;DR If you have an elasticsearch instance that is publicly available, upgrade to 1.4.3 or later now.

Elasticsearch (the “E” in ELK) is a full-text search engine that makes data aggregation and querying easy. It has an extensive JSON API that allows everything from searching to system management. This post will show how a new vulnerability, CVE-2015-1427, allows attackers to leverage features of this API to gain unauthenticated remote code execution (RCE).

Much of the analysis discovering this vulnerability was originally found on a blog post here (translated). This post aims to translate and provide more detail on the vulnerability.