LnS registry manipulation

Discussion in 'LnS English Forum' started by lurker1, Mar 2, 2003.

Thread Status:
Not open for further replies.
  1. lurker1

    lurker1 Guest

    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.
    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
    The whole procedure is quicker than one imagines when reading the above

  2. Frederic

    Frederic LnS Developer

    Jan 9, 2003

    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.

  3. Andreas1

    Andreas1 Security Expert

    Jan 29, 2003
    Mainz (Ger)
    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?

  4. Ph33r

    Ph33r Guest

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

    Great work Andreas(W), I like your way of thinking…
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.