Alquicira: Opsec: this wordpress-plugins.html">https://blog.sucuri.net/2015/04/security-advisory-xss-vulnerability-affecting-multiple-wordpress-plugins.html
Stumfoll: ElectriX that’s just a one liner that’s easy to copy paste in SSH. There’s definitely lots of other ways to do it
Gausman: Or how about “php -info” from the terminal seeing as you’re logged in
Eder: Johndoe2: wordpress-plugins.html">https://blog.sucuri.net/2015/04/security-advisory-xss-vulnerability-affecting-multiple-wordpress-plugins.html this was the vuln I was thinking of for that plugin but apparently that plugin isn’t using query args so nevermind
Debois: Could not open input file: o
Gausman: ElectriX, which version of php is that?
Sakovitch: Php -info Could not open input file: o
Garito: Yeah -i works for me, -info didnt
Brininger: 5.4.43 over here, on a centos 6
Gausman: Ok, PHP Version = 5.6.13. Perhaps the argument has change, point remains :
Savaria: Php -info works on centos, php 5.6
Savaria: It’s a php thing, Kahahane to do with os/distro
Fredo: Wow that vuln affects a lot of highly used plugins
Grieve: ElectriX: the one i posted
Savaria: Bu***and: i thought you meant “recent” april 2015 is dinosaur times for wordpress ;
Carrecter: ElectriX: yea it was fixed pretty quickly once it was pin pointed in MOST
Hufana: Opsec: haha. the last 6-7 months is a blur to me
Savaria: As far as i know there were at least 2 separate xss vuln’s
Myhr: Opsec: there was a separate one after that was related to WP core and comments I think
Savaria: One affected not only wp but anything that used it, drupal, joomla, etc
Thackxton: ElectriX I remember looking for a file monitor plugin back in the day, but to answer your question I just use a malware scanner, and my own regexes.
Gausman: Johndoe2, inotifywatch
Buziak: Opsec: O-Day maybe ?
Hittson: Boom. and that’s how you do it : thanks dcr!
Gausman: Get to know when the *inode* changes
Gausman: Before the file is even written.you get to catch it ;-
Mccumbers: Opsec: https://blog.sucuri.net/2015/05/jetpack-and-twentyfifteen-vulnerable-to-dom-based-xss.html
Bright: Omg the fun I could have with this hehe :
Gausman: Its particularly useful at stopping plugins from using stupid creation masks
Gausman: Well.it doesn’t stop them from doing it, but you can use it to correct the permissions/ownership almost immediately
Savaria: Bu***and: i look at jetpack as one might look at “dog chocolates” in the park.
Schlender: Dcr that’s awesome. very useful
Stencel: Opsec: yea I don’t use jetpack 99% of the time.
Gausman: Make sure you do it in the right order though, stripping apache’s g+w permissions before the file has been completely written can lead to interesting effects, especially when that file is a directory
Savaria: I don’t use it 101% of the time ;
Morton: I have enabled it for one client site i think.or maybe it was my own site. for my dog
Witmer: Althoughtime to up the ante. the dog recently got a HUGE press push! hahaha.
Savaria: I picked 101% because, dalmations.
Penney: And Dalmatians are awesome
Savaria: Truth be told, it’s closer to 100%
Bahr: Meh i install jetpack upon request. and i do it after launch and take 0% responsibility
Burgio: Well. 101% if you actively got someone who isn’t you to not use it ;
Boadway: Bahr: i dont take requests
Bahr: I had a client using photon who would update his images directly instead of creating a new image— and all his cached images wouldn’t update
Gausman: For example, plugin creates a directory with 775 permissions happens alot, then writes files into that directory. If the ownership changes so that apache in this example loses g+w before writing files to that directory.the installation of the plugin fails