Exploit PoCs

[HeffalumpAndOrWoozle]

I have some exploit PoCs / CVEs that I've been working on. I will probably have at least a couple by the end of the week. Where do you want me to report them?

[gregster]

For AutoHotkey? I guess you could post them here - for now, your posts won't be visible to the general public until we approve them.
We could then move them to the restricted staff forum until lexikos is back, if deemed appropriate.

[HeffalumpAndOrWoozle]

Okie dokie.

[boiler]

Another thread was created by a new user claiming he was this one but lost access to his AHK account when he dropped his phone and referenced this thread by description. Why he didn't make another post in this existing thread is not known. It all seems a bit fishy to me.

[HeffalumpVersion2]

Okay.

[gregster]

I moved the posts.

[tank]

Exploits do not belong in this community

[gregster]

To be fair, I think this was meant as a friendly warning/report for the developers, and not for the general public.
That's why the OP asked in advance, I would suppose.

[HeffalumpVersion2]

A recap of responsible disclosure in action: someone told me that I couldn't open issues on Github and that I'd have to do it on the forums. I go on the forums and create a post a day or two ahead of time confirming where they want me to submit exploits. I'm told to put them here. An inbox message said that since I'm a new user my posts are restricted and that this is ideal since only XYZ can see them. Great.

I finish my first set of exploits. I go to the spot where I was told to go and I see that as a non logged-in user I can see my post. I point that out -- the idea was so only XYZ users could see it since I'm a new user. I'm told to not make new threads and to just post the exploit in this thread. I post the exploit in this thread. Tank comes along, deletes the first three PoCs and sends me a warning.

Why am I spending hours on fixing your software

[gregster]

Yeah, good pointsm, imo. Sorry, I guess there was a communication deficit on our part, among staff members. Perhaps we can find a better way of handling this. The admins should now decide how they want to handle it.
But afaics the first one was not AutoHotkey-specific, but chm-related. Re the fixing: would you also have a fix for it - or was that a general vulnerability?
(I am not the one handling the docs, but I guess it might be interesting for our guy.)

Btw, your posts were moved, its contents are still there. At least the two posts, I have seen. I don't see any more in the logs.

[HeffalumpVersion2]

Sending PoCs through email

[joedf]

Well, we already have the documentation online. The CHM is mostly a bonus for offline usage. Arguably, people should only be getting the documentation and binaries from a trusted source anyway. Or better yet, just build everything from source.

[HeffalumpVersion2]

Sending PoCs through email

[Descolada]

@HeffalumpVersion2, I can't follow the logic. :/ The CHM file can realistically only be tampered with if you download it from an untrusted source (at which point you've failed already) or you run something that contaminates it (which probably doesn't need to tamper with the CHM anyway to achieve malicious goals). It's difficult to see how such a scenario is realistic, and why AHKs CHM file is in any way special compared to any other CHM file the user might open.

Also, I think it's fair to say that AHK is a general-purpose programming language, so the AHK executable is capable of pretty much anything: it can keylog, download/upload arbitrary files, and anything else malicious you can think of. So if an attacker wanted to do something malicious, couldn't he just trick the user into executing a malicious AHK file? Much easier than tampering with a CHM file.

I wouldn't want to "just get rid of it". Personally I've needed the offline help file multiple times whether when AHK documentations page was offline or if I was having internet troubles. Also there are users who might need to use AHK in situations where there is no internet connection at all. Perhaps there exists a more "secure" help file format that the online docs could be exported to?

[HeffalumpVersion2]

I edited this

[geek]

I haven't seen the PoC to know what's going on here, but I'd say any class of "vulnerability" that results in code execution under the current user context is really not a concern, in terms of AutoHotkey. Wherever AHK is available, just running code through AHK is immediately the better choice than trying to sneak code through the help file. AutoHotkey doesn't have any kind of code signature requirement mode like PowerShell, so you can't normally limit it to not accept any code that is thrown at it. So honestly anything that is an exploit for "arbitrary code execution" can be ignored under the principle that AHK is intended to execute arbitrary code normally.

All that said, if there are genuine concerns about hh.exe being unfit for purpose, we have other options. There is a decent chance that Microsoft is planning to remove it in 2029 when the Trident engine / "IE Mode" is supposed to go fully End of Life, or maybe even sooner with the release of Windows 12. When that happens, I expect it will be fairly straightforward to do two things: first is to extract the docs to the file system, second is to build a thin WebView2 application to load them. Already we do not use the native UI of hh.exe, so really any window with a browser pane should do.

Tangentially: why is the concept of a malicious chm file anything to do with AutoHotkey? If someone was going to somehow modify a component of AutoHotkey to be malicious, why not just modify the executable? The fact that files can contain malicious code is not much of an exploit. And even if we stopped packaging a CHM file with AutoHotkey, someone downloading a tampered version of AHK could get a malicious chm in the package regardless of whatever we say is normal.

Edit to add: If a malicious attacker has access to my computer and is going to establish presence, and has access to write to the CHM file which is normally under Program Files and is accessible only by administrators, don't they have literally endless other better ways to establish persistence than modifying a CHM file? And if we replaced the CHM file with literally anything else that runs as a local application, couldn't they just as easily tamper with that? I don't see what's unique about the chm format that makes this situation more exploitable than not having a chm file.

[HeffalumpVersion2]

I should have the PoCs ready in the upcoming days. Have a good rest of your day, everyone. Sent first three.

[geek]

I realized I didn't point out how the first exploit is to some extent an AHK vulnerability and not just a Microsoft vulnerability. When we decompile and recompile the CHM file it still continues to work as expected, it just does whatever malicious deeds an attacker wants it to do. Like all CHM files -- we can leak ntlm, get RCE, RFI, etc. We can also use psexec, powershell, command prompt, whatever. It can also use malicious vbs files and hta files (I haven't tested HTA files) . We can do all of those things and the CHM file will happily execute them and it doesn't have a way of seeing it the file has been tampered with. The help files continue to work as expected and the user will unknowingly trigger them when going through the documentation. Worse, it's going to spawn off of a legitimate windows binary. This implies that it can be used as a backdoor or as persistence by an attacker. When you decompile the CHM you have a lot of different .htm files to pick from. If you change the search.htm, for instance, and you try searching or you browse to the search section it will execute whatever an attacker added.

So I agree that it's a bonus feature. It just potentially makes a user "more online than they want to be" and it has the potential to add "unexpected friends" to view the documentation alongside you.

Therefore I'd just get rid of it.

Isn't all of this true about AutoHotkey.exe as well though? It's an unsigned open source application that anyone can compile with added malicious code, and (in your scenario) put in place of a legitimate AutoHotkey.exe such that running AutoHotkey.exe executes the malicious code silently while maintaining its original functionality. AutoHotkey has no way to see that the it has been tampered with. And even if it did, that tamper protection could be just as easily removed by the fictional attacker while they're inserting their own code.

Do you have a suggestion for how to address this issue with AutoHotkey.exe that is not "just get rid of it" like AutoHotkey.chm?

[HeffalumpVersion2]

I'm not going to argue with you. This isn't the time or the place -- both of us have better things to be doing. I am also in mild disbelief about the decision to argue against a proof of concept that you can not see. It doesn't add anything to the discussion. I also don't really understand why this thread is visible to the people that it is visible to.

I'm trying to help fix your software. Jeez Louise!

[gregster]

You are approaching the 10 post threshold quickly - so a decision needs to be made anyway (because then most of your posts get auto-approved, but you can send PMs).
@joedf, where should more posts with sensitive information be directed? Email? Or via PMs? Contact form? Not at all?