4 ms·

I'm not sure if security didn't actually improve dramatically. Web frameworks seem to have SQL injection and cross-site scripting more or less under control the

I'm not sure if security didn't actually improve dramatically. Web frameworks seem to have SQL injection and cross-site scripting more or less under control these days. Cloud setups and containerisation should also help (servers are more easily rebuild and therefore more likely to be fully patched, infrastructure-as-code is easier to review, most servers/containers are only running one service etc.)

peterwwillis 10y ago
Patching is not easier now, and wasn't difficult before. There's more steps now, it's not easier to review. Look at it from the blackhat perspective. I don't care what the hell loops you're going through on the backend. If there's a 0day, i'm going to use it and it's going to work, because you don't even know about it yet, much less have a patch built into a binary pushed to mirrors that your Docker image building box needs to update to before you can rebuild your image and push it to your servers and do a maintenance window to switch to the new services. It doesn't matter if you are running in a VPS in a container in a virtual machine in an emulator, because I can still use an SQL call to dump everyone's passwords, or get voting records and account details for one of your political parties. If I execute code you're still going to get owned because you don't have security patches in your kernels and you don't use signed binaries (none of which are new technologies, btw). I would even go so far as to say you would never in a million years find exploited code in one of your systems because you somehow believe container apps are immune to basic vulnerabilities. Containers are just fancy chroots.
- SomeStupidPoint 10y ago
  I disagree with your assessment for two reasons: 1. Breaking up my app (eg, across containers) increases exploitation difficulty, because it's harder to chain weaknesses between parts of my stack. A weakness in the API layer doesn't let you run against the DB directly -- you either need to find a weakness in the interface between containers or use a container jailbreak exploit. You also have fewer system libraries to use, since the container only has those needed by either the API or DB, not both. 2. The frequency of rebuilding means that a lot of system components get patched faster. Sure, you can burn a 0-day on my app, and there's relatively little I can do about it, but all of my builds are <1week old, so you're using new exploits, not easy-to-get legacy malware. The point of security is always economics. So containers (and more generally, frequent rebuilds and virtualization) provide security by raising the complexity and freshness of exploits required. That's a non-trivial gain.
  - peterwwillis 10y ago
    Abstraction has never been a big barrier to chained vulnerabilities. And hackers do not rely on a dynamic linker or shared libraries to deliver their payloads. (Script kiddies do, because they're using some paint-by-numbers malware package) Any actual hardening of a system will more than secure it from "the excess of unnecessary binaries" that some people fear. So you're running brand new code on your production systems on a regular basis? Fantastic! I'll find a new 0day in the latest releases since those are the ones that have had the least review. If you're using an old stable build, the 0days keep working until one gets leaked, and then you just find another one. How do you figure containers raise complexity of an exploit? The exploit is of the app or the stack, but the container isn't part of the app stack. A container is literally just a way in which you run your app. If I can execute code, the game is over, in all container systems that don't prevent traditional exploits. The only thing containers make easier is namespaces, which is a white hat mitigation. Like locks on doors, they only keep honest people out. By the way, exploits don't really need to be fresh. Many exploits getting patched these days are years old, and some were patched years ago and a recent update re-instituted the vuln. You can resist 99% of attacks using 10 year old technology, but nobody implements it. They just say stuff like "I put it in a container!" and your boss is happy so everyone goes on with life.
    - cyberpunk 10y ago
      Containers make things a bit harder from a persistence view. There was a great CCC talk on pwning architectures which are just based on aws lambda this year [1], worth a look. 1: https://app.media.ccc.de/v/33c3-7865-gone_in_60_milliseconds https://app.media.ccc.de/v/33c3-7865-gone_in_60_milliseconds
- monksy 10y ago
  I completely agree with you and I find the ignorance in our industry mind blowing. The industry has pushed for sloppy dev practices (Lean/Agile) and has time after time claimed that all of the "extra" stuff like strict access controls and discipline "aren't needed features." Mongo DB security didn't come until version 3. VERSION 3. It was assumed you could just firewall it off and life is good.
  - threeseed 10y ago
    Everyone uses Lean/Agile now so calling effectively the entire industry sloppy is a bit stupid on your part. There is nothing in the project management process that forbids you from including security as a high priority or making sure the software meets certain quality criteria. Also where did you get the idea that security didn't come to MongoDB 3 ? You're talking nonsense.
    - toomuchtodo 10y ago
      > Everyone uses Lean/Agile now HN bubble generalization. Also, was the stupid part necessary?
- djrogers 10y ago
  > If there's a 0day, i'm going to use it Sure, but with the number of unpatched systems out there most black hats aren't paying (in time/effort or straight cash) for 0-days except for exceptional circumstances. 0-days are great for targeted attacks, state actors, and hack-for-hire/contractors, but for the everyday dude who wants a botnet? Why bother... Look at Mirai - that wasn't anything close to a 0-day and it had a huuuuge impact. Anyone running a similar botnet could be extorting hosts and providers to this day if it hadn't been used in such a public way.
- cyberpunk 10y ago
  I've run java apps on boxes that are several years out of date OS patching wise and have many bugs, explain to be how you'd exploit those? You'd need to: * Get through the CDN to hit origin * Get through the patched internet facing rproxies * Exploit the JVM to get code execution, while your target area is something like spring * Get a code exec on that box as the appserver user _THEN_ use your j33t exploit.. If an attacker is capable of doing that, then absolutely nothing you can do is capable of stopping them anyway. Patching is only important for your internet facing stuff, depending on your environment. I WANT to patch such systems, we all agree that it's poor practice to do so; sometimes life is unfair though and in the grand scheme of things I don't see any significant risk in this scenario..
  - peterwwillis 10y ago
    I worked at a company with that kind of app. It got owned three different ways. A user reported it after they saw it listed in a forum somewhere. It was mainly app vulns, not platform, but there were certainly things that could have avoided it. The system was just not hardened at all, and the devs were sloppy. Luckily they had basic network security best practices and so it was confined to frontend, but blah blah SQL blah blah MITM, still not a good situation to be in.
kakwa_ 10y ago
Security is not that much improved to be true. Docker is just a fancy chroot, a motivated attacker can escape from it, it remains far less secure than a freebsd jail or a solaris zone. Except maybe some somewhat safer compiled languages (rust, newer versions of C++), and a few interesting tools (like AFL), there was not much improvements in security mechanism in late years. SELinux is still so annoying that it's commonly the first thing disabled in many install. A large amount of sysadmins and developers still do a chmod -R 777, not fully understanding what there are doing. And in the area of micro services, the traditional 3/4 tiers architecture can easily be replaced by a clusterfuck of containers deployed in a flat network where it's impossible to monitor what is speaking with what. And it's much easier to make a mistake like putting a database on the Internet with no authentication whatsoever... What is more, because of containers, infrastructures tends to be far more diverse than ever: python, node, php, ruby, go, java, each with various version, from various distribution, with various libraries. Each of these environments must be properly monitored, but when you deal with thousands of containers, hundreds of technological stacks, with 3 or 4 versions for each layer, it becomes a nightmare. In languages that encourage bundling, Java with war webapps for example, I've rarely seen developers properly monitor security issues of what they ship. Too often I've seen only opportunistic updates. And in some extreme cases I've seen products shipping version of libraries 10 or even 15 years old. Containers being a way to generalize bundling, I don't see it being an improvement in that regard. Quite the contrary in fact. However, to be completely honest, new tools like chef/puppet/containers and new methodologies like Infrastructure as Code somewhat helped to be less frighten about updates as it reduces the risk/impact of something breaking in the process, no more 'don't touch it, it will break comething'. Even containers can help in that regard, it's easier to do AB testing, avoid downtime or put servers in maintenance with them. Fundamentally, some things are better, some things are worth, and in the end the security level has not really changed. And honestly, it's a truly frightening view. Software/Infrastructure security is becoming more and more important as sensitive operations are increasingly done through websites (ex: banking operation), private data is increasingly stored in the "cloud" and an increasing number of devices are now connected. Security flows are still as numerous as before, but their impact, once exploited, tends to be far greater. If it continues like that, something really bad will happen, exactly what is difficult to predict (massive data leak? major industrial disaster caused by a hack? an election being manipulated?), but it will happen.

peterwwillis 10y ago

Patching is not easier now, and wasn't difficult before. There's more steps now, it's not easier to review. Look at it from the blackhat perspective. I don't care what the hell loops you're going through on the backend. If there's a 0day, i'm going to use it and it's going to work, because you don't even know about it yet, much less have a patch built into a binary pushed to mirrors that your Docker image building box needs to update to before you can rebuild your image and push it to your servers and do a maintenance window to switch to the new services. It doesn't matter if you are running in a VPS in a container in a virtual machine in an emulator, because I can still use an SQL call to dump everyone's passwords, or get voting records and account details for one of your political parties. If I execute code you're still going to get owned because you don't have security patches in your kernels and you don't use signed binaries (none of which are new technologies, btw). I would even go so far as to say you would never in a million years find exploited code in one of your systems because you somehow believe container apps are immune to basic vulnerabilities. Containers are just fancy chroots.

SomeStupidPoint 10y ago
I disagree with your assessment for two reasons: 1. Breaking up my app (eg, across containers) increases exploitation difficulty, because it's harder to chain weaknesses between parts of my stack. A weakness in the API layer doesn't let you run against the DB directly -- you either need to find a weakness in the interface between containers or use a container jailbreak exploit. You also have fewer system libraries to use, since the container only has those needed by either the API or DB, not both. 2. The frequency of rebuilding means that a lot of system components get patched faster. Sure, you can burn a 0-day on my app, and there's relatively little I can do about it, but all of my builds are <1week old, so you're using new exploits, not easy-to-get legacy malware. The point of security is always economics. So containers (and more generally, frequent rebuilds and virtualization) provide security by raising the complexity and freshness of exploits required. That's a non-trivial gain.
- peterwwillis 10y ago
  Abstraction has never been a big barrier to chained vulnerabilities. And hackers do not rely on a dynamic linker or shared libraries to deliver their payloads. (Script kiddies do, because they're using some paint-by-numbers malware package) Any actual hardening of a system will more than secure it from "the excess of unnecessary binaries" that some people fear. So you're running brand new code on your production systems on a regular basis? Fantastic! I'll find a new 0day in the latest releases since those are the ones that have had the least review. If you're using an old stable build, the 0days keep working until one gets leaked, and then you just find another one. How do you figure containers raise complexity of an exploit? The exploit is of the app or the stack, but the container isn't part of the app stack. A container is literally just a way in which you run your app. If I can execute code, the game is over, in all container systems that don't prevent traditional exploits. The only thing containers make easier is namespaces, which is a white hat mitigation. Like locks on doors, they only keep honest people out. By the way, exploits don't really need to be fresh. Many exploits getting patched these days are years old, and some were patched years ago and a recent update re-instituted the vuln. You can resist 99% of attacks using 10 year old technology, but nobody implements it. They just say stuff like "I put it in a container!" and your boss is happy so everyone goes on with life.
  - cyberpunk 10y ago
    Containers make things a bit harder from a persistence view. There was a great CCC talk on pwning architectures which are just based on aws lambda this year [1], worth a look. 1: https://app.media.ccc.de/v/33c3-7865-gone_in_60_milliseconds https://app.media.ccc.de/v/33c3-7865-gone_in_60_milliseconds
monksy 10y ago
I completely agree with you and I find the ignorance in our industry mind blowing. The industry has pushed for sloppy dev practices (Lean/Agile) and has time after time claimed that all of the "extra" stuff like strict access controls and discipline "aren't needed features." Mongo DB security didn't come until version 3. VERSION 3. It was assumed you could just firewall it off and life is good.
- threeseed 10y ago
  Everyone uses Lean/Agile now so calling effectively the entire industry sloppy is a bit stupid on your part. There is nothing in the project management process that forbids you from including security as a high priority or making sure the software meets certain quality criteria. Also where did you get the idea that security didn't come to MongoDB 3 ? You're talking nonsense.
  - toomuchtodo 10y ago
    > Everyone uses Lean/Agile now HN bubble generalization. Also, was the stupid part necessary?
djrogers 10y ago
> If there's a 0day, i'm going to use it Sure, but with the number of unpatched systems out there most black hats aren't paying (in time/effort or straight cash) for 0-days except for exceptional circumstances. 0-days are great for targeted attacks, state actors, and hack-for-hire/contractors, but for the everyday dude who wants a botnet? Why bother... Look at Mirai - that wasn't anything close to a 0-day and it had a huuuuge impact. Anyone running a similar botnet could be extorting hosts and providers to this day if it hadn't been used in such a public way.
cyberpunk 10y ago
I've run java apps on boxes that are several years out of date OS patching wise and have many bugs, explain to be how you'd exploit those? You'd need to: * Get through the CDN to hit origin * Get through the patched internet facing rproxies * Exploit the JVM to get code execution, while your target area is something like spring * Get a code exec on that box as the appserver user _THEN_ use your j33t exploit.. If an attacker is capable of doing that, then absolutely nothing you can do is capable of stopping them anyway. Patching is only important for your internet facing stuff, depending on your environment. I WANT to patch such systems, we all agree that it's poor practice to do so; sometimes life is unfair though and in the grand scheme of things I don't see any significant risk in this scenario..
- peterwwillis 10y ago
  I worked at a company with that kind of app. It got owned three different ways. A user reported it after they saw it listed in a forum somewhere. It was mainly app vulns, not platform, but there were certainly things that could have avoided it. The system was just not hardened at all, and the devs were sloppy. Luckily they had basic network security best practices and so it was confined to frontend, but blah blah SQL blah blah MITM, still not a good situation to be in.

kakwa_ 10y ago

Security is not that much improved to be true. Docker is just a fancy chroot, a motivated attacker can escape from it, it remains far less secure than a freebsd jail or a solaris zone. Except maybe some somewhat safer compiled languages (rust, newer versions of C++), and a few interesting tools (like AFL), there was not much improvements in security mechanism in late years. SELinux is still so annoying that it's commonly the first thing disabled in many install. A large amount of sysadmins and developers still do a chmod -R 777, not fully understanding what there are doing. And in the area of micro services, the traditional 3/4 tiers architecture can easily be replaced by a clusterfuck of containers deployed in a flat network where it's impossible to monitor what is speaking with what. And it's much easier to make a mistake like putting a database on the Internet with no authentication whatsoever... What is more, because of containers, infrastructures tends to be far more diverse than ever: python, node, php, ruby, go, java, each with various version, from various distribution, with various libraries. Each of these environments must be properly monitored, but when you deal with thousands of containers, hundreds of technological stacks, with 3 or 4 versions for each layer, it becomes a nightmare. In languages that encourage bundling, Java with war webapps for example, I've rarely seen developers properly monitor security issues of what they ship. Too often I've seen only opportunistic updates. And in some extreme cases I've seen products shipping version of libraries 10 or even 15 years old. Containers being a way to generalize bundling, I don't see it being an improvement in that regard. Quite the contrary in fact. However, to be completely honest, new tools like chef/puppet/containers and new methodologies like Infrastructure as Code somewhat helped to be less frighten about updates as it reduces the risk/impact of something breaking in the process, no more 'don't touch it, it will break comething'. Even containers can help in that regard, it's easier to do AB testing, avoid downtime or put servers in maintenance with them. Fundamentally, some things are better, some things are worth, and in the end the security level has not really changed. And honestly, it's a truly frightening view. Software/Infrastructure security is becoming more and more important as sensitive operations are increasingly done through websites (ex: banking operation), private data is increasingly stored in the "cloud" and an increasing number of devices are now connected. Security flows are still as numerous as before, but their impact, once exploited, tends to be far greater. If it continues like that, something really bad will happen, exactly what is difficult to predict (massive data leak? major industrial disaster caused by a hack? an election being manipulated?), but it will happen.