steakejjs

Lcamtuf notably found several ELF Parsing bugs in file, that appeared may have been exploitable.

The work he has been doing with AFL and googles big fuzz farm, focusing on utilities that are used daily without thought is insanely important, imho

The first way I did it was just read the file, parse the json, check for nulls, and print. Then I piped this to a file. That is too boring though.

The next way I did it was with Vim replaces. There might be sexier ways of doing this?

1) A big replace to get rid of all the junk.

    %s/\%Vemail.*creditcard/creditcard/g

    %s/\%V.*creditcard.*null.*//g

This Vim flow is the exact thing I do every week or two at work when building the Chrome HSTS preload list into our product. Anyone know the sexier ways to make this really really fun?

I should note to those not super familiar with vim that may try this, my vim commands are over a visual block (the json string), since this was in the same file as my code.

It might be extremely valuable for Google to prompt you, while riding in your driverless Tesla, to make a stop at a Krispie Kreme on your way home.

What if you are an experienced engineer talking to another experienced engineer ?

Seems to me if someone writes bad code when they SHOULD be writing good code, code-shaming might be in order.

I'm all for being nice and understanding. Everyone programs at a different level and I may not write code that is as good as I think, but some code is just obviously bad...and constructive criticism (if willing to be accepted) might help

Nginx and net/http has worked wonderfully for me. Nothing fancy is necessary.

After reviewing the code it looks like I was wrong. The code from the tutorial won't provide any encryption for your sessions, only integrity.

In order to encrypt the values in the session, rather than just encode you have to do a NewCookieStore([]byte("HMACKey"), []byte("CipherKey")) instead of a NewCookieStore([]byte("HMACKey")). I guess to answer your question, separate keys.

https://gist.github.com/steakejjs/6c17f07c4ca72115bfec

Here's a gist that shows a regular session, created with NewSessionStore([]byte("something-very-secret")) having the value's inside recovered easily.

The strings "foo" and "bar" are pretty easy to spot in the base64 output

I actually wrote a tool[0] to attack gorilla sessions that are mentioned at the bottom of this, and gave a talk on some security functions in Go.

The big take-aways from my talk. Go doesn't have a lot of unsafe functions.

HTMLTemplates package and exec package are very resistant to common web attacks, so much so that I had trouble writing vulnerable code to XSS and RCE

As for the tool that attacks Gorilla Sessions, I found a lot of people on github who were not initializing their session securely. Most people in the first 30 pages of github search were doing it wrong. This is most likely a pretty widespread issue. It seems they didn't realize this was an AES key...The blog post is not completely correct saying it will be used for an HMAC. It will...but it is also used as an AES key.

[0] https://github.com/steakejjs/G2B2

They are technical.

Brushing up on:

K&R - The C Programming Language

K&P - The Unix Programming Environment

K&P - The Practice of Programming

Kerrisk - The Linux Programming Interface (Not light reading)

Even though it is mostly review, reading code and seeing commands that K&R&P run has actually helped my workflow, code quality, etc.

Highly recommend re-reading if it has been a while. Even things like variable names have noticeably improved since beginning re-reading.

And, the Linux Programming Interface....is huge. There's always more to learn in there.

Google has a big fuzz-farm and Project Zero looking for this type of thing and even they did not find Heartbleed years ago. They are nabbing tons of bugs but there are many that are simply buried.

This seems to me a bit like when you do a maze starting from the finish and it is, for whatever reason, trivial to go from one end to the other.

It is neat that it is 2015 and fuzzers are cool again, though.

The new stuff happening in the PHP space is really really awesome.

HHVM + HACK + XHP is an entirely different experience compared to writing PHP. Code can actually be very clean and lots of bugs can be found that may have previously gone unnoticed + performance benefits.

Just wanted to say FB is doing an exceptional job with these projects.

Sounds like we were always on the same page...

I never said an attacker can't do this. I'm saying an attacker can't do a s/https/http and have a user end up at an HTTP login page, where the attacker can sniff credentials.

Relay what credentials from the HTTP connection ? There are none...

It sounds like you are talking about creating a phishing page and injecting it, hoping the user enters their credentials, and stealing them. I already said this was possible.

Not all traffic. Amazon has a separate SecureOnly cookie for access to their trusted pages that isn't sent over HTTP. Without that cookie not all traffic can be proxied.

Right, but you get a redirect to the https login page with an http login URL.

An attacker can attempt phishing with HTML/JS injection on a HTTP page but an attacker cannot get a user to be looking at Amazon's real login page over http.

I think the problem here is the term ``SSL stripping'' was used and it may be kind unclear what MITM attacks is actually encompassed by it.

The OP wrote ``An attacker can easily steal passwords with SSL Stripping''. If OP meant he can easily steal passwords by basically a s/https/http on all urls on the page, OP's wrong. The attacker needs to create their own fake login page, present it to the victim, and hope the victim falls for it

No. SSL stripping is an attack where you prevent a user from upgrading to an HTTPS connection. That isn't possible here.

Many sites have multiple tiers of authentication. For example viewing items to purchase is over HTTP but to actually checkout or manage your account requires you to go to HTTPS and reauthenticate on an HTTPS login page. Always. After this you are kept on HTTPS for the trusted actions. Amazon only does shopping over http but trusted actions are all HTTPS.

This has been amazons authentication scheme for years and it is actually the same as googles (where Google does have http assets, they force a reauth before going to https only stuff).

The most an attacker could do is inject code on http pages, annoyingly add things to cart, purchase items with 1 click purchase (inject javascript that clicks the button) and eavesdrop on all items purchased (quite serious).

BUT they cannot perform SSL stripping if Amazon doesn't do any auth over HTTP. An attacker could do some phishing like attacks to try to convince the user to put their password in at the wrong time, though.

What's wrong with being more than one thing. They are shaking up A LOT about how we currently think about the ``energy'' models. I think batteries are going to do wonder for countries that don't have a ``grid''.

The coolest thing to me about Tesla is the car is becoming decoupled from what powers the car. It's still electricity but if my power provider was to switch to nuclear, solar, people on bicycles, or coal It would be transparent to me.

I think it would be hilarious to see fictional "failed" historic YC apps, especially those that made it big in their time.

I don't understand your issue with hardcoded salts. It essentially works the same way as an HMAC. It is some secret material that further complicates the attackers job...It doesn't mean they react to a successful attack in a different way.

After hashing the password he is storing the hash along with the users random salt, not retroactively applying the salt a second time.

I actually think Terry could provide a lot of value if he was able to provide training in system engineering. The experience he has is invaluable. I'm not sure what his plan is, though....

In case you're thinking this is THE BUG that should have been released today, I don't think it is. While serious, I saw this on github several days ago. I've also seen two others this week.

This also isn't internet shattering, or whatever. Maybe it's just me but I expect a little more from all the talk about this bug.

Would a possible example of a large magnitude event be the 2012 Virginia Derecho[1] ?

Does anyone remember this evening as a day of large outages? I wasn't able to experience the event as an internet user having lost power. This is the type of event I would EXPECT to get a big magnitude.

[1]http://en.wikipedia.org/wiki/June_2012_North_American_derech...

Yeah, it is only base64ing the woffs. The reason I post it is that it has all the benefits of this project (only CSS) without the downsides (being ridiculously hard to use).

You can already do regular fonts in pure css. See. Here's open sans in pure CSS. https://github.com/steakejjs/OpenSans-CSS

I've actually found its much nicer using this in my projects than using a font cdn or self hosting woff files.

I do like the minimalism of css rules to creating this font as opposed to having a giant data section. It's pretty neat

What do you mean? ``If you can do something malicious''.

Browser extensions have a lot of abilities. People install browser extensions with no idea what they actually do, when content scripts in chrome extensions can scrape all your data on all sites you visit. There is no way to whitelist extensions to only some URLs and blacklist them from others.

If the browser is an OS, extensions have A LOT of abilities to avoid SAMEORIGIN policy, skirt CSP rules, and much much more.

Bottom line, if your browser is an OS, extensions can be malicious just like regular software.....whether or not you have NPAPI support or whatever else.

I actually began working on the exact same thing within the last month or so in my spare time.

Having competed in the CCDC for 6 years in college, I found it pretty insane when I saw that employers don't use real hardware during interviews.

Looks like I picked the wrong side project now this team is working on it. However, interviews are broken enough that there is plenty of room in the space =]. Can't wait to see what you launch.

In case people are interested in the under-the-hood. I just dug in a little bit and it looks like a library is used that automatically generates IV for each encrypt, and automatically uses your passphrase, passed through EvpKDF as the key.

SHA3, Rabbit, and whatever EvpKDF does, I don't actually have time to look at that.

Be carful not to forget reading off a semi-colon. Syntax counts!

Great post. I hate interviewing. I think a lot about it since I'm the type of person who performs horribly in an interview call when some person I've never met is asking me trivia questions on speaker phone...

One thing I wonder. Why are people being interviewed for technical positions in a google doc or whatever fake coding environment? Servers are cheap.

If you have to go the way of the technical phone interview, doesn't it make more sense to have both (interviewer and interviewee) parties SSH into a server and work together on some type of problem for an hour? The interviewer can even watch the candidate program or work in screen. This type of interview isn't perfect, but closed book "Programming Jeopardy" style interviews are just worse in every way.

No it is even true for security things BUT the authors need to have no problem taking a dose of humble pie and labeling the project as completely insecure.

I don't see anything wrong with writing security software that is insecure as long as you don't pretend it is secure....

Wolf is 100% correct. These details make it sound like this product is insecure. We definitely don't want ecb mode or a weak kdf like 1 round of sha256 with no salt.

BUT before anyone lambasts this guy, it's good the author posted so mistakes can be learned from the feedback, that way others get exposed to the issues, and less mistakes are made in the future. In my opinion, there is too much hate for people who make mistakes when writing code, when in reality that's how you learn. Few people learn all the theory first and THEN how to build it, it's often learn to build then the theory.