vuLnDAP Walkthrough
Fri 3rd Aug 18
This is a full walk through detailing how I would go through my vuLnDAP challenge. There are probably plenty of other ways this can be done so don't take this as the only or best. If you do have a better way, please let me know.
Start by browsing to the stock control system, select Fruit and notice the URL is:
/fruit_or_veg?objectClass=fruits
Here is the first injection where you can specify different object classes. You could try to guess or brute force valid values but the easier way is to use a wildcard, for LDAP that is *, that gives you the following URL which shows you a list of all objects in the system including the users and groups.
Fred the CEO looks like a good target, selecting his account gives you more information but not much.
Check the URL and you see the following:
/item?cn=fred&disp=stock,description,cn
The parameter disp is a list of search filters, these tell the LDAP query which fields to return for the specified object, any which don't exist are silently ignored. Currently the search returns the stock level, the object description and the common name (cn), which is perfect for a stock control system but not much use for us wanting to extract user data. To see more information, you have to specify the right filters. Unfortunately, there is no wildcard feature here so, without a bit more digging, you would have to guess field names.
If you do some more looking around you'll notice that the back link takes you to the following URL with a new object class, posixAccount:
/fruit_or_veg?objectClass=posixAccount
So, before when looking at fruit the objectClass was fruit, now we are looking at an objectClass of posixAccount and are seeing a list of users. Googling posixAccount and LDAP you'll find that posixAccout is a standard schema used to describe users, here is a good write up on it from the Linux Documentation Project. The following are four extra search filters it mentions:
- uidNumber
- gidNumber
- homedirectory
- userpassword
Lets give these a try:
/item?cn=fred&disp=description,cn,uidNumber,gidNumber,homedirectory,userpassword
That's pretty good, we've got some details for Fred, not his password, I'll come back to that later, but remember the brief also talked about SSH keys so lets look for some of those. Back to Google, this time searching for LDAP and SSH keys. There are plenty of hits, this is a good one SSH Public Keys in OpenLDAP, but if you read any of them you should find that when you want to store SSH keys in LDAP you use the sshPublicKey field. Lets try adding that to Fred's search filters.
/item?cn=fred&disp=description,cn,uidNumber,gidNumber,homedirectory,userpassword,sshPublicKey
Jackpot, we've got Fred's public SSH key, but really, that isn't much use as that is designed to be public. What about checking the other users that were listed way back at the start when we listed all the posixAccount objects.
Nothing interesting for Sue:
But look what we've got here, looks like someone messed up creating my account and put my private key in by accident
From here it should be a simple case of grabbing the key and SSH'ing your way round the network having fun as you go.
A quick step back, when we listed the search filters, we asked for userpassword but did not get anything back, that is because the field is only used for authentication, it unfortunately cannot, as far as I know, be retrieved.
I hope you have enjoyed this walk through, as I said at the start, this is my first foray into LDAP and so both the implementation and walk through may not be exactly as they would be in the real world but I hope they are close enough to give you an idea of what to look for when you come across LDAP and give you some ideas for further experimentation on your own. Any constructive feedback is welcome.
One final thing, before you go throwing SSH logins at my boxes using that key, save yourself the effort, it was made up just for this project and if you look very carefully you will easily be able to confirm that.