Profile cover photo
Profile photo
Llamas In My Network
Keeping your network secure by keeping the llamas out
Keeping your network secure by keeping the llamas out

Llamas In My Network's posts

Post has attachment

Post has attachment
Moxie Marlinspike posted about the failings of GPG (GNU Privacy Guard, an open-source implementation of PGP) for trying to be too perfect.  In the following article, I argue for something that is good enough but which can be improved over time.

(I wrote this at the end of February and, in the aftermath of the passing of Leonard Nimoy, I forgot to post it here.)

Post has attachment
Looking for a computer?  Thinking about a Lenovo?  Please reconsider your choice.

Post has attachment
This is a quick overview of how I browse the Internet using four browsers.  It's not as complex as it sounds, but it does make things a bit more secure.

Post has attachment
Want to learn how to conduct a penetration test? I'm teaching a Mentor course in the #DFW area for #SANS #SEC560 : Network Penetration Testing and Ethical Hacking starting Apr 21, 2015.  Here's your chance to learn:
- How to properly scope a pen test
- Writing an effective report for the client
- Finding and exploiting weaknesses in the target
- Pivoting to inaccessible targets
- Cracking passwords
- Why getting root/SYSTEM isn't enough

Sign up by Mar 24 for discounted rates!

When registering, it would be a great help to me if you would enter "MENTOR RECRUIT" in the Comments section of the registration.

Post has attachment
I'm teaching a Mentor course in the #DFW area for #SANS #SEC504: Hacker Techniques, Exploits, and Incident Handling starting Jan 20, 2015.  Here's your chance to learn:
- Preparing for an incident: Not if, but when
- Legal issues and when to involve outside entities
- Common tactics used by attackers
- Vulnerabilities in operating systems, applications, and networks
- How to look for, respond to, and recover from attacks

Sign up by Dec 23 for discounted rates!

Post has shared content
If you're in the #Dallas  area, interested in learning about #hacking  and #infosec , and interested being part of a #CTF  (Capture-the-Flag) team, this is a good place to start.  No experience necessary.
For those interested in the CTF team, please stop by this link and have a look at the basic setup that I've put together. If you don't have a forum account, please do create one and chime in with your thoughts, even if it's just to say that you're OK with it.

(Don't forget to drop by the Welcome forum and introduce yourself if you haven't already done so.)

Just in case any of you are looking to encrypt your data and need an awesome program to do it... do not go to TrueCrypt right now.  The site has (apparently) been compromised saying that the program is insecure and providing instructions to move to BitLocker (built into some versions of Windows).

More worryingly, a version has been posted that was signed with the TrueCrypt Foundation's GPG key, meaning that the compromise is extremely complete.

Again: DON'T go there unless you know what you're doing.  Here's hoping it will get cleaned up soon.

So the bug security news of the day is called "Covert Redirect" and it's purportedly a weakness in the OAuth 2.0 protocol used by Google, Facebook, and many others. Except it's not, and there's not really anything that Google, Facebook, etc. can do about it.

It's not a weakness in the protocol. It's a failure of external sites (those using Google, Facebook, etc., to authenticate) to validate the information passed to them. It is not a flaw in the protocol, and in fact was identified as a potential threat a year ago with advice that site developers implement appropriate filtering.

Here's how it works in brief is this:
1. Site ( sends request to authenticator (we'll use Google) to identify user Pat, and if it's successful, send the user back to
2. Some sites allow a redirect to be specified in the form of Even in this case, though, Pat will be sent to first because has to issue the actual redirect.
3. If doesn't check where it's redirecting users and if the attacker can control the redirect to go to, say,, then that's where the user will go.

The solution to this is really simple: has to check where it's redirecting users. It should only be directing them to domains it controls. If it doesn't, it's a failure on, not on the authentication providers.

So as a test of a program called #oclHashCat, I ran through a set of NTLM #password hashes recently on my system. While it's better than most, it's really not that special and has only a single AMD 7970 graphics chip in it. Using that, I went through the entire space of mixed case letters and numbers up to eight characters (approximately 222,000,000,000,000 combinations) in a mere 7.5 hours. Current GPUs are as much as 50% faster per GPU, and some systems can be configured to have ten of them for not very much money.

If you have passwords that are shorter than 10 characters, you're at a serious risk of them being cracked. Update them to something better.
Wait while more posts are being loaded