Saturday, March 25, 2017

Securing your internet privacy

On the 23rd of March 2017, the US Senate approved a bill that would allow internet service providers (ISPs) to sell information about your internet activity.
This coming week, the House will vote on the same measure.

I believe this is a very damaging act. Your internet activity should be private, just like your library card activity and your movie rental activity.

There are a few things you can do to protect your privacy from your ISP today. See below for more of my favorite general privacy and security links.

I always recommend using SSL/TLS as much as possible. Install the EFF's HTTPS Everywhere browser plugin. This is good but it will not completely blind your ISP as they will still see the IP address and domain names of who you are contacting.

For better protection, use a reputable VPN service. This is not too complex but it will cost you money. I'm still investigating my VPN options, so I'm reluctant to make a recommendation now. I'd prefer to set up a VPN on my home router so all my devices are protected when at home. I'd also like to have the VPN exit in Europe to get GDPR privacy protection.
Here are a few links to get you started:
ARS Technica's in-depth article on How to stop ISP's from selling your data.
The impossible task of creating a "best VPNs"list
TechRadar 10 best VPNs

Finally, here are some good general resources:

The Electronic Frontier Foundataion is a great resource for security and privacy. They do HTTPS Everywhere, Privacy Badger, and have the Surveillance Self Defense site.
You may want to consider using the Brave browser to help with ad-blocking.
Keep your browser and OS up-to-date.



Sunday, September 11, 2016

TSA keys are similar to Federal encryption backdoors

The TSA has long had master keys for each type of TSA padlock. Stolen keys have purportedly been available for some time, but someone used a picture of the TSA keys posted to the Washington Post to create 3d printable keys.

When any organization proposes that governments be allowed to have extra keys to citizen's encrypted traffic, this is exactly what we are going to get.

Any crypto system that has multiple keys is more vulnerable than a system that has one key.
And protecting keys is hard if you have to distribute them.



Microsoft Natural Keyboard

I've used this keyboard since 1999.
Today I took it apart and cleaned it up. I'm not going to show you pictures from before. But here are some shots after.
Disassembled

I ran the keys through the dishwasher. That cleaned them up nicely. The rest of the keyboard had to be wiped down by hand.
Pieces. The dishwasher cleaned up the keys nicely.

I'm hoping I can get a few more years out of this keyboard. 

Saturday, February 20, 2016

BSides Slides

BSides Slides

Securing the Software Engineering Process slides were presented at BSides Seattle on February 20, 2016. They have also been presented at a few other events.

These slides are my own work and are not the property of my current employer, whoever that might be. I'm releasing the slides under a Creative Commons license. Feel free to discuss the ideas within. Please don't re-present the slides as your own. I'm happy to present these slides to any engineering organization. Contact me if you'd like it presented.

Please enjoy.

Thursday, January 14, 2016

Interviewing in the technology industry

The following is an article that I wrote for a young relative just out of school trying to get their first job in the tech industry. It's not specifically about security, but it applies to most software engineering jobs.

The interview process is multi step. First, you need to get a recruiter or HR person to notice your resume. Then you’ll have to pass at least one phone screen, then you’ll have an in-person interview. It’s a chain, so you have to pass every single hurdle to get a job. You can’t screw up any of them. Here are some strategies that I find work.

  • Resume
    • First priority: Your resume is the first impression of you. Make it the best you can.
    • Keywords: Most automatic resume robots just read keywords. If you don’t have the right keywords, you won’t get noticed. Keywords are going to be “software Engineer”, Java, Python, C++, HTML, IP/TCP/UDP, Android, IPhone, virtualization, VMWare, Visual Basic, SQL, HTML”.Don’t be afraid to work “cloud” or "Amazon EC2” onto there if you have experience.
    • SWEngineer: Please call yourself a software engineer. I don’t like “developer”. A developer just writes lines of code. An engineer builds large and complex systems out of code. 
    • Projects: Put a blurb about what you did in class. Use words like “Member of a team that implemented …” or “Personally implemented …”. Just 1-2 sentences on each class is fine, but try to distill down what it is that you personally did. If your resume says "implemented BASE64 in C", I’ll ask you questions about the implementation. If you say “uh, I didn’t actually implement it, I wrote the header file with the APIs, the rest of the team did the work”, then I won’t be impressed. If your say “member of a team that implemented BASE64”, then I’ll ask about your team responsibility and how you dealt with the team dynamics. It’s also good if you can say “led the team that implemented BASE64”.
    • Projects pt2: If it is on your resume, it’s fair game for me to ask you about it. If you are asked about a recent project that is on your resume and can’t answer coherently, that’s bad. Make sure if it’s on your resume you can speak about it.
    • Keep a short resume: After 20 years, mine is only 2 pages. When I read 5 page resumes, I just get grumpy that they can’t distill down their experience for me. It’s really hard work to maintain a 2 page resume as you get more experience, but do it.
    • Experience: Every 6 months, touch up your resume with what you have done. What you’ll find is that the last project that took 4 sentences to explain and takes up 2 inches of resume space was really shiny at the time but isn’t nearly as cool as the newer thing you did. Feel free to cut older stuff back down to 1 sentence. I know you worked hard on those 4 sentences, but they don’t matter anymore, you have something shinier.
    • Complete: If the interviewer or recruiter says “I didn’t know you did that”, then you screwed up. Put it on your resume. Especially in the first few years out of school.
    • github: Put your github.com site on your resume. A technical interviewer who is really interested in you will look at it. Make sure that you touch it every so often. Maybe place a project on there and just work on it occasionally, even a website or a node.js project to do something silly.
    • LinkedIn: It's great to have your linkedin profile on your resume. In my opinion, your resume should be short and catch people’s attention. Your LinkedIn page should have more details about what you do and your passions. I update my linkedIn every few months.
    • LinkedIn pt2: Culture your LinkedIn profile as your professional internet persona. Everything you do there should be professional and polished and shine a good light on you. Collect powerful mentors on LinkedIn and make good connections. Don’t accept every connection though, stick with people you actually know.
    • Facebook, etc: As an interviewer, I never look at someone’s Facebook page. I don’t care what you do in your spare time. I do expect my HR people have looked around the internet and made sure that you pass a sniff test and are not a complete maniac. Facebook, etc. should not be embarrassing for you. (Duh)
    • Contact methods: As a security & privacy advocate, I never put my address on my resume. Only my phone and personal email address. And I think adding the phone is being generous. If recruiters want to contact me, first it should be via email (or LinkedIn) and set up a phone call for later. That’s what I do as a hiring manager and what I expect any recruiter to do.
    • Spelling/grammar errors: Don’t make them. Double check everything. If your resume is sloppy, I’ll assume you are a sloppy coder too. 
    • Resume format: PDF!! Yes, your resume needs to fit on 8.5x11 paper. Yes, it should look nice. But you will probably never send a paper resume to anyone; you’ll send it electronically. Make it look nice electronically and if it doesn’t look as good on paper, who cares. I greatly prefer PDF to MSWord or any other format. You can make hyperlinks out. And best of all, PDF is very good at looking the same no matter what viewer anyone uses.
  • Recruiters
    • Recruiters: Their job is to find qualified candidates but not waste the time of the engineers who will be doing the interviewing. They have a quota so they want to send you to a phone screen. Your job is to convince them that you won’t waste anyone’s time. Try to suss out what they think the hiring manager needs (see later) and convince them that you can solve that problem.
    • Technology: Recruiters often don’t have a technical background. To get past them, you need to be professional and polite and sound like you know what you are doing. If they do have technology background, then your job is still the same only now you get to talk deeper about technology. That’s even better.
    • Think like a recruiter: They will take less than 30 seconds to look at your resume. Make them be interested in you. Highlight personal projects and things you’ve done to make yourself stand out.  If you were a tech recruiter and had to speak with 20 uninteresting nerds per day, you’d want to find someone who stands out. Show some passion for some accomplishment of yours.
    • Think like a recruiter pt 2: Make your resume clearly state what you want to be. Many recruiters I speak with say that they don’t know what to do with schizophrenic resumes — like mine when I couldn’t figure out if I was a manager or an architect. Figure out what you want to do and make sure your resume reflects that.
    • Recruiter pt 3: They will likely ask you some canned technical questions. Don’t be afraid to say “I don’t know, can I get back to you after I’ve studied that?” They’ll be impressed that you admitted you don’t know and that you want to study for the job. 
    • College grads: Show enthusiasm and a willingness to learn. Clearly you don’t have much experience, so you need something to stand out. One of the best out-of-college hires I ever made was a person who just said “I don’t know” to a number of very hard questions. I hired her because she had enthusiasm and demonstrated a willingness to learn. 
  • Phone screen
    • Phone screen: Ok you made it past the first tier. Congratulations. The phone screeners job is to decide if you will waste other engineers time if you come in the office for a full loop. He doesn’t have a hiring quota, so he’s much more likely to reject you. On the other hand, he’s probably on the team and he knows better what skills are needed in a new team member.
    • Screener: Do some homework. Find his LinkedIn page. Don’t try to connect with him, just make sure you know who he is (don’t be creepy). Try to study some of the areas in which you know he works. Most likely he’ll answer questions in that area.
    • Engineer: The phone screener is likely already an engineer. He’s also likely to be someone you will work with closely.  He will know more than you and will ask hard questions. Find out what he does and what he needs (again, see later).
    • “I don’t know”: Don’t be afraid to say it. It’s not a sin to say “I don’t know”, but it is a sin to not try to know. “I don’t know, can you help me?”, or better yet “I don’t know the answer to that but I know about this small portion of it. I’d like to know how that fits into the big picture.” This is same as with the recruiter, but now you are in the technology world. Try to understand the tech as deeply as possible, that will impress the person.
    • Just out of school: If you are just out of school,  interviewers are looking for someone who can they can grow into a good engineer. The only way that they can know that is if you demonstrate the ability to think on your own. 
    • Code questions: I prefer to do thought exercises over the phone, not straight coding. However, Google Docs has made it easier for someone to see you code. Don’t be nervous about exact syntax, make sure you get the algorithm. If you realize you made a syntax error, correct it but don’t fuss over it. Think big picture.
  • Interview process
    • Interview: You made it this far. Congratulations. Each interviewer you see will likely report back to the manager or the next person right after your interview. Assume they communicate.
    • Format: I like five or six 45 minute interviews with different team members and a lunch with the hiring manager. Be prepared for different interview styles. Some people ask puzzle questions, some want to get to know you, some will make you write code.
    • Interview styles: Individuals interview differently. Be prepared.
      • puzzle-master: Asks brain puzzles to see how you think.
        • Try to show that you are analytical and think your way out of problems.
      • whiteboard coder: makes you write code on the board.
        • Try to show that you know algorithms that help you solve problems.
      • get-to-know-you: Discusses your experience and asks questions about what you’ve done.
        • These are the easiest interviews - or so you think. These folk want to see if you know everything you said you’ve done.
    • Resume: Take paper copies of your resume with you (Yes, I know this contradicts earlier advice about electronic resumes). If an interviewer walks in to see you without your resume in his hand, politely offer a copy. Many times, the recruiter sends an electronic copy to the interview loop. The interviewer (because she’s extremely busy doing other things) probably glanced at it but has spent less than 5 minutes with it. 
    • Blabbing: If there is a lull in the conversation or if they were unprepared and want to look at your resume, then start to tell them about your latest project or an interesting project while they read your resume.
    • Bio: Good interviewers offer to let you take a break or ask you if you need anything. The last thing you need is a full bladder or a dry mouth in a high pressure situation. Take them up on their offer for water or a bio break.
    • Hiring Manager: If you are lucky enough to get to speak to the hiring manager, then you are doing well.
      • Most important advice in this blog: Find out what pain the hiring manager has. Convince him you can erase that pain. If his problem is that the app is 2 months behind schedule and they need someone who can write SQL until the project ships, then you’ll be writing SQL for the next 2 months. If you can’t write SQL, ask if you can take workload from another team member who can write SQL. I cannot stress this enough. This will get you the job. Hiring managers are the ones making the decision. Impress them.
    • Interviewee/er: You as an interviewee are also interviewing them. If the team snipes at each other or is dismissive of you or anyone else or any red flags go up, you may consider saying no to the job. Dysfunction ain’t cool.
    • Finishing it up: I always like to say “thank you for your time” to anyone I interviewed, whether I plan to hire them or not. You should tell your interviewers, “Thank you for your time.” They are busy. They might even be annoyed that they have to interview a noob like you. If you are gracious and humble they’ll be more likely to hire you.
  • Misc:
    • Title: You’ll probably start off as a Software Engineer 1. You’ll progress to SW2, then SW3, then Senior SWEng. Then Principal Engineer or Architect or you can move into a management track. In a good org, there’ll be very good criteria on what it takes to move from 1 -> 2 -> 3. After that, advancement gets to be murky. Generally, to move up from Senior, you need to tackle a project no one else will tackle or build something amazing that no one else could build. Or demonstrate solid team leadership.
    • Title pt 2: My take is that title doesn’t mean much. Get some experience, find out what you want to do, then find a path to Sr SW Eng.
    • Salary: I’m no good at giving advice on this. Maybe you can look up local salaries on the internet.
  • Best advice Summary:
    • Find out a problem your boss needs to solve and solve it for them.
    • Be enthusiastic and eager to learn.

Thursday, February 5, 2015

Software Engineering Security part 6: Running External Penetration Tests

Engineering shops often won’t have the expertise or the time to do deep security testing on all areas of the product. Using external security firms who have specific security knowledge can extend security testing well beyond their own capabilities.

External security testing — often called penetration testing or pen testing — can be effective when the scope is well-defined and narrow. It is better to do four small tests on specific areas rather than one large test across much of the product. Two to three week engagements are relatively inexpensive and should be run once per quarter. Even four engagements a year are generally cheaper than a full time security tester.

Pen tests also grow security expertise in the organization. Dev and Test resources who participate in the pen test will have a deeper understanding of security issues.

To make the most of a pen test engagement:
  • Security contractors are very expensive. Be prepared to spend time before the pen test configuring the software, setting up the test harness and gathering documentation to make the most efficient use of their time.
  • Ideally a security test is run on full featured beta code about 8 weeks before the ship date. This will allow time to fix any issues found before shipping. This is not always possible, so run the test when you can.
  • Assign severity to the issues; policy should dictate action.
  • Many pen testers will want to inspect source code. The steps below outline a black box testing strategy in which source code is not needed. Inspection of source code is generally a longer engagement and should be a supplement to source code analysis used during construction.
  • Select an ethical pen tester. Ethical pen testers will obtain permission before engaging, document all steps, judiciously select targets, and report all findings.

To run a pen test, follow these steps.

Step One: Assign a pen test resource
Assign an owner for the pen test. This person will be responsible for writing the RFPs, configuring the test harness, gathering documentation, communicating with the contractor, setting up meetings, and other tasks. Expect these tasks to take roughly one third to one half time during the pen test.

Step Two: Focus on a feature
Select a feature that is exposed and has potential weaknesses that could be exploited. Consider features that have had known vulnerabilities or weaknesses in the past. Also consider features that have known deficiencies in test cases or a long legacy of different engineers. Specify the feature and the constraints in the RFP. Ideally, find a vendor with experience in the subject area.

Step Three: Involve feature engineers
Select engineers from dev and test to be responsible for actions during the pen test. Record roles and responsibilities during the engagement. Dev engineers are responsible for explaining design decisions, asking questions to understand the issues raised, and securing the code. Test engineers are responsible for understanding the source of the issues, writing tickets, and developing test cases around the issue so that no similar issues are found.

Step Four: Set up the scenario
Pre-configure and set up the scenario. If possible, configure VMs with the software and deliver those to the pen tester. Ideally, set up a cul-de-sac network that contains just the software under test and allow the contractor access to that network.

Step Five: Run the pen test
Schedule weekly meetings during the engagement. Involve the dev and test engineers and and make sure they understand the issues and can fix them. Focus on correct mitigations rather than implementation details at this point in time.

Step Six: Followthrough
Classify all vulnerabilities according to vulnerability severity and have them worked according to policy. Write unit tests to ensure that similar vulnerabilities don’t happen. Write test cases to avoid similar issues. Hold a postmortem lessons-learned meeting and spread the security knowledge through your organization.


Following these steps will build a more secure product, grow security knowledge in the organization, and develop better practices around secure development.

Wednesday, January 28, 2015

CVE-2015-0235: Ghost

The last two days have been taken up with the glibc ghost vulnerability found by Qualys. They have a good description and a good detailed analysis.
Essentially this is the old "parsing untrusted input" problem -- a value comes in from a dubious source and the code needs to be robust against an attacker who can choose arbitrary malicious input.

Vulnerabilities like this are hard to classify. It's almost certainly exploitable by someone who has a local account on a box. But determining if it is remotely exploitable is difficult. This is what is called the "cone of uncertainty"; it takes time to do the research and find out if any code paths are directly vulnerable. Starting at the vulnerable gethostbyname() functions and working out is time consuming.
Many times this week I have wished for a rough equivalent to perl's taint checking -- let me flag a piece of memory as "tainted", and allow me follow it through the system to an arbitrary function call.

Since vulnerability classification is the first step in determining actions, use attack modeling techniques to determine exploit vectors. Enumerate all the ways untrusted input can make it through the system. For example, an attacker may be able to input an IP address into a field in a web app. In this case, an IP address text field could trigger the vulnerability.
Once all vectors are enumerated, determine if mitigations are in place. In the case of ghost, only 1024 or longer inputs may be vulnerable. When that work is done, there should be fewer code paths to analyze.

As Qualys proved, there are many possible attack vectors. If they cannot all be analyzed in a short amount of time, then prepare for the worst case.
Weigh the risks before deciding a plan of action. Often the fix for a new vulnerability is not immediately available and issuing an incomplete fix is worse than taking a few extra days to publish the correct fix.
In this particular scenario, the risk of patching glibc is relatively small -- the code has been patched since 2013 and there is a definitive test case that can be run easily. It is prudent to issue a patch as soon as possible.
Given the classifications published earlier, ghost would qualify as a severe vulnerability.  Actions should be dictated by established policy.