sullivanmatt

I want to be clear about the use case that the enterprise port knocking solution is trying to solve: it's an additional control that would not normally even be in place. In most setups, you are exposing some sort of relay to the internet, through which your users can access the services after authentication - such as an SSH bastion host or a VPN. The IP based whitelisting mechanism is simply a layer to allow you to not have to compromise and expose anything to the world wide internet. The actual authentication and authorization mechanism is the certificate-based set of SSH connections.

There is one network entry point per deployment of our app infrastructure (eg. US and EU deploys), so the lambda does go and update both security groups simultaneously to allow the requestor's IP to hit either if they would like. If you wanted to, you could certainly make it more fine-grained than that, but the goal was simply to cut off the majority of the Internet from these mechanisms as an extra protection layer. There are all the other protection mechanisms (e.g. the mutual certs) to actually protect and authenticate the connection itself.

For web apps, we simply front using an OAuth2-aware proxy. Back in the day, we used this: https://mattslifebytes.com/2018/08/07/protecting-internal-ap... Now, we utilize Kubernetes for hosting most production internal apps, so we run the oauth2-proxy Helm chart (https://github.com/helm/charts/tree/master/stable/oauth2-pro...) to handle verification of identity before sending traffic back to its destination service. Conceptually similar, as auth has to be completed before the request is sent to the back-end.

Most people in industry I have talked to just do VPN for all traffic, even though that seems crazy to me to route your Hacker News traffic through your prod servers' networks (gross). Normally a compensating control would be appropriate, but if you are pursuing FedRAMP Moderate ATO like we did, you can only get away with a pretty small number of alternative implementations, and only Low findings can be easily accepted by the Federal stakeholders. It's tough.

The control I listed, NIST 800-53 SC-7(7) [which is a part of the FedRAMP Moderate suite of controls], specifically requires you implement a technical control such that your users cannot split tunnel.

As I alluded to in the post, it's a legacy viewpoint. These customers hand you a 300+ security questionnaire that hasn't been updated in 10 years. When you tick the 'VPN' boxes, alarms sound, but they are thinking about the term 'VPN' in a different context, like employees accessing a network file share. But what we really have is a Bastion host (aka jump box), which is fundamentally different. By not saying you run VPN software, the conversations shift significantly, especially when dealing with the F100 banks and the like that may not be as familiar with modern cloud architectures.

Thanks all for your feedback. I have removed the images to improve readability, especially for mobile users. The post was originally written for an internal blog where we have a GIF-heavy communication culture, and I probably should have cleaned it up a bit more for general public consumption.

Here's the scoping doc: https://iowacourts.gov/static/media/cms/Rules_of_Engag_E9D80...

Some highlights include authorization to attempt entry by tail gating, lock picking, place devices once access has been gained, etc. It's a total vindication for Coalfire (IMO).

Enterprise customers want the ability to pull their keys and walk away from a platform, sometimes with very little notice.

A made-up example: assuming Brexit occurs, EU customers of a London-based SaaS chat service may no longer wish to keep that data outside of the EU. The easiest way to wipe it out quickly? Pull the key. Or perhaps your government is trying to compel you to produce data that you believe they have no right to. Some companies would rather have the option to destroy it and face the consequences, whatever they may be.

Yeah, I got the same. Might need to built some sentiment analysis in there too.

I work for one of the companies mentioned, and we don't / did not pay for the name drop. Maybe one of the others did, but we did not.

This is the EDGAR system that was breached: https://www.edgarfiling.sec.gov/Welcome/EDGARLogin.htm

Up until two years ago, that page used to recommend a minimum browser of either IE 5 or Netscape Navigator 3. If you look at the source and use of 'htm' extension, all signals point towards it being created using an extremely old version of Microsoft FrontPage (2000?). And that's not particularly uncommon on the government systems for unsexy tasks like filing regulatory reports. Limited IT staff and budget, paired with an unimaginable amount of red tape, lead to this type of breach. Also good InfoSec talent usually doesn't stay at the Federal space long. Anyone with strong skills within 50mi of the beltway can make $25k+ more per year by going private sector. Finally, let's not forget a much more limited talent pool is available because, in many situations, these jobs require you to be a U.S. citizen.

I would argue that the SEC breach is only a symptom of a much more systemic problem with IT at the Federal level. To fix it will be extremely costly and painful. To do nothing will be extremely costly and painful.

You are correct, but if you actually have the source and can compile a binary from that, it is much easier to evade detection. As you might imagine, the gnarly things you have to do to add malware to existing software often trigger detection mechanisms.

I see 16 bytes of hex after the anchor slug for the encryption feature, e.g. for 'https://nofile.io/f/86JiUNYM6QK#5827800f46cef978', the key is '5827800f46cef978'.

The key is absolutely does not contain enough entropy, because your key material is only comprised of the ascii-printable hex chars converted into a byte value. So instead of a byte having 256 different possibilities, a byte now will only be one of 16 values. Bruteforcing these keys would be incredibly trivial. To decode the hex into actually random key material, you would have needed to do something like hexToBytes("5827800f46cef978"), which would yield a correctly random byte array of [88, 39, 128, 15, 70, 206, 249, 120]. Note that this is half the proper key size required for AES-128.

I also want to echo the concerns already voiced by others in saying that key material needs to be generated from a strong random provider, and not just from the hash of the file.

I say this in the interest of privacy of those who might use your service, so please don't take any offense: please disable the encryption feature entirely until you can get assistance from someone with extensive experience in implementing crypto, because as it exists now, the implementation is fatally flawed.

Where we could, we certainly tried to avoid it. The bigger problem is just the opportunity cost with regards to resources involved with the transition.

Well, the codebase existed long before HTML5 was supported by pretty much any major browser (remember, HTML5 didn't really stabilize to the point an enterprise could use it until 2012). So you have to continue adding to it while you wait for HTML5, and its popular frameworks and libraries, to come to fruition. Oh, and we're an enterprise SaaS app, so all of our customers run on whatever version of IE was released 4 years ago.

Yes, and we have been for a while. But as you can imagine, you can't stop adding features to your existing product and expect to survive. 1M lines of code isn't something you can port quickly.

I work appsec for a company that provides a (primarily) flash-based web platform - Apache Flex, specifically. What people don't realize is the extreme cost of porting things like this to HTML5. We have nearly 1M lines of ActionScript. The browser makers and Adobe are aware of deployments like us, and that's why they can't just pull the plug. We don't need a few months to fix this problem, we need years.

Cousin. Elon is the chairman of the board.

OP did not read the article correctly. Untrue.

The documentary is "Inside North Korea", for the curious: https://www.youtube.com/watch?v=mxLBywKrTf4

The author of this article posted a follow-up a few days later, and more or less acknowledged that he should have done a bit more vetting of this "research" before going to press. The follow-up worth the read: http://www.citylab.com/weather/2015/07/4-key-problems-with-m...

The Microsoft of today is not the Microsoft of 15 years ago. Nadella has a long history of embracing openness, especially with the Cloud Services division he was heading until his appointment as CEO. I think the open-sourcing of the .NET platform is a big testament to that. The old Microsoft guard would have ran the company into the ground before doing that.

I'm going to be making some assumptions here, with assumption #1 being that you would be based in the US.

It wouldn't be illegal, but I think you'll have serious issues with viability. Concern #1 would be when / where / why you would distribute my encryption keys. For example, I am a SaaS, perhaps small, perhaps big. You are a one-or-two person startup holding my encryption keys, and the FBI comes knocking with an NSL. You will not have the money / resources to fight it, so you'll turn over those keys without telling me (as you are required to by law). However maybe it was a BS request, and maybe had I known about it I could have fought it with my A+ legal team.

The other issue is one of data mutability. If you are just storing files, there is some merit in separate key storage. However, if your SaaS does something with that data (converts it, processes it, moves it), then those encryption keys will be right back in the hands of the company doing the data holding.

Finally, there are very few companies that care enough about encryption to actually do it, and those who care that much about it probably won't be willing to ship that functionality out of the company.

(A bit about me: I am a webapp security / crypto guy at a mid-sized SaaS company)

Yep, example does not work for HTTPS users of GitHub. I use HTTPS everywhere, so I'm always defaulted to HTTPS where available.

I will start by saying that the site color scheme is pretty sharp for my eyes. I think you'll have a more polished look by having the background be white with a more neutral color palette.

For the extension itself: I like that it doesn't call out for information unless called upon, but if I ask for information about a site, I see no reason for you to have to collect the full URL and POST it to /track. That could lead to unexpected data leakage (as some URLs could be sensitive). You should probably get those API calls over to using HTTPS as well.

Also with every lookup, my console gets the log message "asdf", which is kind of weird. One thing I noticed is that the extension is pretty slow to get information. It appears it calls out for each item individually, and this leads to seven unique calls to your API that could be condensed into one request / response. If an API call fails with a 500 error, the entire stacktrace is dumped to the user. You'll want to disable debugging mode in your Express app to ensure that doesn't happen.

Since these APIs are public, you might want to consider rate limiting by IP, or you might find that your extension isn't the only consumer of them. A free and open WHOIS or Geolocation API that responds with JSON could be abused by other app developers, and having that already around moves the cost from them to you.

Hey stefanom, fantastic game. I see your website is having some trouble keeping up. You should sign up for the free version of Cloudflare and put your website behind it - then you'll not have nearly the trouble with the traffic load.

(I'm not affiliated with them in any way)

Collecting the session IDs is not illegal, but yes, using them would be.

(but of course courts have sent people to jail for much less...)

Since none of the existing replies go into technical detail, I'll add a few points:

E-mail is sent via the SMTP protocol, a protocol that made perfect sense in 1982. Since then, changes have been hacked together and the protocol has been bastardized beyond recognition to achieve various goals.

For example, if you want to transmit messages via an encrypted channel, you'll use the STARTTLS mode (tacked onto the protocol in the mid 2000s). But even if you are using STARTTLS, the server is likely not actually validating the certificate, as very few really do (even Google Apps / Gmail doesn't seem to check, as far as I can tell). So a MITM attacker could just set up their system to answer with a self-signed certificate, and there's a very high chance the client sending the message is going to go ahead anyway, even if it can't verify that the server it's talking to is the real SMTP server for example.com

Additionally, we've had a serious problem verifying that the sender of an e-mail is legitimate. In 2006 SPF (Sender Policy Framework) was proposed, which allows a domain to declare what IP addresses can send mail from it. However using SPF breaks things (like Gmail's ability to allow you to send from another non-Gmail account, for example) and almost nobody uses hard-fail mode to reject mail based on SPF. In 2011 DKIM (DomainKeys Identified Mail) was officially standardized, and this security add-on allows the message to contain an RSA-signed header vouching that the "real" example.com generated the message. DKIM is a really big step for e-mail authentication, and is really starting to see wide adoption. However, many mail providers don't check for the DKIM header on receipt, thus leaving their users susceptible.

Other grossness includes the actual message transmission schemes - using multipart messages with base64-encoded attachments, all encoded (typically) in the quoted-printable encoding. Again a great method for the late 80s, but completely, totally, 100% inappropriate for modern communications. Base64 encoding an attachment also causes the attachment to grow by roughly 33%. Client software has to be incredibly complex to deal with all of the bastardized, non-spec implementations of message boundaries, character encodings, etc. The standards are there, but are complicated and ripe for accidental or intentional abuse. And, finally, messages have to be pretty grossly constructed to support unicode (this is an example UTF-8 subject line: =?utf-8?B?Hello!?= ).

The entire protocol needs a ground-up re-write. In my opinion, a lot (perhaps all) could even be borrowed from HTTPS. Imagine just sending e-mail by using a REST API, authenticated by utilizing client-side certificates. But that's probably just a pipe dream :)

I haven't been able to find anything stating that the Black Hat conference is shutting down (which is very different than dismissing the GM). Can you provide your source for that information?

Central Iowa has a growing tech / startup sector that is home to many new tech companies. Cost of living is insanely low. I live in Ames, Iowa and work for a medium-sized tech company founded in 2008. Salaries here are comparable to what you'd find in Minneapolis or Kansas City, but with an even lower cost of living. If you're going to bootstrap a startup, Central Iowa is the place to be. Lots of talent and super low costs.