5 replies to this topic

[tank]

Since i use AHK in the corporate world professionally. I thought i might start a formal discussion on security issues in the corporate workplace. If particularly clever posts are made documenting a good security control i will link to it.

 

First lets start the discussion around issues i have had raised in corp security

 

• Residency- Scripts need to be seen as being altered only by authorised personnel. this introduces a number of control points.
  • Version Control. only one production version can be used at a time
  • Code Viewability. Script should not be stored within the native OS
    • sensitive contents that may be inside the script such as passwords should be difficult to gleen
  • developers should have to document changes to code and have it reviewed before being put into production.
• Access to scripts should be  restricted to only the users that require  it. 
• Rogue scripts should be scanned for and removed
• Does not compromise existing security standards. Many corp environments require a desktop to lock automatically after a certain amount of inactivity. the  scripts should not prevent or otherwise impede normal security controls.Data accessed from secure network locations should not be retrieved in mass and stored in incorrect locations by scripts

This thread will not endeavor to cover every security concern. I will update the OP as Items are discussed and solutioned. I intend to also post specific solutions that i may have used to mitigate issues. I welcome feedback from all skill levels but lets refrain from conversations about how open source means it should be freely available. 

 

 

[toralf]

How do you want to scan for rogue scripts? Depending on the order of a few commands a script could be save to SEC or bad for SEC. The difference will IMHO be difficult to find automatically.

AFAIU you want to give the user the ability to write their own code, right?

Or will only IT or certain admins be allowed to write, compile and execute scripts?

You would need to scan every drive (incl. USB sticks) and all the files to even find scripts that are mischievous. They could be any kind of file type or name. You would need something like a virus scanner specific for AHK code and compiled scripts just to find them all and in real time.
I had AHK on a stick with scripts so I could use it everywhere I needed it.

I do not believe that overly restrictive rules prevent data breaches. There are too many possibilities data can be transported unnoticed. Thus I believe that an education for users to do things right is better for SEC. It opens a lot of potential for increase of efficiency.

[VxE]

I also use AHK professionally (though I don't have to deal with security... because there isn't any!) and I have some ideas to address restricting user access to scripts and to the AHK interpreter itself.

Of course, none of this is bulletproof, but a decent salesperson can pitch it to management as though it were.

The basic idea is to use a service script running on each user's computer that waits for a user to log into windows. When a user logs in, the script connects to a database and requests the text source of each official script that user is supposed to have running.

The service script then launches those scripts with normal user permissions (requires research... this looks promising).

The database can be set up on any old laptop, then you can physically lock the laptop somewhere safe (use VNC for maintenance).

Come to think of it, the service doesn't have to be a AHK script; it can be written in a more suitable language.



To block users from running their own scripts (searching for script files is a bad idea) just associate (shell.open) AHK scripts with a compiled script that tells the user "Authentication failed. Cannot run AutoHotkey."

</brainfart>

[toralf]

How do you want to block the shell.open, when you do not know which file extension is used?

The user could as well just drag and drop the file on AutoHotkey.exe.

[Elesar]

Here is my current setup:

 

I have a hook into the windows domain login script. This hook points to a VBS that I can change at will to attach any AHK scripts or other items that I want to run on my users desktops at each startup.

Dim root:root="\\path\to\my\share"
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objShell = WScript.CreateObject("Wscript.Shell")
Set objNetwork = CreateObject("Wscript.Network")
Set appShell = CreateObject("Shell.Application")
objDesktop = objShell.SpecialFolders("Desktop")
objTemp = objShell.ExpandEnvironmentStrings("%temp%")

'<============================================================================>
'<=====  Shortcut Setups  ====================================================>
'<============================================================================>
'<=====  Setup Network Program Shortcut  =====================================>
Set objLink = objShell.CreateShortcut(objDesktop & "\Network Program.lnk")
objLink.Description = "Network Program"
objLink.TargetPath = "\\path\to\Network Program\Network Program.exe"
objLink.WorkingDirectory = "\\path\to\Network Program"
objLink.Save

'<============================================================================>
'<=====  Link Setups  ========================================================>
'<============================================================================>
'<=====  Setup Web Link  =====================================================>
Set objLink = objShell.CreateShortcut(objDesktop & "\Some Website.url")
objLink.TargetPath = "http://somewebsite.com"
objLink.Save

'<============================================================================>
'<=====  Run Programs  =======================================================>
'<============================================================================>
'<=====  Compiled Script  ====================================================>
objFSO.CopyFile root & "\Compiled Script.exe", objTemp & "\", true
objShell.Exec("""" & objTemp & "\Compiled Script.exe" & """")

'<============================================================================>
'<=====  Cleanup  ============================================================>
'<============================================================================>
Set objShell = Nothing

As far as security goes, there isn't much at the moment. This simply allows me to publish scripts (and desktop shortcuts) to all domain users every time the login, so they can't claim that they don't have a standard item on their desktops

 

AHK isn't installed on individual machines, and isn't allowed to be (monitored with spiceworks and uninstalled if found - this is standard practice for any unwanted software, not just AHK). As far as AHK specifically, I'm fairly confident at the moment that I am the only user at our location that even knows what it is (rural hospital, most people can't operate MS Word on their own).

[Person93]

How about replacing AutoHotkey.exe with a compiled script that checks if the script being run is authorized for that computer and user, if it is, it runs it with the real Autohotkey which is stored under a different name.