Author: Douglas Muth

Posted on

What a Phone Scam Sounds Like: Meet “Rachel from cardholder services”

I got this voicemail the other day from “Rachel at cardholder services”:

(If the embedded player doesn’t work, here’s the direct link)

This one is kinda clever, that rather than a human using high-pressure tactics to get you to enter your credit card number, what you hear instead is a recorded message which asks you to “press 1 to get a lower interest rate”. Had I pressed 1, I suspect I’d be transferred to a nice sounding human operator who would try to coax me into giving them my credit card number.

There’s two takeaways from this:

  1. Never give out your card card number to someone who calls you on the phone. (caller ID can be spoofed)
  2. Strongly consider against picking up the phone when an unknown number calls you. Let it go to voicemail. If it’s someone trying to get a hold of you, you can listen to the voicemail right away (or use Google Voice, which does transcripts), and call the person back.

Stay safe.

Posted on

Introducing Diceware: Secure Passwords You Can Remember!

In general, the longer the password, and the more random it is, the more secure it is. This is because if a password file is stolen, the passwords are stored there are stored in encrypted format, where each password is encrypted with… itself. This means that in order to determine what an account

‘s password is, an attack must try encrypting every random possible string and see if it matches the encrypted password.

Naturally, this means that all possible 2-character strings can be tried quicker than 3-character strings, and 4 character strings will take even longer. Unfortunately, thanks to Moore’s Law, “longer” means “a few milliseconds”. 8 character passwords are usually the minimum, but by some estimates, even that is not sufficient. To make for an even bigger challenge, us humans tend to have a hard time remembering random letters and numbers. This leads to bad habits such as using the same password on multiple sites, and that can cause its own problems.

Continue reading “Introducing Diceware: Secure Passwords You Can Remember!”
Posted on

Data Analysis of The Streisand Effect

The Streisand Effect, for those not aware, is where an attempt to remove, hide, or censor a piece of information has the unintended consequence of publicizing that information more widely by way of drawing attention to it. It is named after Barbara Streisand, who once filed a lawsuit to have an arial image of her home removed from the Internet. In her case, it resulted in a flood of publicity and thousands of people viewing that image.

What happened here?

An individual took issue with a post that I wrote 8 years ago. The identity of the person and the content of the post aren’t relevant to this post, but what is important is that prior to this event, the post was sitting by itself, pretty much left alone except for for the occasional web crawler visiting it. The post would have stayed that way, except that the person who had an issue with my post decided to complain in a heavily trafficked forum. This resulted in the post receiving more traffic than the previous several months combined. Additionally, many more people were made aware of the contents of the post, which I’m fairly sure the person complaining did not want to see happen.

How about some numbers?

Here’s a graph of HTTP requests to that page over time:

Note the huge spike, when is when the post in question was mentioned. Approximately one thousand separate people visited the post in question during the spike in traffic.

Now, what did we learn?

Posted on

Notes from February 2015 Philly DevOps Meetup: Security Practices for DevOps Teams

As a service to the Philly tech community (and because folks asked), I took notes at tonight’s presentation, called “Security Practices for DevOps Teams”. It was presented by Chris Merrick, VP of Engineering at RJMetrics.

Security is a “cursed role”

  • …in the sense that if you’re doing a really good job as a security engineer, no one knows you exist.
    • It isn’t sexy
    • It’s hard to quantify
    • It’s never done

As DevOps engineers, we are all de facto security engineers

Some tips to avoid ending up like this [Picture of a dismembered C3PO]

Sense. This picture makes none. 


  • Security Principles
    • Obscurity is not Security
      • “A secret endpoint on your website is not security”
      • “Don’t rely on randomness to secure things”
    • Least Privilege
      • Do not give more privileges than are needed
    • Weakest Link
      • If you talk to an insecure system, you’re at risk
    • Inevitability

Security Types

  • Physical
    • Stealing laptops
    • Breaking into datacenters
  • Application
    • Any vector that comes through an application you developed
      • XSS
  • Network*
  • Systems*
    • Applications you didn’t write
  • Human
    • Phishing, social engineering

Server Auth

  • Reminder:
    • Authentication is who you are
    • Authorization is what you can access
  • Don’t access production directory
    • Good news: this is our job anyways
  • Don’t spread private keys around
    • Don’t put in your Dropbox
    • Don’t let it leave the machine you generated it on
    • Use SSH agent forwarding
      • ssh-add
      • ssh -A you@remote
      • ssh-add -l
  • Don’t use shared accounts
    • Especially root
  • Be able to revoke access quickly
    • Time yourself. Go.
  • We use Amazon OpsWorks to help us achieve these goals
    • Chef+AWS, with some neat tricks: simple autoscaling, application deployment, and SSH user management

Logging

  • “Logs are your lifeline”
  • When you get into a high pressure security investigation, you start with your logs
  • Capture all authentication events, privilege, escalations, and state changes.
    • From your Os and all running applications
  • Make sure you can trust your logs
    • Remember – they’re your lifeline
  • Have a retention policy
    • We keep 30 days “hot”, 90 days “cold”
  • Logging – ELK
    • We use ELK for hot log searching
    • Kibana creates logs and lets you monitor your application in real time

Deployment

  • Keep unencrypted secrets out of code
    • Otherwise, a MongoLab exploit becomes your exploit
  • Don’t keep old code around
  • Make deployment and rollback easy
    • More good news: this is our job anyways
    • When dealing with a security issue, the last thing we need a “hard last step” in order to get the fix out
  • IAM
    • Don’t use your root account, ever.
      • Set a long password and lock it away
  • Set a strong password policy and require MFA
  • Don’t create API keys where API access isn’t needed
    • Same goes for a console password
  • Use Managed Policies
    • To make management easier
  • Use Roles to gran taccess to other systems
    • No need to deploy keys, auto-rotates
  • IAM Policy Pro Tips
    • Don’t use explicit DENY policies
      • Keep in mind that everything is denied by default
    • Don’t assume your custom policy is correct just because it saves – the interface only confirms the JSON is valid
    • Use the policy simulator
  • Know Thy Enemy
    • People are out there scanning for AWS keys – treat your private key like a private SSH key

Bonus Tips

  • Set up a security page
  • Sign up for the US-CERT email list, and the security notification list for your OS
  • Other resources
    • OWASP – owasp.org
    • SecLists.org
    • Common Weakness Enumeration – cwe.mitre.org

Conclusion

  • What else should we be doing to keep our work secure? [Picture of C3PO in a field full of flowers]
Posted on

Setting up custom short domains in Bit.ly

What is a URL shortener?

A URL shortener is a service which takes a long URL and creates a much shorter URL which then forwards you to the original URL when loaded. For example, the URL http://bit.ly/18lZ8Ns, if clicked on, will redirect your browser to http://en.wikipedia.org/wiki/Cheetah instead.

Short URLs and the services that offer their creation have grown quite popular in recent years, as microblogging services such as Twitter limit you to 140 characters or less per message. In fact, some services such as Twitter offer their own URL shorteners built into the service for the benefit of their users.

The most popular of the URL shorteners is Bitly, so this post will be about setting up a custom short domain with Bitly.

Continue reading “Setting up custom short domains in Bit.ly”
Posted on

The Importance of Having More Than One Backup

Many years ago, I wanted to make sure my data was secure, so I purchased a fireproof media safe from a (now defunct) company called FireCooler. I thought it would be a good idea to have a UL 125-rated safe which could keep an internal temperature of less than 125 degrees over an hour long fire. I regularly made backups to DVD and stored them in the safe.

Well, sometimes the best laid plans can go awry, and that was the case the other day when I went to put something in my safe, and found that it was flooded with water:

IMG_3372 IMG_3374

How did this happen? Did something in the safe suck in tons of moisture? Did the basement somehow flood and not cause water damage elsewhere? To this day, I am still not sure. I did not see any evidence of flooding in my storage area–nothing else was damaged.

Before I switched over to WordPress, one person pointed out that the safe my have been insulted with “water glass”, specifically from US Patent US7459190:

Outer wall composed of water glass sodium silicate solution that is 40% solids, 60% water, and having a silicon oxide:sodium oxide ratio in the range of 2:1 to 4:1, calcium chloride, and an additive chosen from calcium oxide or calcium hydroxide […] After curing, water released from the solidified insulation can migrate to and leak from pinhole defects which sometimes occur in the plastic shell.

Patent US7459190

So that’s a possibility, but I am not a chemist, so proving such a thing would be beyond me.

The takeaway here is that I had backups stored elsewhere so no actual data was lost. I recommend that everyone reading this, if they care about their data, to do the exact same thing. Here are a few resources for backups:

Happy Backups!

Posted on

Git 101: How to Handle Merge Conflicts

In the last post, I talked about how to create a Git repository and upload it to GitHub. In this post, I’m going to talk about how to resolve Git conflicts.

Setting Up Our Environment

First, we’re going to create a Git Repository for the user Doug. Since I already covered that in the last post, I’m bring to breeze through those steps below:

$ mkdir doug
$ cd doug
$ git init
Initialized empty Git repository in /path/to/doug/.git/
$ touch README.md
$ git add README.md 
$ git commit -m "First commit"
[master (root-commit) d86a7e2] First commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md

At this point, we have a repository created for the user Doug. Now I’m going to clone that repository for the user Andrew:

Continue reading “Git 101: How to Handle Merge Conflicts”
Posted on

Git 101: Creating a Git Repo and Uploading It To GitHub

In this post, I’m going to discuss how to create a GitHub repo and upload (or “push”) it to GitHub, a popular service for hosting Git repositories.

What is revision control and why do I need it?

The concept of revision control is a system which tracks changes to files. In programming, that is usually program code, but documents and text files can also be tracked. Using revision control will give the following benefits:

  • You will know what was changed, when it was changed, and who changed it
  • Multiple people can collaborate on a project without fear of overwriting each others’ changes.
  • Protection against accidentally deleting a critical file. (revision history is usually read-only)

In GitHub, we store revisions in “repositories” or “repos” for short. As of this writing, the #1 service for storing Git repositories is GitHub. They offer free hosting for Git repositories.

Continue reading “Git 101: Creating a Git Repo and Uploading It To GitHub”
Posted on

Notes from “Scaling on AWS for the First 10 Million Users”

Earlier tonight, I had the pleasure of attending a presentation from Chris Munns of Amazon at the offices of First Round Capital about scaling your software on AWS past the first 10 million users. I already had some experience with AWS, but I learned quite a few new things about how to leverage AWS, so I decided to write up my notes in a blog post for future reference, and as a service to other members of the Philadelphia tech community.

Without further preamble, here are my notes from the presentation:

Continue reading “Notes from “Scaling on AWS for the First 10 Million Users””
Posted on

An American’s Visit to Sweden and Denmark

I found myself between jobs a short awhile ago, and suddenly had a few weeks of downtime. Since I had an open invitation to visit Sweden and Denmark from friends living there, I figured I would take the opportunity and head over. I took a few pictures, and noted some observations about those countries.

First, Know Some Locals

If you want to take a package tour and see the parts of the country that are tourist attractions, feel free. But you’ll get much more out of the experience if you know locals who can show you things that they think are interesting. I was fortunate to know both Pinky Fennec and Joel Fox, who were more than happy to host me while I visited.

Public Transit is Amazing

Subway Station
A subway station on the Hågsatra line

The train system in Stockholm is pretty extensive. Trains and busses run pretty much everywhere you’d want to go. Both systems used a wireless card that you could buy with a week’s worth of fare, and just swipe it at the turn style or at the front of the bus. Subway stations had displays above the tracks stating how much time until the next train would arrive. When bus schedules said that busses arrived on the quarter of every hour, they meant it.

It was also pretty much the same in Copenhagen, except I spent more time on busses. The bus service there was simply phenomenal. They had busses that would arrive every 8 minutes, and they meant it. I regularly commuted from a friend’s place on the outskirts of Copenhagen to the central part of the city every single day.

Getting from city to city was also fun. I rode on what amounted to the Swedish version of Amtrak from Stockholm to Copenhagen. It was a single train ride, about 400 miles in 5 hours. That’s an average of 80 mph, but with the stops we made I’d say we did somewhere between 90 and 100 mph most of the time. The train ride was exceptionally smooth, and several times when we started moving I thought that the train next to us was moving. Naturally, these trains were also on time.

Continue reading “An American’s Visit to Sweden and Denmark”