The Coalition against Personal Firewalls

Because it doesn't do anything malicious. Therefore it is not malware.

I've just invented a device which has a handle at one end and is heavy at the other end. I think I'll call it a hammer. I claim that my hammer will bypass nearly all glass windows easily. I'll prove it if you like. Take one window; swing my hammer and SMASH, no window. If that were the window of a jewellery (or jewelry if you must spell it like that) store then I could get up to all kinds of mischief. So I expect that my malware (sorry hammer) will shortly be classed as a very bad thing which no-one should have. No doubt the police will want to take it away from me if they find it. Why would you want something which proves that glass windows don't work NOT to be detected as malware?

Nah I think it shows that they will do anything to increase the amount of "malware" detected because if it's more than a competitor then they may sell more product than their competitors.

Jason

What do you mean it doesn't do anything malicious - if it does something you don't want, which is the point, then it's malicious. Just because it's not currently used for malicious activity doesn't mean it can't be used that way.

All this does is prove that the vendors are getting better at detecting the holes in the OS/apps and stopping them. Looks like VB, who didn't have a good working POC, will have to invent another reason to complain about PFW solutions.

Same with hammers :) I've got one here. If it does something you don't want, such as breaking a window, then it's malicious. Just because it's not currently used for malicious activity doesn't mean it can't be used that way. Perhaps I should hand it in at the nearest police station. It's probably only a matter of time before they develop a way to detect it.

Glass vendors are getting better too. They've stopped claiming that my hammer can't get through and now only claim that special toughened glass is needed to stop my hammer. If it weren't for my hammer they would never have developed toughened glass and car drivers would be in danger of windscreen (or is that windshield) breakage because car manufacturers would have used the cheaper glass which breaks easily. For some reason no car manufacturer has ever claimed that my hammer is malicious and should be banned, but somehow I think they would if they could get away with it. They don't seem to like having the toughness of their glass demonstrated in public. It's not good for sales if too many people find out that non-toughened glass is vulnerable to my hammer.

Or a stronger hammer. Or maybe a liquid which dissolves glass, or a way to drill through the wall and thus avoid the window altogether. All these things will have to be labelled malicious because they can do something we don't want. If you want to drill through a wall you'll need a special drill permit.

Goodnight

Jason

I'm not sure if you're off-kilter or just not sure of the POC that doesn't work as a POC properly.

But your point seems to be that the PoC is malicious.

Quote: "What do you mean it doesn't do anything malicious - if it does something you don't want, which is the point, then it's malicious"

Either it works properly or it does not work properly. Whether or not it has malicious intent is a separate matter from whether or not it works properly. I do not see any malicious intent in it, I see the opposite.

Goodnight

Jason

I doubt that. And I cannot see, that the AV vendors are doing what you're claiming - implementing very clever heuristics. As a matter of fact, if you change just one line in my PoC code and recompile, all AV programs I heard of aren't detecting malware any more.

Yours, VB.

My code does not break anything, it does not bypass a firewall, there is no "dirty trick" with it (like with code injection, for example), it just uses well known and well documented features of the Windows operating system to communicate in a way, these features are indended for by the manufacturer.

To detect this as malware behaviour just is ridiculous.

I implemented this way and _not_ like other "leak tests" intentionally, because this is what I wanted to show.

Yours, VB.

"Volker Birk" wrote

please prove it and offer me some changed compiled PoC's. I haven't the software to compile things. From another example I know changing code didn't help.

It is intended to prove that a malicious code could get past the PFW, so, while it does not contain any "true" malicious code, it's presenting itself as malicious - if it was not acting as a malicious program it would not be trying to get past the firewall. So, if it was not "acting" as a malicious application would, it would not be doing what VB hoped it would, and as it's detected, it's another example of how flawed the CAPF thinking is.

So a program which tries to get past a firewall is a malicious program? Or is that a program which acts as a malicious program? Or is that the same? What if I just wanted to check that the firewall works?

Anyway, enough splitting hairs, let's have some facts. Download a free compiler.

Compile as many variations of Volker's code as you want. AVG won't blink and I'd be interested to know if that's true of other scanners.

I think it's much better not to get additional unwanted code on the system to begin with. Then it doesn't need to be detected by heuristics which don't seem to work anyway.

Jason

The PoC is not exactly trying to get past the PFW anyway. It remotely controls a local application (which is a valid way to do automation on Windows) which happens to be allowed to communicate through the PFW.

However, I seriously doubt that Leythos will ever be able (or willing) to understand that, so don't bother.

cu

Just change yourself, please.

No problem. For example here you can find a toolchain:

It depends, what you're changing, of course. Changing something that results in the same binary will not help.

Yours, VB.

"Volker Birk" wrote

and trying to make your PoC undetectable and workable? You are the expert and you could always say that my changes aren't the correct changes.

Wow, changing the code and that should result in exact the same binary? What a nonsense. I know that you are very wrong.

You can modify the code as YOU like. You just need to change some code without breaking functionality. The changes need to be big enough so that the binary is different. If the PoC is sill detected as a virus then change some more code.

And I know that you are very wrong.

Why sould "some_var = 40 + 2;" and "some_var = 42;" generate different binaries? It's different code but will result in the same binary.

It seems you don't know that modern compilers do a lot of optimization so that even other differences can generate the same binary. The above example is just very simple.

Wolf

The PoC works already. And I did not try to hide something at all. Why should I?

There is no such thing as a "correct change" here, because there is no reason to change anything.

It's just ridiculous, that some AV providers are detecting PoC code as malware. It's a bug in their software, and we all only can speculate, why they're inserting bugs into their products intentionally.

This we don't need to discuss, because it's a fact.

What we're discussion now is, _how_ are they detecting it. There was a claim, that some kind of heuristics is detecting the thing, how the PoC would work when started - before started. And I doubt that, I think, there just will be a signature for it. This is probably the way they're working, because they even have created malware IDs for my PoCs, a thing they usually create for every malware they have a signature for.

Change a name of a symbol, i.e. a variable, and compile again. Nothing changes in the binary.

You seem not to know too much about how the toolchains work.

Yours, VB.

They won't let me on a plane with a nail file or a 2-inch long phillips #0 screwdriver either.

The PoC breaks a personal firewall. It then communicates out but does nothing malicious. But this exact code could be used to front a malicious program. The activities of the code are easy to break down, analyze and detect, and form the source of the actual security exposure, therefore are the logical place to form a security protection. The rest of the (hypothetical) new malicious code is whateverr goofy stuff some script kiddie dreams up, and potentially far harder to notice until you get sent a sample.

So why not trigger on the PoC?

-Russ.

My PoC does not break anything.

No. It's not usuable as attack code, and this is intentionally.

Yours, VB.

Good heuristic detections don't work that way, they look for the specific calls to the OS or the specific activities, not just different biary crc's or strings. So, seeing a few particular calls that would be the same no matter what sorts of changes you made to program flow or syntax, add up to the heuristic definition. That's what makes it a heuristic. Changing a few lines of code to give a different binary evades garden-variety string-matching AV signatures, but not good heuristic engines.

-Russ.

I don't need to download any compilers I have about everything on the market for writing code, as I code in 11+ languages, and have since the

The point is, and he's said this in every post, that his POC application will PROVE THAT PFW's DON'T WORK, and the simple fact is that his POC's that I tested were unable to do anything, were stopped by the PFW or my normal security settings in IE.

So, it doesn't matter how his code is written, how it is intended, once it's compiled it should be detected as malware - that's why you want to compile it on your own system and have the virus scanner ignore it once YOU compile it - I would never download a compiled program from anyone in this group and just blindly trust them.