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.
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.
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
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
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 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
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 ❤
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!
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!
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.
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
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.
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.
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.
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...
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
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.
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?".
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
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.
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!
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
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.
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.
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.
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.
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
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.
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.
> 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’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.
@@ReadThisOnly That 800 year old tool works more consistently than your latest fad webful framework. Even back in 5.5 php we still had XDebug. I can't say the same about node without castrating it several times over to get remote debugging to work, nor python, which as a long running process for what ever god damn reason works the same way in debugging sense as php does (read: connects to you). In php it makes sense: there is no php process to connect to. It dies the moment you finish processing the request. In python, which is a long running process it does not. Finally, try the new PHP instead of following 20 year old memes. And this is coming from a java developer that migrated to 17.
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?
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.
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
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?
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.
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.
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
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
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 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
I’m so happy I’m not a Wordpress dev anymore. Your installation woes brought me back.
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...
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 ❤
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 :)
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!
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 like this kind of failure videos, it show us the whole processes of what a successful research need.
My first thought: what goes into the cache and can I get anything out of the cache that I shouldn’t have access to
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 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.
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
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 absolutely love this video format. So many rabbit holes!
I’d love to hear your thoughts on overcoming that “fear of failure.”
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.
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
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.
Thanks for showing your "failures", so we can all learn from them!
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.
Thank you squarespace for sponsoring this video
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...
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!
Re: the end: definitely not a useless video! the MD5 explanation really helped make it click for me
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
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 a great format! It was a bit like a detective show.
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?".
16:36 great perspective on attempting it regardless!
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
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.
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!
True, nobody gets better without failing.
Absolutely valuable video even with no zero day.
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 ;)
I defs like seeing the failed attempts almost as much as the successful ones!
The Artist of Failling
Videos like that are very motivating. Please keep doing o/
I hope i can have your mindset one day, thank you mate.
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?
Dude, you makes me want to write a scientific paper again
just here to say, I love your content
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
Please keep bringing new content like this! Loved it and learned something new today!
Love it! Even if we didn't get a shell!
Oh shit, here I thought I was the only one who get days like this.
This is awesome, I didnt know we could debug wordpress with xdebug. Thank you!!
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.
Do more WordPress videos. The software is great but we need more professionals to look into it and make content about it.
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
Every failure is a step toward success or a learning experience. That's why I'm not afraid to fail.
WP gives PHP a bad rep :(
I highly recommend DDEV for your next PHP adventure. =)
"do you have an idea what to research"
idk, maybe the md5 collision you talked about in the intro ;p
Yeah i also learned new thing php debugging... Never used it.. now i can use
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.
"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
Great video! Learning to fail and how is so important!
I agree, and appreciate you bro ❤🙏🏻 love form India
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.
Great video, thanks vor sharing your experience.
Hey, thanks for the PHP xdebug setup in dev container tutorial at least 😂
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'd love to see you do a video at some point showing how you organize your notes when doing security research.
My thought when you brought up MD5 being used to access stuff is manufacturing hash collisions to steal data.
Nice to see xdebug in vs code :)
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.
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)
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
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.
Very good video, thank you.
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.
> 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.
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.
That was very interesting!
"Looks Messy LOL", relatable -_-
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.
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.
Your vscode should support adding breakpoints on lines rather than have you modify the code.
sadly php is 800 years old
@@ReadThisOnly Oh a php hater appeared. I guess you never tested the newest PHP-Version. A LOT has changed..
@@TheFailFalse not to mention that the age doesnt really matter since xdebug is doing that
@@ReadThisOnly That 800 year old tool works more consistently than your latest fad webful framework. Even back in 5.5 php we still had XDebug. I can't say the same about node without castrating it several times over to get remote debugging to work, nor python, which as a long running process for what ever god damn reason works the same way in debugging sense as php does (read: connects to you). In php it makes sense: there is no php process to connect to. It dies the moment you finish processing the request. In python, which is a long running process it does not.
Finally, try the new PHP instead of following 20 year old memes. And this is coming from a java developer that migrated to 17.
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?
My first thought was forcing an MD5 collision too, but I got hung up on the target key problem.
That moment you realize no one even uses debug in php
I like this Video a lot! Thx
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.
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
Enjoying journey video
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?
great video!
Why do they hash the cache keys to begin with? Any decent cache engine does that internally (and is supposed to deal with collisions)
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
Big surprise at the end 🙃