Scripting SecurityAgent windows (SD Crashes, SE doesn't)

(Phil Stokes) #1

So I guess this is a bug report, but there’s a couple of wider questions here.

It came up on some of the security forums that this hack/trick/feature to reveal keychain passwords still works on Sierra, and probably High Sierra too:

(though in Sierra at least you need to remove the ‘of group 1’ part in the click command line).

Someone then mentioned that they thought Apple had made changes to stop malicious actors from scripting SecurityAgent windows, and I was sure I’d heard that too, but after doing a bit of a google searching, and searching ASUsers, I couldn’t find any mention of it.

Having tested the above-linked trick and found it worked, I wondered if maybe it was just Security windows that needed a password filled in that had been blocked, but no. In Script Editor, if I get an app to throw a password request dialog, this script will fill out the password and click the ‘OK’ button without issue:

tell application "System Events"
	# repeat while exists (processes where name is "SecurityAgent")
		tell process "SecurityAgent"
			tell its window 1
				tell text field "Password:"
					set its value to <insert admin password here>
					perform action "AXConfirm"
				end tell
			end tell
			click button "OK" of window 1
		end tell
		delay 0.2
	on error
		# exit repeat
	end try
	# end repeat
end tell

This is the kind of window I’m talking about:

In Script Debugger, however, the password is filled in, but then SD crashes (well, I should say it quits unexpectedly). Relaunching Script Debugger and running the same script again (the same Security window is still open, with the password filled in from the first run of the script), SD now clicks the button as expected and doesn’t self-terminate.

Why SE will do this in one pass without self-termination but SD doesn’t, I’ll leave to you guys to figure out! Hopefully you can reproduce it your end without the crash reports, or I’ll have to set it up on a VM machine in a virgin account.

That leads me to two questions:

  1. did I hallucinate the whole ‘Apple blocks scripting on security windows’ thing (if so, I wasn’t the only one)?

  2. I notice that Little Snitch windows are completely opaque to System Events and GUI scripting. Neither SD nor Accessibility Inspector can introspect them at all. How is that done? I understand that the window has to be a child of the window server to be accessible to System Events, but how is it possible to build an app with windows that AREN’T registered with the window server? Not really expecting any answers on that one, just a bit of a surprise to me that it can be done.

(Shane Stanley) #2

Yes, thanks. Quite odd.

I’d imagine it can be done by doing the UI in your own code, bypassing normal controls. You might also be able to things via the accessibility APIs.

(Phil Stokes) #3

No, I didn’t dream it. I wonder what ‘synthetic clicking’ means? Using key codes perhaps? Seems odd that it still works.

Available for: OS X El Capitan 10.11
Impact: A malicious application can programmatically control keychain access prompts
Description: A method existed for applications to create synthetic clicks on keychain prompts. This was addressed by disabling synthetic clicks for keychain access windows.

(Phil Stokes) #4

Just to complete the story: It appears that Apple re-enabled the ability to perform synthetic clicks in 10.11.5.