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.
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.
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!
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 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 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
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 ❤
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 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.
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.
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
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 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 :)
No offense but you kinda did like way too much here dude. Setting up a php dev environment doesn't have to be that hard. Its pretty easy to install a lamp stack and installing wordpress is as simple as downloading a tarball and unzipping it. The idea that'd you'd use docker and vs code for this is just high-sillyness. And while xdebug for php is fine (I guess it gives you breakpoints, which aren't really a thing for server-side languages) but again overkill. 99% of php problems can be debugged with: ini_set('display_errors','1'); ini_set('display_startup_errors','1'); error_reporting (E_ALL); Look I mean I guess to each their own and if those are your tools you want to use whatever. Knock yourself out. But I just want to be clear it doesn't have to be that hard and there are better ways. I think you're probably just suffering from bad surface level advice on stack overflow and php forums.
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.
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.
@@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 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?".
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 don't prefer to use vscode xdebug extension, I would rather use xdebug client in phpstorm, since it's much more polished and less buggy overall. also xdebug has a xdebug profile snapshot analyzer tool built into It
You could’ve enabled Xdebug with “Local WP” Mac App extension On Mac In just 3 clicks.
ปีที่แล้ว
rly cool stuff just one thing brother you already have a round face. don't make your neck beard round. do a "square". straight line on the bottom 2 fingers width bellow adams apple. and then straight lines up at the back.
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.
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!
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?
11:11 Lolz that is a good way to get yourself hacked. Never make wp files world writable. Obv this is a dev setup for research purposes. But that is a good way to get yourself uber pwned in prod, especially if you're running in a shared hosting environment. Wordpress recommends 755 for dirs and 644 for files, wp-login.php should ALWAYS be 600. If your files are world writable and I have my arbitrary php code running on the same web server (very common for shared hosting environments) then I can just write whatever I want (webshells, ransomware, miners) into your files and tada, you're pwned!
> 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.
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
That's a good one, hadn't ocurred to me to look for md5 collision vulns in software. Those replacement of %2F to / etc look sketchy too, although coming form that rawurlencode(urldecode()) maybe it's safe.
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'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?
You're security researching but have problems with container setup, that's odd and shows you lack prior experience in dealing eith containrrs and how much you need to know about infrastructure before securing your application. Nonthless standard setup would mount your wordpress content directory from host rather than being embeded in container itself which allows modifications on host side and would reflect it without compiling container or rebooting / building container. Getting shell access in container is usually a bug red flag that you're trying to modify things from inside rather than at control plane level where you have proper access. I've never used wp dev repo but looking at code Imit shows from compose file that it clearly mounts contents of working directory to your container which you can edit outside container without permission implications as those files will always be accessible to current user Speaking of xdebug the repo already points to php ikage maintained by wp community that has specific flag to turn it on or off by env variables. This is quite prime example of how security works, you not only need knowledge of php and wordpress but also of your environment. Most security implications comes from user errors that do not know their environments like this YT guy who is claiming to do research but fails at infra basics. This is what usually happens in wp community when someone with no sysadmin / infra knowledge tries to fix things while they are actually brekaing system that was more secure earlier. Reality hits hard once damage is done - and people learning gets half backed knowledge when they are supposed to get all or none.
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
As a professional php developer, i understand that the Wordpress codebase is ugly as hell. I cannot understand how someone would work with this piece of spaghetti code. Try some research with Symfony 😊
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.
No way that was a days work for you.... Took me 2 weeks flat to understand how docker, php, and xdebug could all link together to create a dev environment. : (
I found a vulnerability in Google chrome dealing with there payment saving and I did the same thing like in my head I said no way it’s Google someone would have thought of this. I even wrote up a draft report then just said nah I’m gonna look stupid 3weeks later a bounty was claimed using my exact method lol and even today I still think this way like it can’t be this easy can it but that’s just a flaw in myself
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.
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?
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.
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.
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!
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.
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
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
My first thought: what goes into the cache and can I get anything out of the cache that I shouldn’t have access to
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.
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!
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 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 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
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 ❤
WP gives PHP a bad rep :(
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 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.
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.
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
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 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 :)
No offense but you kinda did like way too much here dude. Setting up a php dev environment doesn't have to be that hard. Its pretty easy to install a lamp stack and installing wordpress is as simple as downloading a tarball and unzipping it. The idea that'd you'd use docker and vs code for this is just high-sillyness. And while xdebug for php is fine (I guess it gives you breakpoints, which aren't really a thing for server-side languages) but again overkill. 99% of php problems can be debugged with:
ini_set('display_errors','1');
ini_set('display_startup_errors','1');
error_reporting (E_ALL);
Look I mean I guess to each their own and if those are your tools you want to use whatever. Knock yourself out. But I just want to be clear it doesn't have to be that hard and there are better ways. I think you're probably just suffering from bad surface level advice on stack overflow and php forums.
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...
Videos like that are very motivating. Please keep doing o/
True, nobody gets better without failing.
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
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.
That moment you realize no one even uses debug in php
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
My thought when you brought up MD5 being used to access stuff is manufacturing hash collisions to steal data.
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.
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)
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?".
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?
It's funny that you assume wordpress developers use xdebug to debug the code .
First lol
I don't prefer to use vscode xdebug extension, I would rather use xdebug client in phpstorm, since it's much more polished and less buggy overall.
also xdebug has a xdebug profile snapshot analyzer tool built into It
You could’ve enabled Xdebug with “Local WP” Mac App extension On Mac
In just 3 clicks.
rly cool stuff
just one thing brother
you already have a round face. don't make your neck beard round. do a "square". straight line on the bottom 2 fingers width bellow adams apple. and then straight lines up at the back.
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.
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!
Do more WordPress videos. The software is great but we need more professionals to look into it and make content about it.
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?
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.
11:11 Lolz that is a good way to get yourself hacked. Never make wp files world writable. Obv this is a dev setup for research purposes. But that is a good way to get yourself uber pwned in prod, especially if you're running in a shared hosting environment. Wordpress recommends 755 for dirs and 644 for files, wp-login.php should ALWAYS be 600.
If your files are world writable and I have my arbitrary php code running on the same web server (very common for shared hosting environments) then I can just write whatever I want (webshells, ransomware, miners) into your files and tada, you're pwned!
I absolutely love this video format. So many rabbit holes!
I’d love to hear your thoughts on overcoming that “fear of failure.”
> 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.
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
That's a good one, hadn't ocurred to me to look for md5 collision vulns in software. Those replacement of %2F to / etc look sketchy too, although coming form that rawurlencode(urldecode()) maybe it's safe.
I’m so happy I’m not a Wordpress dev anymore. Your installation woes brought me back.
Yeah i also learned new thing php debugging... Never used it.. now i can use
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
But the MD5 problem in Wordpress is still a problem...
Since they hash their password that way (although via phpass).
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?
You're security researching but have problems with container setup, that's odd and shows you lack prior experience in dealing eith containrrs and how much you need to know about infrastructure before securing your application. Nonthless standard setup would mount your wordpress content directory from host rather than being embeded in container itself which allows modifications on host side and would reflect it without compiling container or rebooting / building container. Getting shell access in container is usually a bug red flag that you're trying to modify things from inside rather than at control plane level where you have proper access.
I've never used wp dev repo but looking at code Imit shows from compose file that it clearly mounts contents of working directory to your container which you can edit outside container without permission implications as those files will always be accessible to current user
Speaking of xdebug the repo already points to php ikage maintained by wp community that has specific flag to turn it on or off by env variables.
This is quite prime example of how security works, you not only need knowledge of php and wordpress but also of your environment.
Most security implications comes from user errors that do not know their environments like this YT guy who is claiming to do research but fails at infra basics. This is what usually happens in wp community when someone with no sysadmin / infra knowledge tries to fix things while they are actually brekaing system that was more secure earlier.
Reality hits hard once damage is done - and people learning gets half backed knowledge when they are supposed to get all or none.
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
As a professional php developer, i understand that the Wordpress codebase is ugly as hell. I cannot understand how someone would work with this piece of spaghetti code. Try some research with Symfony 😊
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.
No way that was a days work for you.... Took me 2 weeks flat to understand how docker, php, and xdebug could all link together to create a dev environment. : (
I like this kind of failure videos, it show us the whole processes of what a successful research need.
I found a vulnerability in Google chrome dealing with there payment saving and I did the same thing like in my head I said no way it’s Google someone would have thought of this. I even wrote up a draft report then just said nah I’m gonna look stupid 3weeks later a bounty was claimed using my exact method lol and even today I still think this way like it can’t be this easy can it but that’s just a flaw in myself
Thank you squarespace for sponsoring this video
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.
I think you probably meant "Try NOT to find a security vulnerability" as this is WordPress after all
Most WP devs don’t use a debugger, they just old school wp_die(var_dump()) all the way
Every failure is a step toward success or a learning experience. That's why I'm not afraid to fail.
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 highly recommend DDEV for your next PHP adventure. =)
18 minutes long video? isnt that a little slow for finding a critical vulnerability in Wordpress?
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!
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.
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.
Interesting that xdebug is still annoying to get working. Its been many years that I've looked at PHP dev
Hey! How do I signup for hextree? When will it be available? Thanks
Pls bring minecraft hacked for just one episode because of the fractureizer situation
After 15 years as php-developer, I still use echo for debuging, as xdebug sush a mess.
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 forcing an MD5 collision too, but I got hung up on the target key problem.
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
"do you have an idea what to research"
idk, maybe the md5 collision you talked about in the intro ;p
Hey, thanks for the PHP xdebug setup in dev container tutorial at least 😂
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 agree, and appreciate you bro ❤🙏🏻 love form India
The global import of $wpbd, maybe can be over-ridden??
MD5 is dead to me. I only use Blake2b on my projects.
Great video, thanks vor sharing your experience.
all developers how use xdebuger will not work on woredpress projects :D
WP and Bug is like soup and water. you cant have soup that has no water hahaha
I'm so glad I don't work on WordPress sites anymore...
Love it! Even if we didn't get a shell!
just install a couple of plugins and you'll find plenty of bugs
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 ;)
the messy frameworks are one of the reasons why i stopped working with php :D
I defs like seeing the failed attempts almost as much as the successful ones!
Absolutely valuable video even with no zero day.
17:34 Does anyone still use *Comic Sans Font?*
the md5 hash is broken
You learned why us devs setup our dev environment once and then never do it again.
Dude, you makes me want to write a scientific paper again
This is a great format! It was a bit like a detective show.
I had the same idea. But I missed the SQL Injection idea
I hope i can have your mindset one day, thank you mate.
3:01 what if hashes were identical or smth