Information Security Short Takes

It has been more than 5 years since I've last updated this blog. Going back and reading through the materials i find a lot of legacy and already forgotten tools and processes, some future mistakes and even some good long valued articles. I decided to move all articles back to draft mode and will revise and re-publish those that are still relevant. In the meantime, I apologise for the emptiness around here.

I created a simple treasure hunt challenge for young InfoSec enthusiasts and professionals. It's mainly OSINT with some very basic crypto and a tactical story. No real prize except bragging rights and mentions if you choose so.  No details collected and you can choose whether to submit the final solution. The challenge starts on my Linkedin profile  https://www.linkedin.com/in/spirovskibozidar/ The challenge will be active until the end of October 2018, after which a full writeup will follow. Also, ideas for the next challenges are greatly appreciated :)

Steganography is still considered to be a part of the obscure tools of secret agents and corporate spies. However, steganography tools are widely available, and anyone can use them. Most of these tools are now available online. But a lot of systems currently perform some form of resampling or filtering of images. This poses an interesting challenge -  how survivable is steganography in filters? This also gave us a great reason to publish another set of pictures (albeit cropped) of Lena Söderberg ;) Here is our original image Proposed Counter-Steganography System The filter system will need to be cost-effective, minimally intrusive and not prone to error. Since there may be many different steganography alghorithms, the filter system should not try to read such messages. Doing so will require an entire farm of filter servers. Instead, the systems will resort to a much simpler mechanism: Modify all passing images so that the original hidden data is compromised. Use only minute c

When preparing a Disaster Recovery Center, one of the most important decisions is the location of the location of the Disaster Recovery Center. Up until the 9/11, a lot of companies held their DR centers in the adjacent building, and right after 9/11, everyone wanted to go as far from the primary data center as possible. One of the common misconceptions of Disaster Recovery planning is that longer distance ensures better disaster protection. Of course, increasing the distance between data centers reduces the likelihood that the two centers are affected by the same disaster. But just putting distance between locations may not be sufficient protection. In reality, the best distance for a DR location is dictated by a multitude of factors: Is the Cloud a good solution - these days the buildout of a DR datacenter may be completely redundant and just delay the DR implementation by many months and even years. If you can implement the DR solution in a cloud based service (remote datacen

Communication links provided by Telco providers are critical to most businesses. And as any network admin will tell you, these links tend to have outages, ranging from small interruptions up to massive breakdowns that can last for days. When such interruptions occur, businesses suffer, but unless the provider has serious contractual obligations, there is little effort on their side to improve service or correct issues. That is why businesses need a good Service Level Agreement (SLA). Usually, the preparation of the SLA is dreaded by most, since it is full of numbers and parameters on which the client must decide what is acceptable, and whose values may be difficult to measure. SLA Parameters A good SLA is not necessarily loaded with a lot of numbers. You need to work with 2-3 parameters which are important to you. Here are the most frequent SLA parameters, with their acceptable values: Availability - more then 99% for internet, more then 99.5% for corporate data links Packet

This week i tried to open an old TrueCrypt container. It turned out that i had forgotten the password. So I endeavored into the realm cracking the TrueCrypt container. Here are my experiences The problem I have a TrueCrypt container in which i hold my personal documents. The container is created with TrueCrypt 6.1a. Since i haven't been using the documents for a while, the password slipped from my mind. I a moment of desperation I tried to crack the password. The preparation To automate the process, I used the true.crypt.brute tool in version 1.9b. It is a very straightforward tool to use, but it has one drawback - it tries to crack based only on a pregenerated wordlist. That means that you need to generate your possible passwords list and let it rip. First, i created a simple encrypted volume with a 2 character password to check the software. It went through 819 passwords within 45 seconds and decrypted the password. This would mean that the brute force crack would run