Comment by umvi | Hacker News Reader

Comment by umvi | Hacker News Reader

Parent Full thread

> Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there.

There is still some information lost in the process:

- "let eigenvector_coefficient = 23" => "let x = 23"

A de-obfuscator isn't going to be able to recover the valuable information contained in the original name. Will it stop a determined attacker? Maybe not, but it would surely slow them down as they now need to spend an order of magnitude longer trying to understand what the code is doing.

> Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker.

Believe it or not, nuisances are enough to stop some people. A lot of would be attackers are just cruising for low hanging fruit.

Remember, the goal is to "reduce risk" and not "stop any highly skilled targeted/tailored attack". Because let's face it, even if you are the greatest crypto wizard in the world, you will fall victim to a highly sophisticated attack tailored specifically to you.

>Believe it or not, nuisances are enough to stop some people. A lot of would be attackers are just cruising for low hanging fruit.

It is not "some people" that I worry about. I worry about attackers with a level of skill.

As I noted elsewhere in the thread, I have audited obfuscated code and the obfuscation is only a speed bump. I can only presume that attackers are smarter than I am, and obfuscation is effectively not an issue. And it is not an order of magnitude. This is another example of developer thinking that this form of obscurity is of any real value. Reviewing code will tell you if eigenvector_coefficient is really what it claims to be or something that morphed into something that the developer didn't originally intend.

Also keep in mind that code reviews approach code from a totally different angle than a developer would either developing or during a code walkthrough.

It might make sense in some contexts, but code obfuscation is a great example of where software engineers think it provides security where it provides none.

Developers often have some idealized notion that an attacker is going to need to piece their program logic back together and try to decode the purpose of each obfuscated variable in order to find a hardcoded password/value.

In reality an attacker is just going to dump strings and try them all or simply set a breakpoint just before the important syscall and let your program do the work. Code obfuscation provides little to no value for these common methods, yet we cannot resist the urge to list it as a bullet point in security meetings, leading to a false sense of security.

Exactly. If you're running crypto and think getting rid of variable names is going to stop people; it's not. Any off-the-shelf algorithm is usually easy to recognize to an accomplished reverse engineer with a basic background of what kind of things they're looking for.

Honestly, the modern JavaScript toolchain is better at giving reverse engineers a headache than 80% of binary obfuscators.

As someone who is not very good at JavaScript reverse engineering, I would tend to agree that minifiers are pretty annoying.

So the first thing that I do with one of those is to parse it and convert it to s-expressions. Problem solved.

>simply set a breakpoint

I knew nothing about this topic in general, but elsewhere in this thread there was a link to a blog post about obfuscation methods used in a piece of commercial software. One item was a function that detects a breakpoint, obfuscates its boolean return value so you can't tell if it did, and makes the program hang when it does. Pretty neat.

I think your (and my) ignorance of such methods is evidence that they probably are reasonably effective, even though when explained, they're not quantum physics.

Let me give you an example. At a previous job as a devops, of my predecessors frequently used these "techniques, minus the encrypted database but I sure he would have done it if he knew how. So there was some buggy internal app they needed some new features added to and the person who wrote it thought he was clever and obfuscated the code. It took me a whopping 30 minutes churn through his 'clever' obfuscation scheme and the randomized variable were just a nuisance. Honestly his best obfuscation technique was his horrible code that made no sense.

Even OP's advice about running services on non-standard ports isn't sound. Who doesn't run a service scan? Even sites like Shodan do service discovery for you. I'm going to find whatever port your running ssh on if your running it.

> I'm going to find whatever port your running ssh on if your running it.

Not if you have to port knock before the ssh port is open to new connections.

Why not? I'll run my automated port knocker

Huh? How would that work? You have no idea what my port knocking scheme is.

For all you know you have to knock ports 22, 46, 1776, and 8998 to the timing of "shave and a haircut" switching between udp and icmp along the way... Good luck, the entropy you have to overcome is astronomical.

I would thing that blocking IP's of insessant knockers would be easy to implement.

They use proxies! So many proxies.

> I'm going to find whatever port your running ssh on if your running it.

I still think it's a good idea. With SSH on port 22, ten thousand bots plus an attacker try to hammer it (so says fail2ban). With SSH on port 9278, zero bots plus an attacker try to hammer it. By throwing away the 99.99% of the chaff, you can see the remaining wheat you care about.

Changing SSH ports isn't about saying "yep, we fixed it!" and calling it a day. It's about decreasing the amount of stuff you have to deal with, which is quite useful. It's something you can do in addition to everything else that gives a decent bang for its buck. No, it doesn't keep you out, but it does keep out those thousands of bots crawling around looking for an open 22 to pester.

But new people in the industry shouldn't think that the things recommended in the article should be used as a primary defense and are accepted industry practices. Moving SSH to a new port to reduce false security alerts is one thing, having people read that article and walk away thinking this is how we do things is another. We don't.

I didn't take that away from the article at all. It said:

> So let’s talk about security by obscurity. It’s a bad idea to use it as a single layer of defense. If the attacker passes it, there is nothing else to protect you. But it’s actually would be good to use it as an “additional” layer of defense. Because it has a low implementation cost and it usually works well.

I think it's good to do those things in addition to the other stuff. Obscurity isn't sufficient by itself, but is another layer of defense.

In addition to the stuff you should really being doing? That stuff is hard enough for beginners, without confusing them with speculation like this that goes against best practices and common sense, especially without clearly explaining the pitfalls and real dangers to each of these hypothetical scenarios. Besides, if you're already using industry accepted solutions to security problems and someone manages to gain unauthorized access anyways don't expect any of this amateur crap to offer any real protection at that point.

I don’t feel as though you came away with the real intent of the article, which didn’t make the arguments you’re shouting down.

Reply on news.ycombinator.com