My Pi-Hole Setup

What in the world is a Pi-Hole you may ask? Pi-Hole is a software package whose primary purpose is to block ads, spyware, phishing, malware, and other undesirable traffic on your network. It runs on pretty much any distro of Linux and for my setup, I’m currently running it on a Raspberry Pi 3, but you can also run it in a VM such as VMWare or Virtualbox as well as on dedicated hardware, or even by using pre-built Docker images. In this blog post I’m going to document how I have designed my setup with the main objective of having all traffic on my home network go through the Pi-Hole to keep all of the common trash of web browsing off all of the devices that my family uses. Continue reading

Cultivating Infosec Knowledge

I often get asked through both work and social media channels how and where do I obtain all of the Information Security knowledge that I routinely share. So I though I would share my own personal workflow for how I cultivate Infosec knowledge and others can use what I’ll describe in this blog post as a framework to build their own. I should point out that my workflow is dependent upon using a Linux distro that supports specific packages such as Weechat. If you are primarily a Windows user, you may need to make some adjustments

I often get asked through both work and social media channels how and where do I obtain all of the Information Security knowledge that I routinely share. So I though I would share my own personal workflow for how I cultivate Infosec knowledge and others can use what I’ll describe in this blog post as a framework to build their own. I should point out that my workflow is dependent upon using a Linux distro that supports specific packages such as Weechat. If you are primarily a Windows user, you may need to make some adjustments such as start using Ubuntu.

Step 1: Twitter

By far the best source for cultivating knowledge is Twitter. First there are tons of Information Security professionals from pretty much every domain of knowledge within Infosec. This involves of course obtaining an account(make sure you leverage 2FA) and following users who specialize in the area that your interested in. Another great feature are ‘Lists’. These are groups of Twitter users for a specific area. This one is a good start: https://twitter.com/DanielMiessler/lists/infosec. So got get yourself an account if don’t have one and start searching using hashtags such as #cybersecurity or #infosec.

Step 2: IRC Client That Logs Locally

You may be asking what is IRC and why do I need an IRC client to cultivate Infosec knowledge? This will become obvious as this post progresses, but IRC was an Internet standard draft created 20+ years ago to create a real-time chat network. The reason you want a modern IRC client that supports logging locally is that there is an IRC gateway called Bitlbee that enables you to integrate with Twitter and the like into the IRC client, which enables you to log all of that content for later reference and searching.

I personally use Weechat due to all of the plugins available for it and being able to leave it running 24X7 in a Tmux session. Think of Tmux as a means of running persistent terminal sessions.

Step 3: Bitlbee

As mentioned earlier Bitlbee is an IRC gateway that acts as a relay between your IRC client and the platforms it supports such as Twitter and Facebook. For my purposes the Twitter integration is key, because it basically turns your IRC client into a Twitter client and most importantly your Twitter timeline is logged locally as long as you have it running. This is where Tmux comes in so even if you log out your sessions are still running. This becomes advantageous when you want to pull out a bunch of links or content, all you have to do is grep through your Bitlbee Twitter logs.

Step 4: Slack & WeeSlack

Slack is a modern attempt to displace IRC utilizing web based API’s and pretty looking integrations such as emoji’s and integrations with a large number of automation technologies such as Splunk and devops apps. There is one Slack channel that has LOTS of Infosec peeps on it and it’s called Brakesec and is run by Bryan Brake. Follow him and send him a Tweet asking for access.

I use a very cool Weechat plugin called, WeeSlack that integrates with WeeChat and gives you the same great benefits that Bitlbee does with Twitter. WeeChat is turned into a full blown Slack client with logging.

Conclusion

With this setup I have a perpetual feedback loop that stores everything locally for referencing when ever you need to and with the content in plain text files you can query and extract it however you want.

The Necessity of Security Standards

Having been working in the Information Security industry for almost two decades, I’ve seen what has and has not worked well for organizations approach to Security. One of the biggest pitfalls I’ve seen is a type of insanity in repeating the same mantras over and over again to supporting groups and stakeholders and then wondering why this incessant repetition keeps returning full circle. Guidance that is provided tends to be slightly different each iteration enough to make each case sound like it’s unique, but it isn’t.  

One project manager approaches someone on the security team and asks, “Hey, our vendor says they can only support DES encryption, is that OK?” Few hours later another PM from a different project approaches a different security team member and asks, “What encryption algorithms does our vendor need to use?” To which the security analyst replies, “We cannot use anything weaker than AES-128.” In this short, but all too common scenario we have two distinct answers to the same question one of which could have serious repercussions in that DES has been broken since 1976!

This is where the need for adopting organizationally sanctioned security standards come into play. The the earlier could have been solved by having an established Cryptography standard that would mandate the approved encryption algorithms to be used in the organization. Thus, when Larry the project manager swings by the Information Security area to ask what are acceptable encryption algorithms you just point them to the Cryptography security standard that documents those requirements. When Joe the other project manager stops by asking the same question for a different project the same guidance is given and then you have a consistent standard from which the entire organization works from. 

Over the years I’ve found that there is a minimal list of security domains that you should have security standards for to formalize security standards across the organization:

  • Access Control 
  • Asset Inventory
  • Authentication
  • Cryptography
  • Certificate Management
  • Data Protection 
  • Incident Management
  • Logging
  • Malicious Software
  • Monitoring
  • Network
  • Operating System – You should have a standard for each OS deployed. 
  • Remote Access
  • Virtualization
  • Vulnerability Management

Your mileage will vary depending upon the organization your working for and how they are leveraging the security domains outlined, but the important first step is getting them drafted and ensuring senior management supports not only their content, but their enforcement across the organization or they will end up becoming suggestions instead of requirements. Security standards are just one component of the overall Information Security ecosystem; you still need to have security policies to drive them and security architectures to ensure they are being adhered to. 

Stop Referrering to TLS as SSL!

Having worked in the Information Security field for close to 20 years now, one of my biggest pet peeves is when Security professionals use technical terms that no longer comport to current realities. So as a word of warning this blog post is going to be a rant.

It is first important to understand some basic history around the progression of the protocol from SSL to TLS. As is the case with most security protocols each new version is created to address security defects in the previous version.

SSL/TLS Implementation Timeline – SSL First Introducted in 1993-1994 by Netscape – SSL 1.0 was never released due to serious security flaws – SSL 2.0 released in 1995 to address the security flaws found in SSL 1.0 – SSL 3.0 released in 1996 as a pretty much rewrite of the protocol to address defects found in SSL 2.0 – TLS 1.0 released in 1999 to address some “minor” issues identified in SSL 3.0 – TLS 1.1 released in 2006 to provide additional security enhancements – TLS 1.2 released in 2008 to provide enhancements around SHA-256 along with support of additional authenticated encryption ciphers.

SSL/TLS Vulnerability Timeline – 2011 – SSL 3.0 and TLS 1.0 found to be vulnerable to BEAST attack – 2014 – SSL 3.0 found to be vulnerable to the POODLE attack

As can be deduced from the above timelines, no one should be using “SSL” as defined in the RFC’s since 1999, but absolutly not since 2011 due to BEAST. Information Security professionals certainly should not be referring to TLS as SSL as I’ve observed time and time again over the last decade.

What is the big deal you may ask? Certainly everyone knows what you are talking about when you tell a client or a customer, “Just secure the HR website with SSL and you’ll be fine.”. Your client or customer then does a proverbial Google search and they find that anyone securing their site with SSL is without doubt a psychotic. They then call you and ask you why you would configure their highly sensitive HR website with a protocol that has been exploitable for the past 7+ years. To which you respond, “Oh no, we would never configure your site with SSL as the security best practice is to only enable it with TLS 1.1 or above.”.

You have know learned why terminology that reflects actual reality matters.

References

  1. Transport Layer Security(TLS)
  2. TLS/SSL Explained – Examples of a TLS Vulnerability and Attack, Final Part

Cybersecurity Podcasts

I was recently asked to give recommendations for Cybersecurity Podcasts to students in college that are majoring in Security. The usual problem with security podcasts (and podcasts in general) is that they frequently become static and in some cases a year or more goes by before they are updated.

There are actually a large number more of Cybersecurity related podcasts than what I have listed here, but these should keep your mind update enough without getting overloaded.

Here are some of the main ones that I know that are kept up to date.

Threatpost Security Podcast

Breaking Security Podcast

White Rabbit Podcast

Security Weekly

Defensive Security Podcast

OWasp 24/7 Podcast

Risky Business Podcast

Building Metasploitable 3 on Ubuntu/Debian

Recently I attempted to build the new Rapid 7 Metasploitable 3 VM for use in my pentest lab on Ubuntu 16.10. Followed the instructions on their Github page to the letter, but failed in variety of areas. The good news is that I was able to hack my way through all them to get it built. This blog entry is going the steps you need to take to successfully build the VM on a Ubuntu/Debian based system. I’m assuming you may run into similar issues on a Fedora-type system, but your mileage may vary.

 

Packer

No issues with Packer, beyond just installing it with: sudo apt-get install packer

Vagrant

First you to need to install Vagrant: sudo apt-get install vagrant

Second, you before you can build the vagrant-reload plugin, you need to install the ruby-dev package with:

sudo apt-get install ruby-dev

Now you can install the plugin with: vagrant plugin install vagrant-reload

Due to the dependency upon WinRM and with the Vagrant version in the Ubuntu/Debian repo you will need to install:

vagrant plugin install winrm --plugin-version 1.8.1
vagrant plugin install winrm-fs

The 1.8.1 version is key in order for the build to complete successfully.

Metasploitable 3 Build Script

The Metasploitable 3 build script has some checks that fail due to the latest version of Virtualbox that’s in the Ubuntu/Debian repo. The main reason is they are checking for a specific version of Virtualbox and since with Ubuntu/Debian your running a newer version than what the build script requires, it fails.

Since we know we already have the necessary dependencies built, we can just run the build commands manually:

TMPDIR=/home/tmp packer build windows_2008_r2.json

The TMPDIR directive was another gotcha as I only had 1GB of space allocated to my /tmp filesystem and the process ran out of space. Point the TMPDIR variable to a path where you have enough space.

Now we can create the Vagrant box with:

vagrant box add windows_2008_r2_virtualbox.box --name metasploitable3

And then start it up with just: vagrant up and your good to go.

Happy Hacking!

Security Links for March 2016

SecureCode_product offering Here are some new security-related (for the most part ;) links from the month of March 2016

Bitcoin Wisdom – Trading-type Terminal for Bitcoin – https://bitcoinwisdom.com/

Zone Transfer Tutorial – https://digi.ninja/projects/zonetransferme.php

Debian Hardening Wiki – https://wiki.debian.org/Hardening

Standard Password Manager for UNIX – https://www.passwordstore.org/

Is your Browser safe against tracking? – https://panopticlick.eff.org

Have I been Pwned? – https://haveibeenpwned.com/

CryptoPals -Cool CTF for Crypto – http://cryptopals.com/

Nice Tool to Tell What CMS A Site is Running – https://whatcms.org/

A simple SSL/TLS proxy with mutual authentication for securing non-TLS services – https://github.com/square/ghostunnel

Find out if a site is down globally – http://www.downforeveryoneorjustme.com/

DNS Zone Transfer Tool – https://github.com/stryngs/axfr-tools

Nice Coding Guide for N00bs – http://download-mirror.savannah.gnu.org/releases/pgubook/ProgrammingGroundUp-1-0-booksize.pdf

Ransomware seems to be popular these days. Here’s a site that tracks the variants – https://ransomwaretracker.abuse.ch/tracker/

Need I say more? – http://www.routerpwn.com/

Security Links for February 2016

SecureCode_product offeringMade a blunder on the droplet that runs this blog on Digital Ocean and lost the previous two security link blogs. Luckily had a backup from August that I was able to restore from. Anyways, here’s the security links for February 2016.

Application Security Learning Resources – https://github.com/paragonie/awesome-appsec#application-security-learning-resources

A Dead Simple TCP Intercepting Proxy Tool Set – https://www.praetorian.com/blog/trudy-a-dead-simple-tcp-intercepting-proxy-mitm-vm

Let’s Encrypt Audit – https://community.letsencrypt.org/t/independent-audits-of-lets-encrypt-finished/6518

Introducing the Keybase filesystem – Sounds like a sane approach to encrypting data at rest – https://keybase.io/docs/kbfs

Securely Hash Passwords – https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords

An Interesting Online Scanner – https://www.censys.io/

Another Attempt at Creating a Secure Linux Distro – https://www.parabola.nu/

An open-source network simulator/emulator hybrid (Tor & Bitcoin) – https://shadow.github.io/
For Encrypting/Decrypting Data on the Fly – https://encipher.it/

Red Team Field Manual – http://www.amazon.com/Rtfm-Red-Team-Field-Manual/dp/1494295504/ref=pd_bxgy_14_3?ie=UTF8&refRID=19V4X7X4WW7215V446N7

Decentralized DNS 
for Blockchain Applications – https://blockstack.org/

Github Bounty Program – https://bounty.github.com/index.html#open-bounties

Send An Urgent Message to a Friend When your in Trouble (i.e. Feds are knocking at your door) – http://www.snapmailemergency.com/

Get your cheap exploits here – http://cheapbugs.net/#home

Educating Youth for Cyber Security Careers

security-icon-01This past week I attended the Northeast Ohio Cyberconsortium conference sponsored by a number of entities in the Cleveland,Oh area. The goal of the conference was to stimulate a collaborative effort around building up and sharing information around Cyber Security as it relates to the North East Ohio area. One of the main talks was about the skills shortage in Information Security and what should be done to increase the talent pool. The proposition(they loved throwing this word around) offered was to build educational programs in the school systems around Cyber Security at as early of an age as possible. I think the NSA said that they get the gifted ones as early as 3rd grade and for security we should consider preschool.

The goal is an excellent ones, but the reductionist attitude offered presents a number of challenges. The one problem is that you simply cannot teach Information Security as an isolated discipline. There are a number of prerequisites that are necessary before you can even start to teach kids security. To name a few:

  • Computer Architecture – X86/X64/ARM
  • Operating Systems – UNIX/Windows/OSX/Android/IOS
  • Programming – Powershell/Python/Perl/Bash
  • Networking – TCP/IP, OSI, Ethernet, Wifi
  • These are all complex domains by themselves and then add on to that the various security principles that need to be applied and you can see it’s not as cut and dry as you may think.

    Then there are the ethical challenges in that to really understand how to secure things is you have to understand how to break things. This will no doubt create dilemmas with existing school policy and what the kids can currently do with school equipment.

    So I think what really needs to happen to make this achievable is a complete rewrite of existing educational plans. I think a structure more like college should be implemented where kids that are interested in a given domain like Cyber Security can elect to make it their ‘major’ and by doing so a specific roadmap would be produced for their educational career.

    The other thing to keep in mind is not all kids will be interested in such a field nor have an aptitude as you need to think about problems in a very detailed and logical way and not everyone’s brain is wired this way.

    Let’s Encrypt Talk @ Debconf15

    ssl1-150x150At this years Debconf15, a nice overview of the Let’s Encrypt project was given that you can view here. It’s a nice exposition as to the current broken state of CA’s and the projects plan to solve them. Let’s Encrypt is going to be making free certificates available in the next month or so.

    Will this be a game changer for commercial CA’s that make their profit off of selling certificates? Probably not in the short term and a large part of the answer will depend upon adoption and getting the Root & Issuing CA’s added to the trusted browser stores.