When to sharpen, and when to cut

Cut down a tree

When performing a task for the first time, I think of whether it's a one-off, or that it will become a recurring thing. Python scripts for example can be developed blazingly fast, and a little bit of automation can go a long way.

However...

...sometimes, while developing an automated solution that looked so simple beforehand, becomes a wild ride from one rabbit hole into the other. Missing dependencies, compile errors, functions that don't lend themselves very well for automation; Everything that can go wrong will go wrong.

That's why I like The Pomodoro Technique [1] so much, where you work in discrete time chunks of say 25, or 30 minutes. You decide upon the maximum cost for the implementation beforehand. Given the expected return, what is a sane investment ? If the time is up, then it's back to the original task at hand.

I have learned the hard way to always budget some time for documenting the (partial) solution, so that at least there's the profit of knowledge gained. Or, another record of a failed attempt...

[1]https://francescocirillo.com/pages/pomodoro-technique
more ...

Tools for setting, tracking and achieving long term goals

planner2018

Immediately after reading an article on David Allen and his brainchild Getting Things Done, I started with implementing his methodology. I loved it. I still love it - especially the Getting Things Done concepts of inbox ZERO, maintaining lists, and periodic reviews.

Inbox ZERO for me is not so much about having empty email inboxes, as well as making sure that input is collected from multiple locations and stored into one dedicated location. An inbox can also be a notebook, or note taking software like Google Keep.

Electronically stored lists have the benefit of being available on a multitude of devices, the ability to synchronize between them, backups, and their biggest advantage - providing dynamic views.

emacs

Both tools that I have been using so far (the open source Java application ThinkingRock [1], and Emacs in Org mode [2]) for maintaining lists of actionable items and projects were great in that perspective. Using those tools for periodic reviews was a different story. After trying numerous configurations I never got the hang of using ThinkingRock and Emacs for that purpose. Items become abstract letters on a screen. Views never fully captured what was important or which project served which goal.

Periodically reviewing projects and …

more ...


Hacker Summer Camp: BSides Las Vegas and DEF CON 2017 review

BSides Las Vegas 2017

The 2017 edition of Hacker Summer Camp is over... Blackhat, BSides and DEF CON: Arguably the best security conferences in the world, being held during a week in Las Vegas. And wow, what an amazing edition it was this time.

I tried to learn, network, enjoy and soak up as much as possible - which unfortunately means not seeing each and every talk, and (probably) missing out on amazing content. That's why I'm so glad that recordings and slidedecks are being released by BSides and DEF CON, so that you can see where you should have been - after the fact.

The biggest draw for me personally to BSides and DEF CON is that you can immerse yourself in fields and interests that are outside of your daily work or routine. Car hacking, lockpicking, the Internet of Things, this year even voting machines: It's all there. You can learn from and play with everything.

As with playing Capture the Flag, it's a great way to touch a lot of surfaces in a short amount of time.

Josh Corman's BSides Las Vegas keynote was amazing - each time I hear him speak, he manages to get everybody even more enthusiastically about cooperation, about personal …

more ...


The complexity of securing Docker versus Vagrant

Docker versus Vagrant

There are many, many comparisons out there on the Internet of Docker versus Vagrant. Usability, scalability, portability, you-name-it-ability.

This blogpost is about some different security aspects about the current implementation of Docker versus Vagrant. It's a high, high-level comparison of the security impact for the host system.

Can you compare the two ? Not really, they're being used for completely different reasons. Docker is wildly popular for medium to large scale production webserver deployments and microservices, where each service has its own process, or container. Vagrant is more being used during design and development by individual developers, or in teams at companies.

So, having said that, let's compare the security differences in high-level:

Docker

  • Partial isolation from the host
  • Shares the kernel with the host.
  • Resources aren't guaranteed, they're shared.
  • Uses runC/libcontainer as runtime (before version 1.8 it used linux containers (lxc) under the hood, then libcontainer, and since the inception of the Open Container Initiative it uses runC which abstracts even further away from libcontainer). System resources can be allocated using control groups (cgroups): block devices (blkio), CPU (cpu), CPU accounting (cpuacct), individual CPU and memory nodes (cpuset), devices, task management (freezer), memory usage (memory), network packets (net_cls …
more ...

Security through obscurity means better operational security

Are YOU OPSEC ?
What I personally like so much about being a penetration tester, is that (I'd like to think that) we make the world a safer place. Better security means better privacy means more democracy.
It's not about telling people what "they" did wrong. On the contrary, it's a learning process for all of us. No single application, network or system is the same. Each company has its own risk model, which means that there often is no one-size-fits-all solution.

It's about "how can we improve the security" for everybody. That's why I think it's so important that penetration testers should lead by example. Apply proper operation security procedures themselves.

Recently my first Pluralsight course was published, operational security for penetration testers. It deals with what opsec is, and how to apply it to your penetration testing workflow. The trailer of the course can be found at https://www.youtube.com/watch?v=DSF6XbCxYGY. The course itself can be found on Pluralsight's site, https://www.pluralsight.com/courses/opsec-penetration-testers

As beautifully stated by the third law of OPSEC: "If you are not protecting it, the adversary wins".

more ...

Why Sharing Improves Us

why sharing improves us

If you're a perfectionist, it's difficult to release a product: Whether that's source code, a pentest report or a blogpost. It's always a work in progress, and never finished.

That's why I like open sourcing code for example, releasing it for everybody to see. Knowing beforehand that the code, your work will be read by others (while you're working on it) forces you to think longer, deeper and harder about the variable names, the structures, function names and coding styles.

I'm the lead pentester for a company where we allow the customer to peek over our shoulder while we're working. The customer can see everything that we try, do and find out during the pentest. This improves the relationship with the customer, as s/he sees what we're doing and even can think along with us.

It also improves the customer satisfaction, as they know exactly what they're getting. And, it improves the mutual respect. Instead of becoming a classical us-versus-them pentest (the pentesters versus the developers), it becomes a 'let's improve the overall security together' exercise.

According to all the positive feedback we're receiving, we're onto something here. A win-win.

Sunlight is not only a great disinfectant, it's also …

more ...

Bash vs Python (dependency hell)

For a number of years I maintained a small collection of open source security scripts, written in Bash. The main purpose of these scripts was to act as a wrapper around other open source tools. Why try to remember long and awkward command line parameters, when you can ask a script to do that for you ?

Bash was chosen, as it was distribution-independent. It works almost everywhere (although sometimes OSX support is troublesome, due to outdated Bash versions).

After more and more (requested) features crept in, the

analyze_hosts.sh
Bash script became more and more complex. That's why I decided to port the script to Python. In my experience, it's at-least-as portable, and the usage of third party (pip) packages means that less time is spent on re-inventing the weel, and more on the actual functionality.

Yes, sometimes people talk about the dependency hell of Python, and in some cases, the usage of third party packages means you have to be careful of what you're doing.
However, when using virtual environments each Python script and its dependencies can be safely separated from the 'main' Python. For example, the following commands create a separate virtual environment for the security scripts repo …
more ...

Preparing your team for a CTF competition - Defcon style

Defcon

Playing Capture The Flag with a team on location is something completely different than performing penetration tests, security assessments or even trying to solve CTF challenges over the Internet.

At Defcon 23 I joined a team of really knowledgeable, nice and friendly people for the OpenCTF competition. It was an exhilarating ride from setting up all equipment to the glorious finish. Playing Capture The Flag on Defcon was educational but foremost fun, fun and fun.

So why would you spend a good chunk of 48 hours sitting in a chair behind a screen while there is so much more to see and experience at Defcon ? In one word: The undescribable exciting atmosphere of playing during a conference, of competing against all these bright people from all over the world, desperately trying to solve the challenges.

Here are some of my personal notes on how to get the most out of competing in an OpenCTF competition with a team:

  • Allow plenty of time before the competition to set up (and harden - don't be a fool like me) your machine. Make sure you have all necessary tools and notes.
  • Make sure beforehand that all team members have one communication channel (eg. IRC …
more ...