Maximising Windows XP security with LUA and SRP

Discussion in 'other security issues & news' started by tlu, Feb 18, 2008.

Thread Status:
Not open for further replies.
  1. PuckSkraper
    Offline

    PuckSkraper Registered Member

    False alarm, it seems something went wrong while slipstreaming my install disc. I've reinstalled and gpedit is working as expected.
  2. tlu
    Online

    tlu Registered Member

    For implementing SRP on any Vista edition I highly recommend this thread - Lucy has done a marvelous job, thanks a lot for that!
  3. zopzop
    Offline

    zopzop Registered Member

    TLU et al, I encounter the following problems when I setup LUAs :

    On literally every machine I've done this on (setting up LUAs), the LUA has write privileges to create files/folders in C:\, C:\Programs, C:\Windows, etc.... But the whole point of LUAs is that you only have write access to your LUA folder.

    This has occurred on 4 different machines running fully legal versions of Windows XP Home and Windows Vista Home Premium. The machines varied from HPs, to Gateways, to Emachines, to Compaqs.

    To solve this I've had to open Explorer, right click C:\, go to the Security Tab, select the Advanced button, select Users, and make a Deny rule (basically denying everything except the following : Traverse Folder/Execute File, Read Attributes, Read Extended Attributes, List Folder/Read Data, and Read Permissions).

    Then it works fine. BUT...............on the Vista Machines I went back to modify my deny rule, but I can't! It says I don't have the authority to change the permissions. I've tried turning UAC on, off. I've tried using the Hidden Administrator. I've tried running Explorer as admin but nothing works. Any ideas?
  4. Lucy
    Offline

    Lucy Registered Member

    Zopzop,

    I know tlu or another knowledgeable person has already answered this. It seems that when you convert an admin account in user account under XP, all permissions are not reset as it should, and the user account inherits some rights from the admin account. So you have to go to your admin account, and take ownership of all necessary files, registry keys and folders, until user has no more write permission to program and windows folders.

    You have these links:
    http://www.winhelponline.com/blog/reset-the-registry-and-the-file-permissions-in-windows-xp/

    http://www.wilderssecurity.com/showpost.php?p=1201866&postcount=146

    http://www.wilderssecurity.com/showthread.php?t=233838
  5. zopzop
    Offline

    zopzop Registered Member

    But that's the strange thing Lucy, these are freshly created LUAs, not admin accounts that I converted to LUAs. I literally have to strip the USERS group of their write permissions using the security tab.

    And there's still the problem of me not being able to modify the permissions I created in Vista even when logged on as Hidden Admin.
  6. tlu
    Online

    tlu Registered Member

    zopzop, the most plausible explanation is that you had installed software that save their settings/data in c:\Program Files and/or c:\Windows instead of in the respective c:\Documents and Settings folders. In order to do that for limited users they have probably manipulated the permissions during the installation process in such a way that everybody has full permissions for these folders. That's extremely bad and irresponsible programming and a blatant violation of Windows security standards! Applying the steps in the links mentioned by Lucy will restore the permissions to their safe defaults - but will break these applications. Thus it might be necessary to grant write permission to your limited account for specific subfolders in c:\Program Files or - better yet - only for the configuration/data files of these programs in c:\Program Files and/or c:\Windows.

    I'm sorry. I have Vista Ultimate but don't really use it. Lucy is more experienced with this Windows version - perhaps she has an explanation?
  7. Lucy
    Offline

    Lucy Registered Member

    Unfortunately, so far no. But I am searching.
  8. aussiebear
    Offline

    aussiebear Registered Member

    I'll be honest here: when it comes to WinXP Home Edition, you don't want to screw around with adding SRP as suggested. Things don't turn out as they should. (Exactly like you have experienced). This *may* result in potential security (or other) issues down the road; unless you re-confirm everything by testing malware on it, and then compare it with WinXP Professional Edition.

    I have to say, that is an AWESOME find!

    The Trust-No-Exe is a better alternative for XP Home Edition as well as WinNT and Win2K users, as its not a quick "hack job" to get things to work. (You don't change XP Home such that you are violating Microsoft's EULA you've agreed to when you installed Windows).

    This is similar to SRP on XP Pro, except:

    (1) You can't make an exception for Admin Users! Once you apply it, it takes effect on ALL accounts including the SYSTEM one! (So its identical to SRP when its set to All Users as compared to selecting All Users except local administrators).

    (2) Trust-No-Exe doesn't allow you to make adjustments on the file types like SRP. Instead, it does things this way...(From the website).

  9. tlu
    Online

    tlu Registered Member

    Hello all,

    inspired by Lucy's excellent thread on implementing SRP in all Vista versions I'm presenting here an alternative easy method how to do it in XP Home.

    The attached file is equivalent to implementing SRP as shown on http://www.mechbgon.com/srp/ for XP Pro and Vista Business/Ultimate. Just rename it to SRP-New_Path.reg and execute it with admin rights. A reboot is not necessary.

    The advantage: You will not need pcwXPProme and pcwGPinst - just apply the reg file and you're done.

    The disadvantage: Since the group policy editor is not available with this method it's not so comfortable to add a new extension or a New Path Rule. Rather, you have to do it in the registry.

    However, these two tasks are not difficult. If you want to add a new extension to the existing list just start regedit with admin rights (e.g. with SuRun) and go to

    H K E Y _ L O C A L _ M A C H I N E \ S O F T W A R E \ P o l i c i e s \ M i c r o s o f t \ W i n d o w s \ S a f e r \ C o d e I d e n t i f i e r s

    doubleclick "ExecutableTypes" - now you can add any extension you want (although I don't consider this necessary as this list is already rather comprehensive).

    Adding a New Path Rule is a little bit more complicated. I've already added one as an example in the above file for c:\NewApps.

    Just change the value for ItemData from c:\\NewApps to any path you want, like g:\\MyApps (please note the double backslash!).

    If you want to add another New Path Rule just copy above section to the end of the reg file, go to http://www.guidgen.com/Index.aspx , create a new GUID and replace the bold GUID above between the {brackets} with the newly created GUID. Save the reg file and execute it. Important: You have to repeat this step for every new path rule - you can't use the same GUID twice!

    All told, this method is actually much easier than the steps discussed before. You need gpedit.msc, though, if you want to implement other SRP strategies.

    One last word: If you chose this method I suggest to install FajoXP in order to add the Security Tab available in XP Pro. (You don't need that if you apply pcwXPProme).

    Attached Files:

    Last edited: Mar 2, 2009
  10. soccerfan
    Offline

    soccerfan Registered Member

    Thanks for this tlu.
    Any chance you could also supply us with an 'undo' reg file that
    deletes entries created by SRP-New_Path(.txt).reg from the registry?
  11. Sully
    Offline

    Sully Registered Member

    Tlu, are you also going to provide in this means methods to lock down user startup entries as well? A simple inclusion of regini and cacls in a batch woudl suffice. You are aware also that you can create a vbs script that uses TypeLib to automate the GUID generation? Lot's of further options to make this an easier for the advnaced user. I doubt any of this is going to be user friendly for those who are not advances. I mean now you are talking reg hacks instead of snap-in console's. A big difference between the two.

    Still, I like this idea a lot, and I think it could prove a good project to do some custom scripting on. Especially the part to sort out the different path rules in the registry and display them, maybe with a chekcbox type affair to enable or disable.

    Sul.
  12. Lucy
    Offline

    Lucy Registered Member

    The undo is not necessary. Just put 40000 instead of 0 in value "DefaultLevel".
    This will switch off SR policy.
    To switch it on, replace 40000 by 0.
    Easy
  13. tlu
    Online

    tlu Registered Member

    True, but unless you need a New Path rule it's just a doubleclick to implement SRP. It couldn't be easier, could it?
  14. Lucy
    Offline

    Lucy Registered Member

    If one starts talking of hack about it when it is actually only registry configuration, so any install is potentially a giant hack...
  15. Sully
    Offline

    Sully Registered Member

    No, it coudl not. My experience though is that .reg files breed problems with novice users.

    lol, this is 'hacking into' the registry, 'hacking up' the registry, and often applying a registry 'hack'.

    Like I say, introducing registry tampering is not preferred for novice. Very much too easy to go 'hacking' and then say 'you idiots gave bad advice, now my machine is borked'. Where you say 'I told you not to futz with registry unless you know what you mean to do'. Seen it before, will see it again.

    :)

    Sul.
  16. Sully
    Offline

    Sully Registered Member

    Ok, I am now curious again with SRP and the registry. Does anyone have an idea of what this is? It exists on default xpsp2 machines, before SRP rules are made. It obviously is rules already existing, but wondering what significance the parent key 0 has vs. the other keys made after custom SRP rules are made. And how does it keep from actually downloading mdac11.cab or other file? I don't see that.
    Code:
    Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer]
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
    "ExecutableTypes"=hex(7):41,00,44,00,45,00,00,00,41,00,44,00,50,00,00,00,42,00,\
      41,00,53,00,00,00,42,00,41,00,54,00,00,00,43,00,48,00,4d,00,00,00,43,00,4d,\
      00,44,00,00,00,43,00,4f,00,4d,00,00,00,43,00,50,00,4c,00,00,00,43,00,52,00,\
      54,00,00,00,45,00,58,00,45,00,00,00,48,00,4c,00,50,00,00,00,48,00,54,00,41,\
      00,00,00,49,00,4e,00,46,00,00,00,49,00,4e,00,53,00,00,00,49,00,53,00,50,00,\
      00,00,4c,00,4e,00,4b,00,00,00,4d,00,44,00,42,00,00,00,4d,00,44,00,45,00,00,\
      00,4d,00,53,00,43,00,00,00,4d,00,53,00,49,00,00,00,4d,00,53,00,50,00,00,00,\
      4d,00,53,00,54,00,00,00,4f,00,43,00,58,00,00,00,50,00,43,00,44,00,00,00,50,\
      00,49,00,46,00,00,00,52,00,45,00,47,00,00,00,53,00,43,00,52,00,00,00,53,00,\
      48,00,53,00,00,00,55,00,52,00,4c,00,00,00,56,00,42,00,00,00,57,00,53,00,43,\
      00,00,00,00,00
    "TransparentEnabled"=dword:00000001
    "DefaultLevel"=dword:00040000
    "AuthenticodeEnabled"=dword:00000000
    "PolicyScope"=dword:00000000
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0]
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Hashes]
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Hashes\{349d35ab-37b5-462f-9b89-edd5fbde1328}]
    "Description"="Stop the download of this file"
    "FriendlyName"="Mdac11.cab"
    "SaferFlags"=dword:00000000
    "HashAlg"=dword:00008003
    "ItemData"=hex:5e,ab,30,4f,95,7a,49,89,6a,00,6c,1c,31,15,40,15
    "LastModified"=hex(b):85,c4,34,dc,19,a2,c2,01
    "ItemSize"=hex(b):0b,03,00,00,00,00,00,00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Hashes\{7fb9cd2e-3076-4df9-a57b-b813f72dbb91}]
    "Description"="Stop the download of this file"
    "FriendlyName"="mdac20.cab"
    "SaferFlags"=dword:00000000
    "HashAlg"=dword:00008003
    "ItemData"=hex:67,b0,d4,8b,34,3a,3f,d3,bc,e9,dc,64,67,04,f3,94
    "LastModified"=hex(b):03,8a,39,dc,19,a2,c2,01
    "ItemSize"=hex(b):05,02,00,00,00,00,00,00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Hashes\{81d1fe15-dd9d-4762-b16d-7c29ddecae3f}]
    "Description"="Stop the download of this file"
    "FriendlyName"="mdac20_a.cab"
    "SaferFlags"=dword:00000000
    "HashAlg"=dword:00008003
    "ItemData"=hex:32,78,02,dc,fe,f8,c8,93,dc,8a,b0,06,dd,84,7d,1d
    "LastModified"=hex(b):be,77,45,dc,19,a2,c2,01
    "ItemSize"=hex(b):96,03,00,00,00,00,00,00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Hashes\{94e3e076-8f53-42a5-8411-085bcc18a68d}]
    "Description"="Stop the download of this file"
    "FriendlyName"="_msadc10.cab"
    "SaferFlags"=dword:00000000
    "HashAlg"=dword:00008003
    "ItemData"=hex:bd,9a,2a,db,42,eb,d8,56,0e,25,0e,4d,f8,16,2f,67
    "LastModified"=hex(b):81,4f,3e,dc,19,a2,c2,01
    "ItemSize"=hex(b):e5,00,00,00,00,00,00,00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Hashes\{dc971ee5-44eb-4fe4-ae2e-b91490411bfc}]
    "Description"="Stop the download of this file"
    "FriendlyName"="msadc11.cab"
    "SaferFlags"=dword:00000000
    "HashAlg"=dword:00008003
    "ItemData"=hex:38,6b,08,5f,84,ec,f6,69,d3,6b,95,6a,22,c0,1e,80
    "LastModified"=hex(b):40,b2,40,dc,19,a2,c2,01
    "ItemSize"=hex(b):72,01,00,00,00,00,00,00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Paths]
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Paths\{dda3f824-d8cb-441b-834d-be2efd2c1a33}]
    "Description"=""
    "SaferFlags"=dword:00000000
    "ItemData"=hex(2):25,00,48,00,4b,00,45,00,59,00,5f,00,43,00,55,00,52,00,52,00,\
      45,00,4e,00,54,00,5f,00,55,00,53,00,45,00,52,00,5c,00,53,00,6f,00,66,00,74,\
      00,77,00,61,00,72,00,65,00,5c,00,4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,\
      66,00,74,00,5c,00,57,00,69,00,6e,00,64,00,6f,00,77,00,73,00,5c,00,43,00,75,\
      00,72,00,72,00,65,00,6e,00,74,00,56,00,65,00,72,00,73,00,69,00,6f,00,6e,00,\
      5c,00,45,00,78,00,70,00,6c,00,6f,00,72,00,65,00,72,00,5c,00,53,00,68,00,65,\
      00,6c,00,6c,00,20,00,46,00,6f,00,6c,00,64,00,65,00,72,00,73,00,5c,00,43,00,\
      61,00,63,00,68,00,65,00,25,00,4f,00,4c,00,4b,00,2a,00,00,00
    "LastModified"=hex(b):3a,5e,ba,42,39,e0,c7,01
    
    Sul.

    EDIT: Digging around on this, I found many instances of the same values existing, but found not a real explanation of why they exist and why they don't show. These may provide clue to help hand made values show in mmc. It is curious to have values by default the are commented 'no downloading' when in fact, to my knowledge, SRP has no network blocking feature. Strange.
    Last edited: Feb 26, 2009
  17. Dogbiscuit
    Offline

    Dogbiscuit Registered Member

    Not to get too off topic but...

    Could you possibly point out how the actions suggested in this thread violate Microsoft's EULA? I can't find anything.

    I've just read the MICROSOFT WINDOWS XP HOME EDITION (RETAIL) END-USER LICENSE AGREEMENT FOR MICROSOFT SOFTWARE Published: June 1, 2004. The only problem I can see arising from this policy would be that the Limited Warranty might not apply if SRP is added to XP Home, as this could be considered 'abnormal use'.
  18. Lucy
    Offline

    Lucy Registered Member

    As already pointed, SRP itself is included in parental control.

    Modifying or applying SRP directly from registry is therefore not abnormal, as it is simply a shortcut to the procedure, and maybe a tweak.
  19. Dogbiscuit
    Offline

    Dogbiscuit Registered Member

    Yes, I understand your point that merely modifying the registry cannot be considered any kind of 'abnormal use'. But I'm not sure what you mean when you say that "SRP itself is included in parental control."

    Frankly, I don't see how any of the actions mentioned in this thread would violate the EULA, so I hope aussiebear explains why he claimed that.
  20. bktII
    Offline

    bktII Registered Member

    Parental controls is a feature of Windows Vista Home (Basic and Premium). It is not a feature of Windows XP Home.

    Also, here is some generic language from Microsoft regarding modifying the registry:
    http://support.microsoft.com/kb/137454 (just a randomly selected URL from MS)
    "WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.

    Wrapping the registry tweaks with an executable with a GUI would be preferable for novice users, which are probably most home users. For example, "enable SRP", "disable SRP", "add/remove/modify file extension", etc.
  21. bktII
    Offline

    bktII Registered Member

    See posts #12, 15 and 17 on this thread " the future of SRP: AppLocker" here:
    http://www.wilderssecurity.com/showthread.php?t=234089

    Parental controls on Vista Home has what one might call "SRP Lite".
  22. Dogbiscuit
    Offline

    Dogbiscuit Registered Member

    Thanks, but the issue I was addressing relates to XP Home.
  23. bktII
    Offline

    bktII Registered Member

    Understood. I was tracing back to Lucy's post first mentioning parental controls. I guessed that you were replying to this. XP Home does not include Microsoft's Parental Controls feature as found on Vista Home.
  24. Sully
    Offline

    Sully Registered Member

    Updates updates updates....

    As has been discussed, part of xp and newer OS's is the inclusion of processes checking the SAFER registry keys when starting. So regardless of version, SAFER values exist and are enabled by default. What is enabled? For one, the allowing of certain key directories, that has been noted you don't want to touch.

    More interesting is that some Hash rules exist for some older versions of files from MS, presumably to ensure you don't get previous versions from some older program that could mess with newer dependencies.

    Anyway, now we know that SAFER registry values exist by default (not sure on xp home but all others it seems). So by using Tlu's or Lucy's registry files, you can add easily to the SRP. Hmm. Let us also state a few things. Pardon me if this is not 100% technically correct. Too many visits to msdn lately.

    Group Policy, aka GP. This is a database, sort of, that holds your GP settings. In xp pro, you would use a MMC snap-in, probably gpedit.msc or secpol.msc to get access to SRP policies. You would set parameters for SAFER or make new path rules, hash rules, etc. Once you create a new rule, I believe that gpupdate is fired. The rule SHOULD take effect immediately. If not, running gpupdate makes it so. When you make this GP rule, a SAFER registry value is also placed into the registry. You can delete the SAFER reg values, and the policies exist still in the GP, so your SRP rules are still in place, but they do not acutally work without the registry values. I have played with it a lot now. Even though you see your rule in the snap-in, the lack of a regsitry value makes it inactive. However, after you delete the reg val, it will not take effect until the registry is reloaded. Rebooting does this, or simply killing explorer.exe and then reloading it will reload the registry. Now that the reg val has been deleted, you see that the rule, still visible in the snap-in, has no effect whatsoever. Running gpupdate does not reinstate it. In fact, once the reg val is deleted, nothing seems to reinstate it.

    Intesting too, say that you make a rule to deny notepad.exe. Ok. Now, if you delete that reg val, and then run notepad, it fails. If you simply kill explorer.exe, and run it without restarting explorer, the registry is already reloaded and notepad starts. Conversely, if you kill explorer, and then delete the reg val, notepad will fail to start until you have explorer up and running again, then notepad will run. Just some interesting stuff to know I guess about how reloading the registry sort of works.

    Back to it then. We can implement SRP on many OS's now with just some registry values, not even needing the snap-in, because indeed the policies listed in the gp will stay visible but inert if the SAFER reg vals are deleted. Nice stuff to know for us geeks.

    Now, let us move on to another feature most talked about using with LUA and SRP. KAFU. While I have not completely immersed myself into all that it does, we know it protects some User autostart locations. A few registry keys and a couple directories. Well, you migh have guessed by now that I have been playing with that too. Actually, I have a while ago created it for my own scripting purposes the same thing KAFU does.

    As I don't even know where my copy is, perhaps some others can help with some testing. My findings are that when restricting the registry, you have 2 modes to use pertaining to KAFU. Normally, (what I found anyway) is that a reg key, say HKCU\software\microsoft\windows\currentversion\run, is allowed pretty much Admin FULL, World FULL, Creator FULL and System FULL. To lock it down, you would use only Admin FULL and World READ. I will say, that it took a few tries to actually get all subkeys to stay protected. This is what I have not tested with KAFU. Let me digress.

    Take this parent key
    HKCU\software\microsoft\windows\currentversion\run

    At first glance, just restricting that key, means that you cannot modify, actually create a new subkey, like
    HKCU\software\microsoft\windows\currentversion\run\NewStartup
    nor, it would seem, can you create a new value in that key.

    However, it is not as straight forward after that. Without some scripting, using common regini.exe will not prevent the creating of subkeys in subkeys that already exist. lol, so if you started with
    HKCU\software\microsoft\windows\currentversion\run\NewStartup
    and you restricted the key
    HKCU\software\microsoft\windows\currentversion\run
    to be read only for World, the command is not recursive. Meaning, while you could not create new keys in Run, you could create any number of new keys/values in Run\NewStartup.

    How does KAFU handle this recursiveness? I don't know. Maybe someone can test it to see.

    Now, we can expound with some further details. Obviously, I have a method that will lock down all subkeys and not just the parent. And a method for reversing this. I found some interesting things though.

    If you run my method, as an admin or as a user, you can lock down the parent key and all the subkeys. If you were to then unlock the registry values, as an admin, it becomes totally unlocked. This is expected. But, what I found as that as a User, you can run the unlock method. This was suprising. Why would a user be allowed to set registry permissions on objects that were set to admin FULL and world READONLY? Regardless, sure enough, a User can run this method, and it unlocks ALL the subkeys. In my example then, a user can unlock Run\MyStartup, and all subkeys/values. However, the parent key Run\, cannot be unlocked by a User, only by an admin.

    So this leads to a question. What does KAFU do. What does it do when ran in admin mode and user mode. Does it present the same strange results? Further, what are the ramifications of this? Is it possible then for something to attempt registry key modification even though one is a user? How does one go about correcting this? Setting restrictions on the parent key above Run\ would be ridiculous. Not something I would want to do.

    There you have it. Ramblings of incessant geekness that pertain to nothing unless you really are a geek like myself. Enjoy.

    Sul.
  25. ParadigmShift
    Offline

    ParadigmShift Registered Member

    What type of scripting? (Great post by the way)
Thread Status:
Not open for further replies.