Trying to Find a Bug in WordPress

let me tell you the story about some WordPress security research that I did specifically in a tech idea involving md5 hash collisions I hope by doing videos like this I can show you how the security research process can look like so here's what we will discuss first how did I find this research topic and why did I want to look into this basically what is the resource question then how to prepare the research environment the research set up so we can actually do something and then third we are going to do the actual research [Music] as you know we are currently working on our online training website hexfree.io and I was working specifically on a course about typical identifiers used in web applications and how that affects security and as you know the way I like to teach stuff is I don't just tell you how it is but I want to encourage digging deeper and provide a little bit more context and so for the video about slugs these human readable identifiers I thought it would be interesting to have a quick peek into the source code of Wordpress being maybe the most popular content management system seeing how they deal with it I think that can be very educational and so from a stack Overflow article I learned about the get Page by path function and that appears to be used to get a page given a path which can be a slug and the WordPress documentation directly shows the source code of this function which made me take a minute and look at this and in there you can find the SQL query where they are looking in the database for the Post basically matching the slug however before this SQL code is actually caching related code here they take the page path basically the slug create an md5 hash of that and use it to build a cache key and then they use that to check if the post is already in the cache if that's the case they return the post and only if that is not in the cache they do the SQL query so now I want you to take a moment and think do you have any ideas what we could research what I mean is do you have any ideas what could go wrong here is there anything that you maybe find risky anything for example you saw the SQL query and they use string concatenation here and not prepared statements so is this function vulnerable to SQL injection that is a perfectly fine research question and if your brain thought about that your brain is already in the hacker mindset now personally my brain also thought this is WordPress if there were an SQL injection in this prominent function no way nobody found this so this must be implemented securely though this is maybe a flaw of my brain I always make these assumptions and I think that's where I sometimes fail to find the obvious vulnerabilities because my feelings at the start just tell me probably safe so while I did have this thought is there an SQL injection it has a low priority for me and I had another research question I found more interesting so if you thought of another research question let me know in the comments what you would have investigated because I'm telling you now what sparked in my mind and it has to do with caching now let me add a disclaimer right away this is research you sometimes have dumb thoughts that turn out to be completely wrong but I think this is part of this research process and it's a creative process so it's never a problem to have dumb ideas it's only a problem if you have no ideas so as long as you have research ideas even if in the end they turn out to be wrong I think they are still valuable and that's why I'm sharing the story with you spoiler alert the idea turns out to be dumb but through this process we still learn a lot and that's why all in all this is a positive experience alright so what was my caching related research idea basically the slack is md5 hashed and then used as a cache key if the post is in the cache the page gets returned if not then SQL query is performed and the result is stored in the cache in the next time the page with slug is requested now it can take it out of the cache so now I'm wondering if there is an md5 Coalition so if two different request Pages result in the same md5 hash what would happen of course if page a was stored in the cache and then you try to access page B with the same md5 hash obviously it would return page higher WordPress allows you to have private and public pages so what if page a was a private page stored in the cache and we request page B which is public then could we leak the private page if the cache key is the same this idea sounded like a much cooler attack to me than checking for lame SQL injection so this is the rabbit hole I went down after I had this abstract idea I was thinking about feasibility because in the five collisions exist but that does not mean md5 can be collided in every case if we know there exists a private page a with this md5 hash there is no known attack that allows us to create a different input with the same hash md5 is still safe against that however if you can somewhat control all the inputs then it's possible let me explain how the md5 Collision Works when md5 hash is computed on input it's calculated in blocks with each block of data an internal state is updated and that state is basically the resulting hash add another block update the hash so hashing the same blocks result in the same hash but they exists an attack where you can generate two different blocks or maybe multiple blocks that are different some bits are different and they produce the same hash okay but how does this help us so basically what you can do with this is you can have the same blocks same data then a part that is different but results in a same internal state or hash and then you can append more data as long as the same blocks so let me repeat that you can have the same blocks the same data then a part that is different but results in the same internal state or hash and then you can append more data as long as the same blocks but how could we abuse that could we craft two post paths that are mostly the same but have some differences and end up with the same hash and cache key of course at this point I haven't figured out all the details there are lots of small problems that need to be overcome for example these Collision blocks are typically just pretty random bytes probably not ASCII text like a URL path would be but because the md5 attack is old maybe somebody managed to find an ASCII only Collision since then I tried to look for that on Google myself with no luck so I decided to tweet maybe somebody knows something but also maybe it's not necessary you can URL encode raw bytes with percentage 0a for example representing the byte hex 0a so maybe we can easily send raw bytes as input so while we are not 100 sure about that this will work with research sometimes we just make assumptions we just assume we can craft two URL paths with the same md5 hash and so let's just continue now remember our original attack idea we are trying to access a post a that is hidden by trying to query post B which is public and ends up with the same cache key so the problem is we cannot control the path of post a and we know there's no md5 attack where we can just Target that hash however maybe we can do some URL path trickery in my mind I had this weird idea where if we know that there exists a secret post a then could we maybe craft two URLs like this slash then we have the md5 Collision part dot dot slash secret page a and we know that the Collision block will be the same but a little bit different we cannot really control the bytes but using Brute Force generating multiple different Collision blocks maybe we can get a bit lucky and maybe we can get two URLs that look something like this just by random chance dmd5 Collision block maybe contains slashes for one post but not for the other turning that into a path traversal and after normalization it will then point to secret post a while the other one has random stuff but no slash so the two dots are not a path traversal and Then followed by secret post a so that probably should give us a 404 not found error but certainly not it's a private post no access error but there's another small problem of course this URL would result in a different cache key than just secret post a so this version of The Secret post URL will will never be loaded into the cache by an admin right but I have a solution we could trick the admin to visit our malicious website then in the background we load this URL kind of like a csrf and then that will populate the cache with the secret page requested through this specially crafted URL and now we are in possession of this other path that theoretically leads to a 404 page but results in the same cache key and that might return the secret page I mean there are still lots of open questions lots of I assume this just works a lot of hand wavery but I thought maybe yeah something worth exploring to me that seemed like an interesting research question so I decided to finally get my hands dirty and try this out and for that we needed a WordPress setup for testing I looked up the WordPress development repository and found this one with some development setup instructions and apparently they support something called Dev containers that can set up a developer government environment for you with just one click I didn't know that this exists so that's awesome learned something new but instead of using the dev space directly on GitHub in the web browser I decided to clone the repository and install the vs code extension for Dev containers of course you also need Docker and so forth but if everything is installed and I opened the repository I could prompted here and I can reopen the project in the dev container this will run now for a while set up all the dependencies but eventually it will launch a server and expose the port and we should have a working WordPress development setup we can now access WordPress on localhost 8080 log into the admin and maybe create a test page but problem when I now change something for example here in the wp login.php site I try to change the title adding test debug and then load the site in the browser the change is not there I understand that the dev setup created containers to run the site but I did hope that there is a volume mounted or whatever so we can actually do development and debugging I want a development setup for debugging like setting breakpoints and so forth well right now obvious code is connected to the dev container but we can also connect to the app container this container should actually run the server with WordPress we open that and here we have the code again so can we make modifications here turns out this container runs with the WordPress user permissions and the WordPress files belong to the WWE data user so we are not allowed to write them ah I looked around a bit how I maybe could attach vs code using a root user couldn't figure that out in the end I just GH modded recursively the whole folder made all the files writable and now we can make changes and they show up but what I really want is debugging breakpoints and single stepping so how does that work with PHP I've never done that and I expected this to be set up in the dev container for us reading over a few more articles I learned that there exists a PHP debugging feature called X debug and you can install the XD back extension for vs code but you also need to configure your PHP server installation to use xdebug in a pair currently you should change the xtiba config in the PHP ini file also it should show up in the PHP info output so I added a file with a simple PHP info output and here at least I found the PHP any path but none of them contained X debug info and there is generally no info about xdebug anywhere so maybe that's not installed in this container I then try to install XD but the packages just didn't work WordPress is an extremely popular framework there must be tutorials out there how to get the debugging development environment so let's backtrack and look specifically for that at least we now know that the PHP debug feature is called X debug so we can specifically search for WordPress xdeback setup and look at that I found a small repository with instructions and a Docker compose file to set up an X debug environment so I set that one up had to make a few changes to the paths in the docker compose file to mount the PHP code to the local folder and also set the IP for The Host where X debug will be running and then Docker compose up which appears to work I now have a new WordPress setup that I can open in the browser but the real question is can I debug now so in vs code I make sure the debug PHP extension is installed and then we have to create a debug launch.json configuration file which contains the port that xdback tries to connect to as well as the path mapping so where the PHP code is stored also you can see that this configuration is called listen for XD feedback because this is how it works the PHP X debug extension installed on the web server will try to connect to the configured XD by client on the sport 9003 and on our development machine this vs code setup will launch the xdback client that is listening on Port 9003 waiting for a connection so it's actually a server listening on Port 9003 but it's called the client in the config I know this is confusing just watch my what is a server video and you will understand I hope anyway when we now launched this debug config in vs code we are now waiting for a connection now let's add an XD by break function call somewhere in the code maybe in our get path function and when we then try to access the page like this test page the site gets loaded and vs code pops up execution paused right here now we can explore the variables and we can single step forward so we just calculate the hash of the page path and we create the cache key and now we check if the page is in the cache of of course it's not yet so we get false and we continue eventually going into the SQL query cool let's try to request the page again to see the cache at work but still not in the cache what I think this is because WordPress doesn't support caching out of the box so I decide to install the first cache plugin I could find and enable the object cache that took again a while but eventually it works the page is stored in the cache now we can really test our attack we have a debug environment we can step through the code we can examine the variable this is exactly the kind of setup you want for doing research but this is also when I realized my whole idea does not work it was flawed from the beginning I got so excited about my idea that I missed a crucial part this function returns a page or WordPress post and this post object has different properties these properties for example include the post status so if it's private or published but also the password in case the post is protected so this function returns this post object given a path even when we are not the admin we can request the page with the secret post a path this function simply gets you the Page by the path whether you use an md5 Collision or not it doesn't matter it just Returns the post for the path there's no authorization check here these checks are done somewhere completely else so if this function Returns the post object of the secret post a because we just requested exactly this post or we happen to have an md5 Collision then obviously your post status or the password is still the one from the secret post a we still cannot access it ouch yeah well there goes a full day of work and you watched a useless video just kidding yes it's frustrating and maybe that ruined the whole video fun for you it kinda sucks that this work seems to have been for nothing but this is not completely true I learned so many new things I learned about Dev containers this is the first time I looked at WordPress code which gives me more experience in how framework code can look like it looks incredibly messy I have to say also I've never debugged PHP before usually I just print r or Echo to debug PHP so learning about X debug was really cool also I practiced reading code I practiced learning new technologies and I practiced failing which is important I have failed with so many research projects that failing doesn't bother me anymore of course it's more thrilling to find a valid bug that's the feeling why we all do this but not finding something also doesn't tear me down I will move on to the next idea so all in all it was still a good project to pursue and I hope you also learned something about WordPress debugging PHP and the five collisions and how security research can look like so let me know what you think about this kind of video format covering failed research and check out hexfree.io where we are building online courses on webpacking but also other topics such as reverse engineering and Hardware hacking and you can follow us on Twitter historyio and of course visit our website hickstreet.io hopefully we can help you grow your it security skills as well and if you want to support my videos on YouTube like this one check out my patreon or YouTube membership or check out my font at shop.liveoverflow.com somebody maybe it was a dream I'm not sure somebody at least told me you can research code much better when you use that font not sure if I believe that but I mean why would they lie about that [Music] foreign [Music]

Channel: LiveOverflow

Views: 91,019

Keywords: Live Overflow, liveoverflow, hacking tutorial, how to hack, exploit tutorial, wordpress, xdebug, php debugging, wordpress security, hacking wordpress, wordpress plugin, caching plugin, md5 hash, md5 collision, md5 collission, hash collision, fastcol, failed security research, failed research, docker, dev containers, vscode, auditing php, cache, object cache, wp plugins, wp development, php debug

Id: lLjgskJgaRU

Length: 18min 6sec (1086 seconds)

Published: Sun Jun 11 2023