As electronics have become cheaper, and thereby more prolific machinery which use to be strictly mechanical are being replaced with electronic equivalents. Locks are no different. Electronic locks are both simpler to manufacture and offer features which are very hard to achieve with mechanical systems. One of the major benefits to electronic locks is the ability to use proofs of knowledge to quickly open a lock. Knowledge based locks are nothing new, the earliest known combination lock dates back to roman times. As with mechanical locks it is important that electronic locks do not allow an attacker to easily remove bypass the lock by removing the dial, keypad or lock from the door. However, electronic combination locks presented a new challenge that earlier combination locks did not face. Namely that of supplying magic pixies (electrons) to the circuitry powering the lock.
David Wang, the guy who has done some absolutely amazing research on Apple’s secure enclave technology recently reached out to me on twitter, asking if August had stopped leaking the firmware keys for their locks. Unfortunately this is not a question I can answer in 140 characters. I will provide a more detailed writeup on the multiple issue with the August smart lock sometime in the near future. However, in this article I will be focusing on the firmware keys used by August.
@jmaxxz Have they stopped leaking the firmware key?
— David Wang (@planetbeing) August 20, 2016
@planetbeing no simple answer for that.
— Jmaxxz (@jmaxxz) August 20, 2016
TLDR: Microsoft MVC has a ‘secret’ backdoor which is not very useful for developers or hackers.
Recently I was poking around in the Microsoft MVC codebase trying to figure out how to make my own bundler. While there I came across the following rather peculiar looking code:
If you have read my earlier article on the August Smart Lock you know it does not have a two factor authentication system in-spite of the claims of its creators. This article will be about an exploitable vulnerability in August’s authentication system. August was first notified of this weakness on December 19, 2014. As of writing this article, August has not fixed the issue (March 3, 2015).
TLDR: August really doesn’t have two-factor authentication, but what they have maybe good enough.
I recently got my hands on the new August Smart Lock, but not to put on my door (well at least not yet). Instead I was interested in the security of a product which is claimed to be “completely secure”. No joke their promo video says completely secure! By definition adding a second way to open a lock can only weaken the security of your house. Adding a new way to unlock a lock always reduces over all security as it adds complexity.
Sparkfun is an online store which sell , electronics for hobbyist. They also are my go to store when I need any small electronics (arduino, raspberry pi, etc.). Unfortunately while their store and service is great the security of their site leaves something to be desired. I am writing this article prior to disclosure, but by the time this is published hopefully Sparkfun will have addressed the weaknesses in their site. UPDATE: Sparkfun was very responsive and has taken actions to addressed all issues below :-D.
Working in software development I am always surprised by how often developers don’t understand the security model of the platforms they work on. In this article I would like to share with you some of the basics of browser security. The topic has a lot of depth but I believe if one understands several fundamental principle they will be far better equipped to build a secure site.
Sometime 140 characters is not enough to explain your point. Recently on twitter Troy Hunt [someone you should be following] said the following in response to my claim that asp.net mvc did not offer out of the box protection from CSRF.
@jmaxxz classic ASP (which this article refers to) has no anti forgery token paradigm, MVC *does*. Web forms has it in the project template.
— Troy Hunt (@troyhunt) April 20, 2014
Before I go any further let me define IMO the characteristics a good CSRF prevention system should have:
- Should prevent CSRF in ideal conditions (you and your users never ever get pwned)
- Should not require tokens to remain secret forever
- Should be on by default for all unsafe requests (see 9.1.1 of the http spec)
When attempting to prevent a CSRF attack on a website using asp.net MVC, and asp.net webforms. The developer is responsible for adding the following to their forms <%= Html.AntiForgeryToken() %> and actions which should be protected must be tagged with the [ValidateAntiForgeryToken] attribute. This system is built on an opt in approach. By default all actions on all controls do NOT protect against CSRF. Further more
because it is a direct reuse of the webforms code base it only works for form submissions. Which is great if that is all one does. However, in the last several years of development I have used less and less forms, and more and more json based services. For the sake of argument lets say you did follow the Microsoft line, and only ever use form submissions, and never forgot to tag your actions, then you are safe right? Nope, because the tokens are generated are essentially an hmac of the current user’s username they are not in anyway tied to the user’s current session. This means that even if the user logs out there CSRF tokens from the previous session are usable by an attacker. It does not matter what you do as a user, you can change your password, log in log out clear your browser cache, none of this will invalidate any previously stolen CSRF token. This leads to the undesirable characteristic of once compromised always compromised. Yes, you are safe. Troy hunt pointed out to me the implementations in webforms and mvc are different. MVC’s implementation of CSRF tokens (at least in the latest version) does not suffer from the same weakness as webforms which did not invalidate the tokens between sessions.
So of the three characteristics of a good CSRF prevention system asp.net’s system
only has the first one has the first and second; It prevents CSRF in ideal conditions. Sooner or later a CSRF token will be compromised because a user logs in from a public computer, gets a virus, is the victim of a main in the middle attack, or the site has an XSS vulnerability. This is not a question of if only a question of when.
The third characteristic (secure by default) is achievable in Microsoft’s ecosystem through the use of a custom filter that automatically requires CSRF protection on all unsafe methods similar to this: https://gist.github.com/jmaxxz/3190357
Lets talk about software development. Recently I have worked to get a team I am part of using a new development methodology called BDD, or behavior driven development. If you develop software at all, and have not been living under a rock for the past 10 years you maybe wonder if BDD is anything like TDD.
The answer is a little, but with some key differences. First and for most unit testing is about function/method level validation. Secondly it is an internal development practice (your stakeholders *should* not care if you do TDD). BDD is about a higher level of validation. It is about verifying the application works. It is also something your stakeholders should care about.
When do you develop software using BDD before you ever write a line of code you must write what is called a scenario. A scenario is nothing more specification or requirement defined by example. There are a near infinite number of ways one could go about doing this, but I am a strong advocate of using something called Gherkins. Gherkins is nothing more than a grammar for documenting the preconditions, key actions, and expected outcomes. [This will be covered in a later article.]
After the scenario(s) are documented development can start. As these scenarios are really the solidified requirements for the application it is fitting that they also become the acceptance tests which the application will need to pass. The first problem which needs to be solved is how to turn scenarios into an executable set of tests. Each scenario is made up of steps. These steps are converted into executable code which can drive the application (through the real ui). As the driver is being developed the code make the steps succeed is written.
Once a feature is implemented, you should have an automated set of acceptance tests that prove the applications works. Which frees your testers, and quality assurance engineers up to worry about how the application works and not if it works.
What maybe surprising to you though is the automated acceptance tests are not even the biggest value of BDD. The biggest value of BDD is the scenarios give developers, stakeholders, and business analysts a framework for communicating about what will and will not be implemented.
Assessing someone’s technical skill level is a quite difficult thing when one only has 30 minutes. Let me start by saying I am no expert at how to do this, but I would like to share my favorite interview question for assessing a developer’s experience the question is targeted for C# developers. However, most of it the question is applicable to Java developers as well. Read the full post »