[#thread š§µ] For this 23rd day of #CyberAdvent, we will talk about the LDAP structure and its naming contexts. š¦
[#thread š§µ(2/10) ] LDAP is a directory structure (a tree) containing objects with their attributes:
[#thread š§µ(3/10) ] You can search for objects in the LDAP with a query on a specified base object and a search scope. In return, you will then get a list of matching objects with the attributes you selected.
[#thread š§µ(4/10) ] There is three values for the search scope, BASE, LEVEL, SUBTREE.
- BASE: Only search in the given object.
- LEVEL: Search in the objects at the same level as the the given object.
- BASE: Search in the subtree of the given object.
[#thread š§µ(5/10) ] When I wrote ldap2json, I was trying to export the whole LDAP data all at once, so I decided to use a SUBTREE search on the DC=LAB,DC=local root object of my domain and I got a weird behavior:
[#thread š§µ(6/10) ] I noticed CN=Configuration,DC=LAB,DC=local did not appear in the results of SUBTREE search on DC=LAB,DC=local. But I could request it directly without problems. Why shouldn't they appear in the results ? Yesterday @cnotin pointed me towards naming contexts.
[#thread š§µ(7/10) ] The naming contexts (or directory partitions) are independent partitions of data inside the LDAP, hence we cannot find them in a SUBTREE query as we would have to switch partitions to access them.
[#thread š§µ(8/10) ] Fortunately, the list of naming contexts is given in the RootDSE object of the LDAP server and returned when we connect to it. I was able to get all of the naming contexts easily from the ldap_server object like this:
[#thread š§µ(9/10) ] Therefore in order to dump the whole LDAP data, I first needed to execute a query on RootDSE to get the list of naming contexts, and then iterate over the naming contexts to dump the data of each partition:
[#thread š§µ(10/10) ] I hope this thread has helped you understand the naming contexts! I was really confused about this until @cnotin explained it to me. Many thanks to him š„³š
ā¢ ā¢ ā¢
Missing some Tweet in this thread? You can try to
force a refresh
[#thread š§µ] For this 20th day of #CyberAdvent we'll be talking about the Local Admin Password Solution #LAPS of Microsoft, and how it can be used to reduce the risk of network pivoting of attackers.
[#thread š§µ(2/6)] One of the common vulnerabilities found in Windows domains is a distributed local administrator on the workstations (sometimes even servers). This means that if an attacker compromises one machine, all the machines with the same administrator password are owned.
[#thread š§µ(3/6)] The attacker can then connect to all the other machines of the network using LM:NT hashes found on one compromised host! š
[#thread š§µ] For this third day of #CyberAdvent (3/24), I'll tell you a story. The story of how I gained root access to a server by leveraging a really fun feature in a web application. This #pentest#writeup will explain the complete process from recon to root. š¦
[#thread š§µ(2/9)] In the recon phase of my pentest, as usual I was performing a port scan. In the output from nmap, I saw an uncommon port 86 with an HTTP server running "Micro Focus DSD 1.0.0":
[#thread š§µ(3/9)] When going on the page from a browser, surprise š„³š we have an unauthenticated access! This is cool, but I never saw this app before so I didn't know whether we could exploit it simply or not!
[#thread š§µ] For this second day of #CyberAdvent (2/24), we will be talking about a common #PrivilegeEscalation when using the * (wildcard) in shell scripts. Almost everyone has used at least once the * (wildcard) in a shell script but what really happens with the #wildcard ? š¦
[#thread š§µ(2/7)] We will take as an example this shell script, performing a backup of a website using tar and a wildcard:
[#thread š§µ(3/7)] In this script, the shell replaces the wildcard with matching files from the current directory then executes the command. The * character is never sent to the command (TAR in our case) instead a list of matched files will be sent as arguments to the command.
[thread] Did you know that ssh tries to authenticate with stored keys BEFORE the key specified with -i in the command line ? I just noticed this, the hard way š.
Let's imagine you have more than 5 keys loaded in your ssh agent. When authenticating to a remote server, you get:
After this message, ssh tries to authenticate with the keys in the order listed above. Why is that a problem ?
Because most servers have a default configuration with MaxAuthTries set to 6. After 6 tries, you will get a "Too many authentication failures" error.
So, ssh tries to authenticate with the keys in the order listed above, but gets disconnected after 6 tries. This means that if your agent has more than 6 stored keys, the key specified with -i is never used. This means you can't login to a remote server and you might not know why