Hacker News Reader

Comment by AlexandrB | Hacker News Reader

I suspect this kind of thing is common in "in-house" applications where the assumption is that the app will never be exposed to the open internet.

View on HN

It is, but it creates the 'soft chewy center' of production infrastructure that hackers so enjoy.

People are supposed to do defense in depth, where there are multiple layers such that a compromise of a single one only leads to limited damage, but too often it's more like there's a hard outer shell surrounding a soft chewy center where they thoroughly and completely own you once the outer layer has been compromised.

Yep. But sometimes you don't get to choose where to hold your last stand. You were not PLANNING for the abandoned kindergarten to be your command post against the rebels but that is where you ended up. Same goes for corporate security sometimes. The chewy soft center was written in happier, more cheerful times. By undergrads. Who now are fully vested and long since left the building. Then the mercenaries are called in to defend it against the Internet. But I digress.

Yes, but the natural thing would to be not to have anything HTTP on its path

(Unless of course some IT department has transparent proxies that try to be too smart)

And that's why some sanity checks are important (magic numbers on the protocol, size limits, etc)

Another possibility is that someone in IT or corporate security bought a fancy vulnerability scanner and is blindly running it against everything on the internal network. They might even change any existing firewall rules to allow it to contact every host

Vulnerability scanners tend not to do anything with unknown custom services, running on ports they probably don't even bother to scan.

Major enterprise vulnerability scanner author here (15 years ago). Yes, we scanned the port, and yes, we ran a lot of fingerprinting rules against it until we figured out what it was (or ran out of rules), so that we'd know what vulnerabilities to test for.

This had some amusing side effects when we encountered some services we'd never seen before, like the port on HP printers that sends every byte straight to print... apparently expecting PCL or PostScript but if it didn't understand it, it just printed the ASCII. Came into the office one morning to find all printers out of paper and 500 sheets sitting in the output tray. Oops.

> the port on HP printers that sends every byte straight to print

That seems like a design flaw. :)

At a minimum, it seems like a way to DOS an HP printer...

Now that's "Resource Exhaustion".

And not just the paper. You might be able to DOS the ink as well.

If we are going there, toner

I remember my first epson dot matrix receiving data from my z80.

Print a graphic was done by sending exactly every dot to it, I mean, 1 to put a dot on the paper, 0 to blank. Encoded as a byte...

It worked, you found a vulnerability.

Still not an excuse to trust data you're getting across an I/O boundary.

...and the first thing that happens when it ever happens to be connected to the internet is that it gets broken and has to be rewritten. That's why it's good to care about the quality in the first place...

Chances are that if you're connecting a formerly in-house application to the Internet, you want to force a rewrite. It likely has a lot of other security vulnerabilities that would let an attacker pwn your corporate network. You build software for the open Internet very differently from you build it for a trusted environment; you don't want to fool yourself into thinking the latter is good enough for the former.

What are the differences really? What's a "trusted environment" anyway?

Every program needs to make some assumptions about what operations it's going to trust and what it's going to verify. Most programs, for example, assume that (length + 1) [where 'length' is a simple 32-bit integer] will have no side effects, even though there's no absolute guarantee that the NSA hasn't backdoored your compiler or a Chinese supplier hasn't backdoored your CPU to open a rooted shell remotely. Most programs will also assume that (length + 1 > length), even though in many languages this isn't universally true because of integer overflow. If your program never deals with integers that large, it doesn't matter.

For most public programs, the trust boundary is generally assumed to be the process. Any I/O the process does is assumed to be untrusted; it could do anything. But anything inside the process is assumed to work as the language says it does, because the OS is assumed to provide memory protection that prevents other processes from tampering with it. (Some big companies go a step further and dictate that you're not to trust 3rd-party libraries unless the code has been specifically audited; this is generally a sensible practice security-wise, but a huge drag on developer velocity.) If you couldn't trust the basic machine operators, you'd never get anything done - you'd have to write sanity checks everywhere, and then you have no guarantee that the sanity checks themselves aren't backdoored.

For many internal apps, the network is inside the trust boundary. It's assumed that any network connection comes from a trusted source, because otherwise the firewall would've rejected this. And being able to assume this saves a lot in developer velocity; it becomes feasible to write one-off internal tools without the devs having to carefully audit all the I/O & cross-process code for vulnerabilities. If you didn't have this trust, most of these apps wouldn't get written, because the productivity benefit they provide isn't greater than the cost of writing a hardened, secure system. It's not just networking calls; if you can assume that your users are non-malicious employees, you also don't need to worry about XSS or XSRF, pathological regexps, DOS attacks based on large payloads, etc.

And sometimes you don't trust the operations. I've heard tales of flight computer software running on 3 computers from 3 vendors running 3 implementations of software from 3 independent teams. Then the 3 computers voted on a course of action.

You may be interested in this PDF[1] which describes what you're talking about.

Title: Triple-Triple Redundant 777 Primary Flight Computer

[1] http://www.citemaster.net/get/db3a81c6-548e-11e5-9d2e-00163e...

Thank you. I heard it about SAAB Gripen fighter/attack/recon craft in the 90s, but for me it's faded memory of hearsay - so it's cool to read a more substantial reference. :)

That's the best-realistic-case scenario. The most likely case is that even if a few problems are found and patched, some serious vulnerabilities will be left in place, unnoticed until someone from outside, without your interests at heart, goes looking for them.

Reply on news.ycombinator.com