ERNW has a new baby, so please say “hello” to the new ERNW SecTools GmbH ;-).
But why another ERNW company? Short answer: Because we want to contribute to changing the way how software is built today: insecure, focused on profit and sometimes made by people who ignore lessons from history. So how can we contribute in this space? Start changing it ;-).
As Kai and I will be holding a TROOPERS workshop on automation with ansible, we needed a setup for the attendees to use ansible against virtual machines we set up with the necessary environment. The idea was, that every attendee has their own VMs to run ansible against, ideally including one to run ansible from, as we want to avoid setup or version incompatibilities if they set up their own ansible environment on their laptop. Also they should only be able to talk to their own machines, thus avoiding conflicts because of accidental usage of wrong IPs or host names but also simplify the setup for the users.
Looking at IPv6 deployment graphs like this one it becomes clear that IPv6 still is not widely deployed in enterprise space (the reason for the apparent oscillation in that curve is the difference between working days – where people use their office computers – and weekend where they preferably use their smartphones or their home equipment connected by means of broadband networks).
You may remember our last post regarding the SGOS system and the proprietary file system. Since then, we got access to a newer version of the system (188.8.131.52). Still not the most current one (which seems to be 184.108.40.206) nor of the 6.6.x branch (which seems to be 220.127.116.11) though. As this system version also used the same proprietary filesystem (although it initially booted from a FAT32 partition), I decided to take a deeper look into this.
This blogpost will be about my first steps with coreboot and libreboot and a life with as few proprietary firmware blobs as possible. My main motivation were the latest headlines about fancy firmware things like Intel ME, Computrace and UEFI backdoors. This post is not intended to be about a as much as possible hardened system or about coreboot/libreboot being more secure, but rather to be able to look into every part of software running on that system if you want to.
I’m happy to announce the release of several Glibc heap analysis plugins (for Linux), resp. plugins to gather information from keepassx and zsh, which are now included in the Rekall Memory Forensic Framework. This blogpost will demonstrate these plugins and explain how they can be used. More detailed information, including real world scenarios, will be released after the talk at this years DFRWS USA.