Hey there, for those of you that roll your eyes when writing the nth Information Disclosure Finding in a report, here is a short story of how such information helped compromising a system.
In a recent penetration we found a hidden debug page which disclosed information about internal parameters. Along with database connection strings and key material there was a username and a user home parameter disclosed on said debug page.
Lesson 1: Disable DEBUG in productive environments. Don’t hide behind unknown URIs.
A preliminary port scan showed an open SSH port on the server and the disclosed username implied that it is also used for continuous integration and deployment. This will be important later.
Then, we found a neat path traversal vulnerability in a file upload form. According to the error messages we were able to create new files, but can’t overwrite files. The error messages were verbose enough to distinguish an existing file versus no access rights on the file system. This could also be used to enumerate each and every file in /etc for example.
Lesson 2: Log errors verbosely; Show generic error messages
By now we have an arbitrary file write on the system. We know the username and home path of at least one user on the system. This user presumably logs in via SSH periodically. I think you know where this is heading.
A quick check revealed that ~/.ssh/authorized_keys already exists and we are not able to overwrite existing files. What we can do is create new files. This is where the next information disclosure comes in handy. The SSH banner as well as the HTTP Server header tell us which Linux distribution is running on the system. And often bash is the default shell.
A quick “image upload” later a ../../../../../../../home/$user/.bash_profile was deployed which contains our ssh public key and appends it to ~/.ssh/authorized_keys.
And now we play the waiting game…
Well, actually we didn’t, since we have the comfortable situation to ask the developers to run the deployment in the test environment 😉
Afterwards, we were indeed able to log in via SSH. It was quite messy with all the files our arbitrary file write testing produced, but here we have our system compromise.
Of course, all of this would be possible with the arbitrary file write on its own. But if we wouldn’t have had the information from the error messages and the specific username and home directory it would have been exponentially more difficult.
So it’s true what we write in our reports: “An attacker might use this information to prepare and launch further attacks more precisely.”
cheers Pascal