LnS registry manipulation

Hi everybody,

this is a continuation of a subject which was started by me, not
quite correctly, under Frederic's topic "LnS, thermite etc."

Ph33r asked me how I would close LnS as a running process in order
to execute a malicious .reg and restart LnS. My answer today was
based on an assumption.

To test this, here is what I did now:

1. I disabled my present firewall and installed LnS.
2. I rebooted and loaded LnS
3. I left all the configuration as is, but had it to save the lns.reg
and start at system time.
4. Reboot, copied lns.reg for later use to another dir. In order to
have an entry in the applications window I started webwasher in
order not to enter the net.
5. Reboot, NOW I HAD ANTS TROJAN SCANNER KILL THE LnS PROCESS. It did.
Copied the saved lns.reg to LnS dir and executed it.
(Spript Defender 1.2 asked me however if I want to execute, I did )
6. Reboot, Webwasher was gone from the application window.

This means that the process CAN be killed and the .reg can be
manipulated.
The whole procedure is quicker than one imagines when reading the above
points.

cheers

 

Hi,

Well, Webwasher is removed from the list.
And so ?
I suppose Look 'n' Stop will ask again for WebWasher if it tries to connect.

Anyway, I agree that changing other entries could be more problematic.
So, this part (registry saving) will be improved in the next release.

Why not restart LnS just after ANTS has killed LnS ?
Why are you focusing on the .reg file ? It should be possible to modify directly the registry without the need of the .reg file.

Frederic

 

How about using some form of encryption to store LnS's settings (and if so, would it still be advisable to store them in the registry?)?


Here's the scenario we want to avoid:

B: A Trojan Programmer codes his trojan so to modify LnS's rules in the registry on-the-fly and introduce some weaknesses where his trojan would be able to connect to the net and to communicate.
W: He cannot do it on the fly, because the settings are kept in memory and re-written to the registry when LnS exits.

B: So, the coder sets up his trojan to kill LnS, modify the reg and then re-launch LnS so the user doesn't notice what has been going on...
W: Okay, so we encrypt the registry keys that are relevant. Then the blackhat cannot just go into the registry and change a setting here or there...

B: So, he sets up his own copy of LnS to generate the (leaky) encrypted configuration with the same LnS encryption algo which he then gives as a "blackbox" payload to his trojan which just copies the whole encrypted mess into the destination registry. After all, the trojan program itself doesn't need to understand which values are concerned...
W: Okay, so we add some "noise" to LnS global encryption scheme: let's say by XORing all those keys with some machine-specific string. Then the remotely generated (leaky) configuration will not be ready to work on another machine...

B: So, the hacker finds out which machine-specific value is at work here and first "XORs out" his own "machine signature" and then uses his trojan program to "on-the-fly" retrieve the respective string from the victim machine, and do the XOR with that before killing/importing/relaunching.
W: We use a user-password (which has to be stored strongly encrypted itself) instead of a retrievable Machine-ID... (this also avoids those hardware upgrade problems we all know and love in WinXP that we'd run into if we used some such machine-ID)

W: Wait a second, what is the weakness that the blackhat would want to introduce in the first place?
B: Hmmm, he needs to make sure that certain connections are allowed, so he has to import a "open-ports-protocol-host-in-both-directions" rule which must sit on the very top. To do so, he must cope with the ecryption scheme, whichever that may be. Additionally, he needs to authorize his trojan to connect at all in Application Filtering, so he also tries to introduce an "allow-trojan-directly" rule. He could either try to add a new application (his trojan) to the list of allowed applications or to have his trojan replace one of the already existing allowed applications. Both of these not only have to cope with the settings being stored encryptedly, but also with how the signatures are computed. So the question for the nature of them sigs is still on the agenda...

Btw, how difficult would it be to change the settings directly in RAM? I suppose that they even have to lay rather open, since it would cost too much time to process them and make them up only just when they're needed...


Any comments? ideas? is it feasible? needed? wanted?

Andreas

 

Correction; I never asked how you would do anything, I stated “Process Termination Protection”.

Great work Andreas(W), I like your way of thinking…