Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Increasing Attacker Cost Using Immutable Infrastructure

diogomonica.com

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Increasing Attacker Cost Using Immutable Infrastructure

#11

Post by viraptor »

oolongCat wrote: post #4

So I am confused, how does any of this increase attacker cost? Cant you do the same thing at the OS level already? Wouldn't making the dir read only do the same thing? If your data gets stolen and your website defaced what's the use of immutability? I mean you can always run a diff tool against the current code on the server with the code you have on your repo right?

> how does any of this increase attacker cost?

Because it forces the attacker to write a specific payload for your service. Standard, reused "drop shell.php and register IP" will not work anymore. And realistically if the target of the attack was a WordPress installation, it will likely be a trivial, automated script.

> Cant you do the same thing at the OS level already?

Yes, you can. Even better, split execution privileges from file privileges, then make it read only, then put a grsec/apparmor/selinux profile on the service. It's not docker specific, but docker does make read only service a little bit easier.

> Wouldn't making the dir read only do the same thing?

Yeah, but who would do that old school thing. Docker security! :-(

Re: Increasing Attacker Cost Using Immutable Infrastructure

#12

Post by sublimino »

Of note is that an immutable/noexec filesystem doesn't prevent code being downloaded to an environment var/typed out and run - tools like https://github.com/SafeBreach-Labs/pwndsh just pipe source to an interpreter (in that case BASH, which generally isn't installed in smaller base images).

Reducing the attack surface is important, but if a running container is compromised it's imperative a post-mortem is performed immediately - and the issue remediated - to prevent re-exploitation.

Re: Increasing Attacker Cost Using Immutable Infrastructure

#13

Post by icebraining »

dgoldstein0 wrote: post #7
oolongCat wrote: post #4

So I am confused, how does any of this increase attacker cost? Cant you do the same thing at the OS level already? Wouldn't making the dir read only do the same thing? If your data gets stolen and your website defaced what's the use of immutability? I mean you can always run a diff tool against the current code on the server with the code you have on your repo right?

it's pretty hard to diff filesystems that aren't designed for it. Either you need to lock the whole filesystem somehow - e.g. by taking it offline - or you have to deal with the fact that other processes are reading/writing as you scan the filesystem, which is rather difficult to reason about. And it's not just about diffing your code with your repo - that only works if the attacker tried to attack your code. What ab…

You can also use lvm snapshots, which work with any filesystem.

Re: Increasing Attacker Cost Using Immutable Infrastructure

#14

Post by runeks » 

    > Until we fix this RCE vulnerability, the attacker will 
    > still be able to execute code on our host [...]
With Docker, it seems to me like we're moving closer and closer to the server being an executable of its own, but with the necessary Linux kernel bits compiled in such that it can execute on (virtualized) hardware.

I'm wondering how far we can take this. The ability to execute code on the host is there because that's what Linux does, but what if we removed this interface, and replaced it with an interface that just accepts one or more ELF binaries at compile-time? Then these would become the only Linux executables that this kernel can execute.

As far as I can see, we could do the same to system calls: if an executable can enumerate all the system calls it needs, we can compile a kernel that will accept only these system calls, which should be a small subset of all available Linux syscalls.

Re: Increasing Attacker Cost Using Immutable Infrastructure

#15

Post by Senji »

dgoldstein0 wrote: post #7
oolongCat wrote: post #4

So I am confused, how does any of this increase attacker cost? Cant you do the same thing at the OS level already? Wouldn't making the dir read only do the same thing? If your data gets stolen and your website defaced what's the use of immutability? I mean you can always run a diff tool against the current code on the server with the code you have on your repo right?

it's pretty hard to diff filesystems that aren't designed for it. Either you need to lock the whole filesystem somehow - e.g. by taking it offline - or you have to deal with the fact that other processes are reading/writing as you scan the filesystem, which is rather difficult to reason about. And it's not just about diffing your code with your repo - that only works if the attacker tried to attack your code. What ab…

COW by default file systems which provide a "snapshot at time x" can help with this. NTFS can do it with shadowcopy.

Re: Increasing Attacker Cost Using Immutable Infrastructure

#16

Post by stable-point »

runeks wrote: post #14

> Until we fix this RCE vulnerability, the attacker will > still be able to execute code on our host [...] With Docker, it seems to me like we're moving closer and closer to the server being an executable of its own, but with the necessary Linux kernel bits compiled in such that it can execute on (virtualized) hardware. I'm wondering how far we can take this. The ability to execute code on the host is there because t…

This is called a Unikernel: https://en.wikipedia.org/wiki/Unikernel

> Unikernels are specialised, single address space machine images constructed by using library operating systems. A developer selects, from a modular stack, the minimal set of libraries which correspond to the OS constructs required for their application to run. These libraries are then compiled with the application and configuration code to build sealed, fixed-purpose images (unikernels) which run directly on a hypervisor or hardware without an intervening OS such as Linux or Windows.

Re: Increasing Attacker Cost Using Immutable Infrastructure

#17

Post by SixSigma »

runeks wrote: post #14

> Until we fix this RCE vulnerability, the attacker will > still be able to execute code on our host [...] With Docker, it seems to me like we're moving closer and closer to the server being an executable of its own, but with the necessary Linux kernel bits compiled in such that it can execute on (virtualized) hardware. I'm wondering how far we can take this. The ability to execute code on the host is there because t…

This industry is one of the least aware of its own history, everyone is focussed on tomorrow. We should really include History of Computing as a discipline. Round and Round and Round we go.

---

You want to make your way in the CS field? Simple. Calculate rough time of amnesia (hell, 10 years is plenty, probably 10 months is plenty), go to the dusty archives, dig out something fun, and go for it. It’s worked for many people, and it can work for you.

        — Ron Minnich

Re: Increasing Attacker Cost Using Immutable Infrastructure

#18

Post by justincormack »

sublimino wrote: post #12

Of note is that an immutable/noexec filesystem doesn't prevent code being downloaded to an environment var/typed out and run - tools like https://github.com/SafeBreach-Labs/pwndsh just pipe source to an interpreter (in that case BASH, which generally isn't installed in smaller base images). Reducing the attack surface is important, but if a running container is compromised it's imperative a post-mortem is performed i…

potentially you do not need any interpreters available at all, which certainly increases attack difficulty.

Re: Increasing Attacker Cost Using Immutable Infrastructure

#19

Post by toomuchtodo »

Senji wrote: post #6
xorcist wrote: post #5

It is not a good idea to restore attacker-owned applications to a "known good" state before you have done at least a cursory post mortem. Not only do are the security holes intact but since the attacker now knows they been found out, you can invite more serious damage. The article tries to pitch read only Docker images some kind of solution, but running your applications read only (and what other permissions you gran…

Should probably just tiger-tree-hash your containers. If they deviate you give them a copy of your database, but it's a "virtual" shadow copy. No writes to it reflect on the real database.

If attackers get your database, you lose. Containers don't fix application vulnerability mitigation and leaking data.

Re: Increasing Attacker Cost Using Immutable Infrastructure

#20

Post by zokier »

runeks wrote: post #14

> Until we fix this RCE vulnerability, the attacker will > still be able to execute code on our host [...] With Docker, it seems to me like we're moving closer and closer to the server being an executable of its own, but with the necessary Linux kernel bits compiled in such that it can execute on (virtualized) hardware. I'm wondering how far we can take this. The ability to execute code on the host is there because t…

> As far as I can see, we could do the same to system calls: if an executable can enumerate all the system calls it needs, we can compile a kernel that will accept only these system calls, which should be a small subset of all available Linux syscalls.

That is what pledge essentially does at runtime

http://man.openbsd.org/pledge

Post reply on HN