Wanted to leave a quote I heard from somewhere a long time ago: "The master has failed more times than the apprentice has tried." Great content as always!
i think that idea is appealing, but in reality Wordpress is such a massive project, there are so many other eyes on it, with much more experience with WP internals. i think the low-hanging fruit (xss, SQL injection, hash collision, etc.) have mostly been tackled.
Even if the hash collision isnt feasible, it's still good practice to also store the original key in the cache so that you can check for collisions. Pretty much all standard hashmap data structures do this.
@@schwingedeshaehers Passwords don't need to be unique i.e. two users can have same password and you can get away with duplication. On other hand hash for identification needs to be unique. There's a difference between usecases.
2:10 - I thought exactly what you did. I saw the code and thought "Oh, definitely SQL injection" and my next thought immediately after that was "This is Wordpress. If there was a SQL injection flaw here I bet it would have been exploited (and fixed) ages ago" lol. A lot of people would be amazed at how many obvious flaws lurk around in popular open source and closed source applications 😅
i wasn't sure what you were trying to accomplish analyzing that function given that it's clear the access control wasn't being done in it. glad to see i wasn't wrong in the end haha
I love this video, simply because I thought "okay cool, you can get the site through a md5 collision, but this does not necessarily mean that you have permission to look at it", and then I watched till the end and you found it out yourself. This just took off some of my impostor syndrome thoughts xD
2:58 Along with the SQL injection and MD5 hashing, I'm also pretty concerned about the URL encoding/decoding with $page_path, especially where the space and forward slashes are replaced using str_replace. Also, those rawurlencode and urldecode functions do not look like a pair. Just generally getting a lot of Log4J vibes from those three lines.
While it didn’t matter in this case, a Chosen Prefix MD5 collision is also really powerful! It requires you to create your own collision, but that only takes a few hours. With that you can make two completely different starting blocks, and turn into the same hash again by adding special collision blocks at the end. With that the difference in the two hashes can be as big as you want, and you are not limited to the 2 bytes or so that are different in the collision that was shown Awesome video as always. It’s important to try every idea you have, no matter how weird it might sound at first, until you have no ideas left and have completely convinced yourself that everything is safe
Love the part where you want to debug, but spend hours on setting up the entire thing 😂 I feel you. Btw love videos like these, where you highlight the fails as well ❤
More of this. People nowadays tend to have really unreasonable expectations, they think everything is sunshine and flowers, but often times it's not. It's about recognizing that without failure contrasting success, succeeding would be worthless. It's about pulling through failure and learning from it to hopefully do a better job next time.
I really love the format of the video! Highlighting the research journey including every dead-end makes the whole process a lot more tangible than simply showing the polished end result in the rare case of success. Thanks a lot :)
Useless video u said? NO this video is very useful. We can know how security researchers work. How do they do try and error to get interesting findings. Keep doing things like this. i love it!
I actually caught that from the beginning of the video. I was like "Even if he requests a private page there must be privacy checks". I have made and maintain 3 wordpress sites and I can tell you that the best way to find an exploit is to look for it at the plugins. Wordpress sites get hacked very often just because of vulnerabilities in the plugins.
This video made very important point! Whether the research is on computer security, math, physics, biology or really any field of science, you need to be very resilient against frustration! And the attitude towards failing is extremely important part of being resilient. There is no human intelligence that could save you from failing. Of course intelligence will help along with critical thinking skills, but failing will never stop, no matter how successful you will be.
That twist at the end really got me! I'm a WordPress developer and know a bit more about the internals. What got me confused from the beginning was your line of thought with the cache. Since HTTP is stateless and every request has its own state, so does the cache. So its not a persistent cache, but rather individually for each request. Usually when the site is rendered, some pages are requested multiple times, because they appear in the header and footer menu for example. That's when they're stored in the cache, but still on a request base. That's particular the reason why the attack vector with an admin account wouldn't work. Sure there are some plugins like you showed, that would allow persistent caching, but that's not the default. Since the get_page_by_path() function is called very early in the routing, before any rendering happens, I wouldn't expect too many pages loaded into the cache. Nonetheless, I didn't see the obvious mistake here, that the cache simply returns the page structure!!! The authorization check is done somewhere else. I focused too much on the other "problem", too!
Great one, i see so many people not wanna figuring out how real debugging works. i have once a coworker that was surprised that PHP even can do this. He worked for years only with debug log statement...
We have two developers in our company who used to mostly code in PHP. However, we are currently heavily focused on client-side TypeScript development. The concept of breakpoint debugging is completely alien to both of them (of course it's a small sample size and may only apply to those two individuals). I can easily identify their code because it is consistently littered with console.log statements throughout. Despite my efforts to demonstrate how to use the debugger, they remain resistant to the idea. Don't get me wrong; sometimes a bit of printf debugging can be useful. However, when things become more complex, utilizing a debugger becomes incredibly valuable.
Being able to know the state of a program at runtime is so valuable. In IDEs that allow you to hover over a variable in code and reveal its state is especially good. The only time I use print is when I don't know how to use the debugger for a given development environment. I think any developer should be on board given their is a debugging specialist to help get them setup for the project if they don't know themselves. Debuggers are a no brainer.
This is very valuable I think, most blogs and resources online always tell of success, and how it was achieved. But the thousands of failures are omitted. I once did something similar in a blueteam context where I would do a full writeup even if it was just a "boring" false positive, because it's super important to understand that most things are failures, not wins.
I liked the video a lot, and setting up a debuggable WordPress installation isn't easy DevContainers are amazing, and in WordPress Code you should always scrutinize every line for security. It works and is widely deployed. Especially within plugins the security know-how and defenses can be pretty weak at times
I really liked this and appreciate the genuine and candid approach in presenting both the knowledge gained and the failures accompanying them along the way. This is eye opening to me.
Great Video, showing that not always everything goes to plan. Usually the internet is a glorified place where no mistakes are shown so this is a welcome change!
Sounds like you figured out the PHP dev environment but if you ever need to do it again there is a docker compose orchestration project called Warden that works with WordPress, Laravel, Magento, Symphony, and probably any PHP framework that does a lot of this leg work for you. I use it in my day job. It's really powerful
I commend you, @LiveOverflow, for doing some stuff on cache poisoning - I have a feeling we as a discipline have not explored it enough. I've found exploring it very tricky indeed; yet tremendously important, especially as I encounter people repeatedly who think "public data, so no security needed, right?".
Its nice to see the failures sometimes. Secrurity is not all glory, but youtube make it seem that way sometimes. Failures is great content and it makes you look like the rest of us. Keep it up, LO!
And in a few weeks you forget almost everything you thought you learned and a year later when you have to do it again, you then realize that you repeat almost the entire 'learning' process, especially when many of the things have changed so much. Yay VR!
Great video. I loved hearing about your thought process. Also, it turns out you actually made a great video for anyone who is interested in getting setup for WP debugging and further vuln hunting. Love it.
Whether or not it validates the access controls after retrieving the cached page, a cache implementation as you describe here could still be vulnerable to attack. The cache validation needs to confirm that the page loaded from the cache has the original page location requested. If it is just assuming this is the case because the hash of the location matched it's vulnerable to a cache poisoning attack. For example, Imagine you know there is a page at /internal/server-management that contains instructions about the commands to run for updating some sensitive systems. You don't have access to this page but you do have a general idea about what it looks like and access to create new pages on the same Wordpress installation. The attack scenario in this case is to poison the cache with a new page with identical md5sum and misleading instructions that will be loaded when the restricted page is requested. So long as your misleading page is kept hot in the cache, an admin loading the /internal/server-management page will see your fake instructions on how to update systems rather than the real ones. I haven't spent any time digging through the relevant WordPress code to know exactly how cache validation is done here, but within the general domain of "cache validation vulnerabilities" cache poisoning is one of the most common types.
WordPress' core is well audited and is constantly updated. A better path (and where most of the hacking happens) is in plugins and themes. There are plenty of plugins that are written by beginners or have less rigorous development practices. They're also the main culprit for WP's bad reputation back in the day when it comes to security.
Amazing approach, grit and patience. Thanks for sharing this. I think maybe you had so much technical acumen and great way of articulation of technical concepts because of those failures :D :D
First off, I'm glad someone shares the pain of Docker permissions! Second, what if we tried the opposite approach? Since the returned page can be private, what would happen if you could trick the admin into creating a private page that collides with, say, home, or store, or something else important that should be publicly accessible?
I had another idea when watching this video, where you could DOS the WordPress server by polluting the cache with 404 pages. You have to be lucky that you are the first person accessing the pages, but if we manage to make the server load 404 pages instead of the actual pages it is still a big win
One idea I got was "does the cache store 404s? Urls that does not lead to existing pages." If you could find a md5 collision for some of the most popular pages on a site as well as detecting or forcing a clearing of the cache you could immediately after the cache is cleared insert bad cache entries to make existing pages return a 404. The cache lookup code shown included a last changed timestamp, is it updated if you post a comment on a blog post for example?
Wordpress is a very popular CMS. I don't think one can consider it to be a framework, so the basic dev container is unlikely to have the tools required for development. Development on wordpress something that plugin developers (or code contributors) do and that's a more advanced use case. The basic use case is to set it up, get it to run, maybe install some existing plugins, and add some content and you wouldn't need to write any code to do any of that.
The attack I would research there would be different DOS attacks. First one would be simple stupid spam, if I can fill the page cache. Second would be to see how the cached pages are stored. If they are stored in a hash map, I would use the fact that they don't put a secret key in the cache lookup table to try to fill a single bucket to poison the cache for specific articles.
My first thought was if there was an unanticipated slug that would match a private page, what happens? Without having examined the code, perhaps a slug is not expected for a page in an unpublished state. Even with the code shown, it is not clear to me if this would be a concern or not. I don't think your thought was a bad one even if only the page object was returned. The page object needs to be evaluated for how it is authenticated and what it's state is from the cache. It's entirely possible the page object is different from the cache than from the database. Maybe whoever wrote the cache driver accidently included the authentication state with the page object. Unit testing may not have caught that sort of bug as the person writing the unit test would likely be the same developer who was not considering object state. As you pointed out in your video, the actual caching functionality seems to come from plugins. There would be an issue with Wordpress if it allows a plugin to solely determine what gets written to the cache without any internal checks. Many plugins have been maliciously updated by bad actors who gained access to the code publication for a particular plugin. Many sites get infected because they are set to automatically update. To me, you still have an avenue for investigation, unless you have examined the things I mentioned but just not shown it in your video. I think the key when looking through code whether looking for exploits or just to understand how it works, you should treat it like a tree. Start at the leaves and work backwards. If you see that something is called to work with the data, you are not at a leaf, so go to the leaf and examine it first.
> Wordpress is an extremely popular framework. There must be tutorials out there [..] As someone who had never done Wordpress before and now have to, I regret to inform you that the lack of information and documentation is not the worst part about it. We got XDebug to work, but it was not easy and required different PHP configs for different colleagues to make it work in Docker.
I'd have probably started by looking for problems with the use of the sanitization and escaping processing of the $parts and $escaped_parts, although this was probably the first thing the developers tested. I'd have also tried to access a private page before it was cached, just to see if the idea you had was feasible or not - easy to do on your own setup where you can guarantee it hasn't been cached yet. I tried similar on phpBB, but they seemed to have covered everything I could think up anyway. Maybe there is some way to deliberately overflow the cache?
Can't we insert malicious input in the slug itself to maybe poison the cache? It's going to be converted into a cache key stored in the database right? So whenever the cached key is retrieved from database the slug with our poisoned input would be then reverted to the user? Does this seem like a valid idea?
My thought was that may be you can poison the cache to return a 404 on a valid page. But that probably won't work either. In any case, the biggest lessons to be extracted from this are 1) Read the code first 2) PHP is hard to debug 3) Setting up an environment would've probably been easier without fancy containers
I’ve done some security research on wordpress in a completely different area. Depending on the configuration either arb file read or sqli indirectly leads to RCE.
Yeah I wish more people would be honest about this part of security research. Basically nothing will ever pan out. You just need to try a million stupid ideas until they trigger the one good one.
Is this not still potentially a security flaw? What if the access control code comes before this page loading code, and checks based on the path. If you have created a nefarious public URL and can get wordpress to check your access to that URL and say you DO have access, and THEN come to this code and hit the cache collision attack on the nefarious URL, then you would be able to access the private page. It depends on how the access control works, but it is possible that this cache attack would work depending on what the access control looked like.
brilliant video, but yeah as a software engineer, this is pretty much exactly the type of shit i would do - and have done before - think i found something really clever - debug docker issues, bad tools, and stale/lazy blogs - spend ages figuring out how a bespoke debugging tool works - realize the concept is flawed, and start from scratch
I get how all this work was not wasted, but in a commercial environment you could get that a bit more efficiently, right? If a company that either wrote or works with that code hires you to analyses it, they could have a programmer help you with the setup of the php debug environment or answer some questions about the code. is that a realistic thing thing you do? Not just a white box attack, but actually getting hints from the original programmers or maintainers?
yeah definitely that is an option, but it's always a balance. You don't want to bother them too much and if you offer professional services then it can be expected that you know what you do ;) so sometimes I rather work a few more hours unpaid overtime to figure out the setup myself, rather than ask their developers, so I look more professional :P But of course, sometimes a setup is very complex and then it might make sense to just ask them.
WordPress is super popular because it has lots of plugins and is easy to install, and has a large marketing budget. That's it. It's not good, it's not secure, and the code is terrible. Don't mistake "Popular" with "Popular with developers", because they're completely different.
Could you use the caching attack to do fingerprinting? I can detect when an admin from a WordPress site loaded my phishing website by observing a reduced access time to some slug, because it is now cached. Only then will I display my phishing form, otherwise redirect to some benign site
honestly bro just by watching these videos and looking at your skill level makes wanna quit this career and move to a jungle or something for the rest of my life.
I feel like there is still a variation to this that could still be useful. Could this not be used as a DOS attack or perhaps the ability to replace a page with your own malicious one? If you can get a hash collision for some reputable page with a public malicious page, and get that into the cache, WordPress would serve up your malicious page instead of the real one. And since you've made your page public, they won't have any auth problems into the page first. Or if you can make a hash collision that returns a 404 error like described in the video, you could at least take down some website you didn't like. The problem would still be how to get your page into the cache if you're trying to replace some popular website, as the real website would likely be cached already... But you might be able to squat on pages that have highly variable traffic if that traffic can get low enough that the page falls out of a cache.
well for me who's new in this field, how do I start my research to find or "hunt" CVEs? what's the best approach like determine ur target or any references related when starting get ur cve *sorry for bad English
I never knew xdebug is a thing Pretty cool. I just take it for granted that I can't put breakpoints in PHP ever since I started tinkering with it 5 years ago
Wanted to leave a quote I heard from somewhere a long time ago: "The master has failed more times than the apprentice has tried."
Great content as always!
As a developer I find it hard not to believe that multiple people have been lazy and missed something
i think that idea is appealing, but in reality Wordpress is such a massive project, there are so many other eyes on it, with much more experience with WP internals. i think the low-hanging fruit (xss, SQL injection, hash collision, etc.) have mostly been tackled.
@@ReadThisOnly in core WP, yes. Now, plugins are a different story...
Everyone: "I don't want to waste my time on that, so many has already checked it".
@@ReadThisOnly m
@@ReadThisOnly yes but it also depend on php versions php.ini settinga etc how long was openssl around when they found that bug just saying
Even if the hash collision isnt feasible, it's still good practice to also store the original key in the cache so that you can check for collisions. Pretty much all standard hashmap data structures do this.
Not for passwords
@@schwingedeshaehers Obviously not for passwords, the context here is caches / maps / key-value DBs where the keys aren't secrets.
@@schwingedeshaehers I'd hope no one is still using MD5 for passwords although I know that's not true
@@schwingedeshaehers Passwords don't need to be unique i.e. two users can have same password and you can get away with duplication. On other hand hash for identification needs to be unique. There's a difference between usecases.
2:10 - I thought exactly what you did. I saw the code and thought "Oh, definitely SQL injection" and my next thought immediately after that was "This is Wordpress. If there was a SQL injection flaw here I bet it would have been exploited (and fixed) ages ago" lol. A lot of people would be amazed at how many obvious flaws lurk around in popular open source and closed source applications 😅
i wasn't sure what you were trying to accomplish analyzing that function given that it's clear the access control wasn't being done in it. glad to see i wasn't wrong in the end haha
I love this video, simply because I thought "okay cool, you can get the site through a md5 collision, but this does not necessarily mean that you have permission to look at it", and then I watched till the end and you found it out yourself. This just took off some of my impostor syndrome thoughts xD
2:58 Along with the SQL injection and MD5 hashing, I'm also pretty concerned about the URL encoding/decoding with $page_path, especially where the space and forward slashes are replaced using str_replace. Also, those rawurlencode and urldecode functions do not look like a pair. Just generally getting a lot of Log4J vibes from those three lines.
Seconded. When I paused the video, this particularly stuck out to me.
While it didn’t matter in this case, a Chosen Prefix MD5 collision is also really powerful! It requires you to create your own collision, but that only takes a few hours. With that you can make two completely different starting blocks, and turn into the same hash again by adding special collision blocks at the end. With that the difference in the two hashes can be as big as you want, and you are not limited to the 2 bytes or so that are different in the collision that was shown
Awesome video as always. It’s important to try every idea you have, no matter how weird it might sound at first, until you have no ideas left and have completely convinced yourself that everything is safe
Love the part where you want to debug, but spend hours on setting up the entire thing 😂
I feel you.
Btw love videos like these, where you highlight the fails as well ❤
As a PHP dev for almost 15 years now, it warms my heart that you're getting as frustrating as I do working with Wordpress...
More of this. People nowadays tend to have really unreasonable expectations, they think everything is sunshine and flowers, but often times it's not. It's about recognizing that without failure contrasting success, succeeding would be worthless. It's about pulling through failure and learning from it to hopefully do a better job next time.
I’m so happy I’m not a Wordpress dev anymore. Your installation woes brought me back.
I like this kind of failure videos, it show us the whole processes of what a successful research need.
I really love the format of the video! Highlighting the research journey including every dead-end makes the whole process a lot more tangible than simply showing the polished end result in the rare case of success. Thanks a lot :)
Useless video u said? NO this video is very useful. We can know how security researchers work. How do they do try and error to get interesting findings. Keep doing things like this. i love it!
I actually caught that from the beginning of the video. I was like "Even if he requests a private page there must be privacy checks". I have made and maintain 3 wordpress sites and I can tell you that the best way to find an exploit is to look for it at the plugins. Wordpress sites get hacked very often just because of vulnerabilities in the plugins.
This video made very important point!
Whether the research is on computer security, math, physics, biology or really any field of science, you need to be very resilient against frustration! And the attitude towards failing is extremely important part of being resilient. There is no human intelligence that could save you from failing. Of course intelligence will help along with critical thinking skills, but failing will never stop, no matter how successful you will be.
That twist at the end really got me! I'm a WordPress developer and know a bit more about the internals. What got me confused from the beginning was your line of thought with the cache. Since HTTP is stateless and every request has its own state, so does the cache. So its not a persistent cache, but rather individually for each request. Usually when the site is rendered, some pages are requested multiple times, because they appear in the header and footer menu for example. That's when they're stored in the cache, but still on a request base. That's particular the reason why the attack vector with an admin account wouldn't work. Sure there are some plugins like you showed, that would allow persistent caching, but that's not the default.
Since the get_page_by_path() function is called very early in the routing, before any rendering happens, I wouldn't expect too many pages loaded into the cache.
Nonetheless, I didn't see the obvious mistake here, that the cache simply returns the page structure!!! The authorization check is done somewhere else.
I focused too much on the other "problem", too!
but cache only stores generated output i dont see any security errors with that ie its just text
I absolutely love this video format. So many rabbit holes!
I’d love to hear your thoughts on overcoming that “fear of failure.”
My first thought: what goes into the cache and can I get anything out of the cache that I shouldn’t have access to
This is how about every one of my research projects go, and seeing that it is a normal thing for you too is very encouraging. Thank you for sharing!
Do you plan on talking about fractureiser? I think it is an interesting topic about security, reverse engineering, and malware analysis
I forward this, fractureiser has taken the minecraft modding world by storm and I think a video about it would be really interesting
+1
+ 1
He needs to bring back the mc hacked series for just 1 episode
Great one, i see so many people not wanna figuring out how real debugging works.
i have once a coworker that was surprised that PHP even can do this. He worked for years only with debug log statement...
We have two developers in our company who used to mostly code in PHP. However, we are currently heavily focused on client-side TypeScript development. The concept of breakpoint debugging is completely alien to both of them (of course it's a small sample size and may only apply to those two individuals). I can easily identify their code because it is consistently littered with console.log statements throughout. Despite my efforts to demonstrate how to use the debugger, they remain resistant to the idea. Don't get me wrong; sometimes a bit of printf debugging can be useful. However, when things become more complex, utilizing a debugger becomes incredibly valuable.
Being able to know the state of a program at runtime is so valuable. In IDEs that allow you to hover over a variable in code and reveal its state is especially good.
The only time I use print is when I don't know how to use the debugger for a given development environment. I think any developer should be on board given their is a debugging specialist to help get them setup for the project if they don't know themselves. Debuggers are a no brainer.
Nah you're wrong
I do wanna say you're correct in the case of TS. PHP is just different
This is very valuable I think, most blogs and resources online always tell of success, and how it was achieved. But the thousands of failures are omitted. I once did something similar in a blueteam context where I would do a full writeup even if it was just a "boring" false positive, because it's super important to understand that most things are failures, not wins.
I liked the video a lot, and setting up a debuggable WordPress installation isn't easy
DevContainers are amazing, and in WordPress Code you should always scrutinize every line for security. It works and is widely deployed. Especially within plugins the security know-how and defenses can be pretty weak at times
Re: the end: definitely not a useless video! the MD5 explanation really helped make it click for me
Thanks for showing your "failures", so we can all learn from them!
I really liked this and appreciate the genuine and candid approach in presenting both the knowledge gained and the failures accompanying them along the way. This is eye opening to me.
Great Video, showing that not always everything goes to plan. Usually the internet is a glorified place where no mistakes are shown so this is a welcome change!
This is a great format! It was a bit like a detective show.
Sounds like you figured out the PHP dev environment but if you ever need to do it again there is a docker compose orchestration project called Warden that works with WordPress, Laravel, Magento, Symphony, and probably any PHP framework that does a lot of this leg work for you. I use it in my day job. It's really powerful
Thank you squarespace for sponsoring this video
I commend you, @LiveOverflow, for doing some stuff on cache poisoning - I have a feeling we as a discipline have not explored it enough. I've found exploring it very tricky indeed; yet tremendously important, especially as I encounter people repeatedly who think "public data, so no security needed, right?".
Your dev container experience is literally the same reason why I tend to avoid working with any PHP
that has nothing to do with php but ok
Its nice to see the failures sometimes. Secrurity is not all glory, but youtube make it seem that way sometimes. Failures is great content and it makes you look like the rest of us. Keep it up, LO!
And in a few weeks you forget almost everything you thought you learned and a year later when you have to do it again, you then realize that you repeat almost the entire 'learning' process, especially when many of the things have changed so much. Yay VR!
But I documented it in a video, so I can easily do it again ;)
True, nobody gets better without failing.
16:36 great perspective on attempting it regardless!
Great video. I loved hearing about your thought process.
Also, it turns out you actually made a great video for anyone who is interested in getting setup for WP debugging and further vuln hunting. Love it.
Whether or not it validates the access controls after retrieving the cached page, a cache implementation as you describe here could still be vulnerable to attack. The cache validation needs to confirm that the page loaded from the cache has the original page location requested. If it is just assuming this is the case because the hash of the location matched it's vulnerable to a cache poisoning attack.
For example, Imagine you know there is a page at /internal/server-management that contains instructions about the commands to run for updating some sensitive systems. You don't have access to this page but you do have a general idea about what it looks like and access to create new pages on the same Wordpress installation. The attack scenario in this case is to poison the cache with a new page with identical md5sum and misleading instructions that will be loaded when the restricted page is requested. So long as your misleading page is kept hot in the cache, an admin loading the /internal/server-management page will see your fake instructions on how to update systems rather than the real ones.
I haven't spent any time digging through the relevant WordPress code to know exactly how cache validation is done here, but within the general domain of "cache validation vulnerabilities" cache poisoning is one of the most common types.
I defs like seeing the failed attempts almost as much as the successful ones!
Videos like that are very motivating. Please keep doing o/
WordPress' core is well audited and is constantly updated. A better path (and where most of the hacking happens) is in plugins and themes.
There are plenty of plugins that are written by beginners or have less rigorous development practices. They're also the main culprit for WP's bad reputation back in the day when it comes to security.
"in these cases, the eyeballs weren't looking"
this is a fallacy, if this was the case we would never find vulnerabilities/panics in the linux kernel
Amazing approach, grit and patience. Thanks for sharing this. I think maybe you had so much technical acumen and great way of articulation of technical concepts because of those failures :D :D
Dude, you makes me want to write a scientific paper again
I hope i can have your mindset one day, thank you mate.
Absolutely valuable video even with no zero day.
First off, I'm glad someone shares the pain of Docker permissions!
Second, what if we tried the opposite approach? Since the returned page can be private, what would happen if you could trick the admin into creating a private page that collides with, say, home, or store, or something else important that should be publicly accessible?
Please keep bringing new content like this! Loved it and learned something new today!
I had another idea when watching this video, where you could DOS the WordPress server by polluting the cache with 404 pages. You have to be lucky that you are the first person accessing the pages, but if we manage to make the server load 404 pages instead of the actual pages it is still a big win
One idea I got was "does the cache store 404s? Urls that does not lead to existing pages." If you could find a md5 collision for some of the most popular pages on a site as well as detecting or forcing a clearing of the cache you could immediately after the cache is cleared insert bad cache entries to make existing pages return a 404. The cache lookup code shown included a last changed timestamp, is it updated if you post a comment on a blog post for example?
For the whole video I thought you were hand-writing all of those hashes until the very end of the video where you promoted your handwritten font :D
just here to say, I love your content
Wordpress is a very popular CMS. I don't think one can consider it to be a framework, so the basic dev container is unlikely to have the tools required for development. Development on wordpress something that plugin developers (or code contributors) do and that's a more advanced use case. The basic use case is to set it up, get it to run, maybe install some existing plugins, and add some content and you wouldn't need to write any code to do any of that.
The attack I would research there would be different DOS attacks. First one would be simple stupid spam, if I can fill the page cache. Second would be to see how the cached pages are stored. If they are stored in a hash map, I would use the fact that they don't put a secret key in the cache lookup table to try to fill a single bucket to poison the cache for specific articles.
The Artist of Failling
My first thought was if there was an unanticipated slug that would match a private page, what happens? Without having examined the code, perhaps a slug is not expected for a page in an unpublished state. Even with the code shown, it is not clear to me if this would be a concern or not.
I don't think your thought was a bad one even if only the page object was returned. The page object needs to be evaluated for how it is authenticated and what it's state is from the cache. It's entirely possible the page object is different from the cache than from the database. Maybe whoever wrote the cache driver accidently included the authentication state with the page object. Unit testing may not have caught that sort of bug as the person writing the unit test would likely be the same developer who was not considering object state.
As you pointed out in your video, the actual caching functionality seems to come from plugins. There would be an issue with Wordpress if it allows a plugin to solely determine what gets written to the cache without any internal checks. Many plugins have been maliciously updated by bad actors who gained access to the code publication for a particular plugin. Many sites get infected because they are set to automatically update. To me, you still have an avenue for investigation, unless you have examined the things I mentioned but just not shown it in your video.
I think the key when looking through code whether looking for exploits or just to understand how it works, you should treat it like a tree. Start at the leaves and work backwards. If you see that something is called to work with the data, you are not at a leaf, so go to the leaf and examine it first.
> Wordpress is an extremely popular framework. There must be tutorials out there [..]
As someone who had never done Wordpress before and now have to, I regret to inform you that the lack of information and documentation is not the worst part about it.
We got XDebug to work, but it was not easy and required different PHP configs for different colleagues to make it work in Docker.
I'd have probably started by looking for problems with the use of the sanitization and escaping processing of the $parts and $escaped_parts, although this was probably the first thing the developers tested. I'd have also tried to access a private page before it was cached, just to see if the idea you had was feasible or not - easy to do on your own setup where you can guarantee it hasn't been cached yet. I tried similar on phpBB, but they seemed to have covered everything I could think up anyway. Maybe there is some way to deliberately overflow the cache?
This is awesome, I didnt know we could debug wordpress with xdebug. Thank you!!
Can't we insert malicious input in the slug itself to maybe poison the cache? It's going to be converted into a cache key stored in the database right? So whenever the cached key is retrieved from database the slug with our poisoned input would be then reverted to the user?
Does this seem like a valid idea?
My thought was that may be you can poison the cache to return a 404 on a valid page. But that probably won't work either.
In any case, the biggest lessons to be extracted from this are 1) Read the code first 2) PHP is hard to debug 3) Setting up an environment would've probably been easier without fancy containers
Why do they hash the cache keys to begin with? Any decent cache engine does that internally (and is supposed to deal with collisions)
Great video! Learning to fail and how is so important!
I’ve done some security research on wordpress in a completely different area. Depending on the configuration either arb file read or sqli indirectly leads to RCE.
Yeah I wish more people would be honest about this part of security research. Basically nothing will ever pan out. You just need to try a million stupid ideas until they trigger the one good one.
Is this not still potentially a security flaw? What if the access control code comes before this page loading code, and checks based on the path. If you have created a nefarious public URL and can get wordpress to check your access to that URL and say you DO have access, and THEN come to this code and hit the cache collision attack on the nefarious URL, then you would be able to access the private page. It depends on how the access control works, but it is possible that this cache attack would work depending on what the access control looked like.
Nobody will care unless you can prove a case.
Love it! Even if we didn't get a shell!
I highly recommend DDEV for your next PHP adventure. =)
brilliant video, but yeah as a software engineer, this is pretty much exactly the type of shit i would do - and have done before
- think i found something really clever
- debug docker issues, bad tools, and stale/lazy blogs
- spend ages figuring out how a bespoke debugging tool works
- realize the concept is flawed, and start from scratch
As a WordPress developer you had me for a minute there because I was wondering how will you bypass the `wp_get_current_user()` function checks.
My thought when you brought up MD5 being used to access stuff is manufacturing hash collisions to steal data.
Really it's great video, because I think sometimes setup the debug environment is the important step to find bugs ,, thanks for this video 😊
You learned why us devs setup our dev environment once and then never do it again.
I get how all this work was not wasted, but in a commercial environment you could get that a bit more efficiently, right?
If a company that either wrote or works with that code hires you to analyses it, they could have a programmer help you with the setup of the php debug environment or answer some questions about the code.
is that a realistic thing thing you do? Not just a white box attack, but actually getting hints from the original programmers or maintainers?
yeah definitely that is an option, but it's always a balance. You don't want to bother them too much and if you offer professional services then it can be expected that you know what you do ;) so sometimes I rather work a few more hours unpaid overtime to figure out the setup myself, rather than ask their developers, so I look more professional :P
But of course, sometimes a setup is very complex and then it might make sense to just ask them.
Every failure is a step toward success or a learning experience. That's why I'm not afraid to fail.
"do you have an idea what to research"
idk, maybe the md5 collision you talked about in the intro ;p
Can’t you have a tag in the cache that makes it restricted to a particular user? I figured the potential issue in the very beginning.
WordPress is super popular because it has lots of plugins and is easy to install, and has a large marketing budget.
That's it.
It's not good, it's not secure, and the code is terrible.
Don't mistake "Popular" with "Popular with developers", because they're completely different.
Could you use the caching attack to do fingerprinting? I can detect when an admin from a WordPress site loaded my phishing website by observing a reduced access time to some slug, because it is now cached. Only then will I display my phishing form, otherwise redirect to some benign site
Yeah i also learned new thing php debugging... Never used it.. now i can use
Oh shit, here I thought I was the only one who get days like this.
honestly bro just by watching these videos and looking at your skill level makes wanna quit this career and move to a jungle or something for the rest of my life.
Tipp, if you evr have to setup a quick dev enviroment for php applications. ddev is pretty nice, and mounts everything as rw. (and it has xdebug)
Hey, thanks for the PHP xdebug setup in dev container tutorial at least 😂
But does the function gets the page by the path?
Is it a polar co. crewneck?
hahahaah i knew the moment you mentioned debugging in php that you're gonna go for a ride. It's cumbersome, however it's neat that it exists.
Hey! How do I signup for hextree? When will it be available? Thanks
WP gives PHP a bad rep :(
I feel like there is still a variation to this that could still be useful.
Could this not be used as a DOS attack or perhaps the ability to replace a page with your own malicious one?
If you can get a hash collision for some reputable page with a public malicious page, and get that into the cache, WordPress would serve up your malicious page instead of the real one. And since you've made your page public, they won't have any auth problems into the page first.
Or if you can make a hash collision that returns a 404 error like described in the video, you could at least take down some website you didn't like.
The problem would still be how to get your page into the cache if you're trying to replace some popular website, as the real website would likely be cached already... But you might be able to squat on pages that have highly variable traffic if that traffic can get low enough that the page falls out of a cache.
well for me who's new in this field, how do I start my research to find or "hunt" CVEs? what's the best approach like determine ur target or any references related when starting get ur cve
*sorry for bad English
There was absolutely no reason to apologize for ur English
@@suponkhan7443 thanks for the advice!
Great video, thanks vor sharing your experience.
My first thought was forcing an MD5 collision too, but I got hung up on the target key problem.
17:34 Does anyone still use *Comic Sans Font?*
I never knew xdebug is a thing
Pretty cool.
I just take it for granted that I can't put breakpoints in PHP ever since I started tinkering with it 5 years ago
The global import of $wpbd, maybe can be over-ridden??
I agree, and appreciate you bro ❤🙏🏻 love form India
Nice to see xdebug in vs code :)