Security Bug: Unauthorized editing of active config.ovpn is possible

[Josh Campbell]

Platform Tested:

macOS 10.15.7 (19H2) (Catalina)

Tunnelblick Versions Tested : 

3.8.5a (build 5671) 

3.8.6beta03 (build 5700)

Bug Description (Steps to duplicate):

1. Edit the config.ovpn of an installed configuration on MacOS Catalina here: /Library/Application Support/Tunnelblick/Users/MyUsername/MyConfig.tblk/Contents/Resources/config.ovpn
2. Save config.ovpn
3. In Tunnelblick, click on configurations tab, select the configuration that matches the one you just edited.
4. Click on connect.
5. You are presented a window with 3 options and the following prompt:
6. The effects of the two buttons [Revert to the Last Secured Copy] and [Secure the Configuration] are reversed.
7. Clicking on [Revert to the Last Secured Copy] accepts the changes made (without asking for a Mac user password) and proceeds with connection using the compromised config.ovpn file.
8. Clicking on [Secure the Configuration] asks for your Mac user password then overwrites your edit with the last secured copy of config.ovpn.

This exploit does require physical access to your Mac that is already unlocked. And you must have the Mac user password anyway to edit the config.ovpn file so it is trivial at most. This bug is more an annoyance because the buttons are backwards. 

[Tunnelblick developer]

Can anyone confirm this? I cannot reproduce this behavior with Tunnelblick 3.8.6beta03 on macOS Mojave (10.14.6).

[Tunnelblick developer]

I have tested this on macOS 10.15.7 and cannot reproduce the problem – each of the buttons works as intended.

Are you absolutely sure that the Revert button connects using the altered configuration file? I don't understand how that's possible. Tunnelblick always uses the secured copy when making a connection and that copy cannot be changed except by entering a computer administrator's credentials.

When you click "Revert to the Last Secured Copy":

1. Tunnelblick overwrites the (modified) insecure copy of the configuration (which is always editable by the user) with the (original) secured copy (which can only be modified by a computer admin).
2. Tunnelblick starts connecting the (original) configuration.

When you click "Secure the Configuration":

1. Tunnelblick will ask macOS for authorization to modify the secure copy.
2. macOS asks for a computer administrator's username/password.
3. Assuming a valid username/password are given, macOS gives Tunnelblick an authorization
4. Tunnelblick uses the authorization to overwrite the (original) secured copy of the configuration with the (modified) insecure copy.
5. (Tunnelblick does not attempt to connect the configuration.)

The insecure copy is in ~/Library/Application Support/Tunnelblick/Configurations/NAME.tblk/Contents/Resources/config.ovpn.

The secure copy is in /Library/Application Support/Tunnelblick/Users/USERNAME/NAME.tblk/Contents/Resources/config.ovpn.

[Josh Campbell]

Yes, 100% sure. I can do a screen capture if you need to see it. But...

- As stated I am editing the secure copy in /Library/Application Support/Tunnelblick/Users/USERNAME/NAME.tblk/Contents/Resources/config.ovpn. 

- If I edit the insecure copy is in ~/Library/Application Support/Tunnelblick/Configurations/NAME.tblk/Contents/Resources/config.ovpn. the buttons on the confirmation prompt function as expected. 

Editing the secure copy breaks the configuration security prompt. It seems Tunnelblick should detect that the secure copy was edit and either scrap the config all together or at least prompt you about exactly what happened. It looks like it is comparing the the two files and ASSUMING the insecure version was edited when in fact the secure version is the file that changed. 

Maybe save and encrypt a hash of the secure version to ensure that configuration is actually secured rather than just comparing two files, either of which can be edited. Or maybe it's so fringe that it's a non-issue.

[Tunnelblick developer]

I'm sorry – I overlooked that you were editing the "secure" copy and assumed you were editing the "insecure" copy.

However, I think it is a fringe issue; you have to go to a lot of trouble to modify the "secure" copy and nowhere in our documentation is it recommended or even hinted that anyone should do that.

In any case, I don't consider it to be a security bug because you can't connect using a configuration that was not approved by a computer administrator. That would be a security bug!

Dealing with this is too much trouble for too little gain (in my opinion). (If, for example, we used a hash to detect changes,  the hash could be modified as well, and we would be back to where we started!)

[Josh Campbell]

Understood. I was just poking around and fuzzing in my free time on some of the apps that I rely on and thought this might be worth mentioning.

If a malicious app already had escalated privileges and was then able to modify your VPN config that would be a pivotal attack vector. How ever you are correct that it would be very situational, and if the machine is already rooted then you are powned anyway.

-Josh

https://attack.surf