Tag: hacks

How Hackers Find You

I made a bold statement that pissed someone off. I told him that hackers don’t use Google to find vulnerable sites and attack them.

They don’t, you know. Sure, they can do that, and I’m certain some of them run scripts to collect a list of people to hit up, but that’s incredibly inefficient. The only kinds of people who do that, who get lists of websites to touch, are people who for good reasons need to do that. Like maybe running a script to ping all your domains and trigger a WordPress automatic update by kicking off cron. And sure, a hacker could use a tool like WPScan to collect all the awesome information. But they don’t.

But like I said, doing that is inefficient. The longer it takes a hacker to find you, attack you, and break you, the more likely it is that you’ll be upgraded. With WordPress in specific, the moment that hacker hits your site, your WP install has probably already begun the upgrade to make you more secure. Assuming that, what a hacker wants, what they need, is to hit you once, hit you right, and hit you hard.

What a hacker really does is use that annoying BotNet to distribute an attack on as many websites as possible in one blast.

Do All Hackers Do This?

I should clarify something. When I say ‘hackers’ I don’t mean a specific person who is out to get you, in particular, and wants to destroy your site. Those attacks take as much tech smarts as they do social engineering. When I talk about hackers who are taking down sites, I mean the ones who know about a plugin or theme or core exploit to your site and are going to en masse blast the hell out of the internet to take ’em all down or leave their backdoors for whatever they do with these sites. Perhaps I should call them script kiddies, since many are.

Why Do Hackers Do This?

I have no idea.

It used to be we hacked sites to prove we could. Then we hacked them to get in and get information we wanted. Then … somewhere along the line we started to hack to deface and leave viagra links. I don’t know what ‘good’ the hackers get out of the end result. It doesn’t make sense to me, but then again, I don’t understand why people buy most ‘as seen on TV’ things.

How Do Hackers Find Your Site?

One (kind of cool) thing they can do is, once they find one site, using a tool like SameIP to collect a list of everyone else on the server. That’s great for attacking people who are on shared hosts because they all have the same IP. And once they have your domain on their own list, they keep it and will hit you forever.

But what if they just want a list of all 23% of the internet running WordPress? It’s not that hard. BuiltWith, for example, has a list of many of the WordPress sites.

Certainly it’s not that hard to do. There used to be a site called Hacker Target that had a list of all WP sites: https://hackertarget.com/100k-top-wordpress-powered-sites/ The URL doesn’t work anymore but the idea is there. One could take such a list and just attack it.

Similarly, if you happen to be on an insecure server, one could hack the server and from there collect a list of all domains (since the server has to know it’s domains) and, in the case of a very insecure server, get all the domains on the network, and attack all of those. The shell commands aren’t all that terrible.

The point is, both of those methods are far, far, faster than just grabbing a google for ‘this plugin’ or even ‘this error.’

How Do Hackers Find Out What You’re Running?

This is where people step in and say “WordPress shouldn’t announce it’s version to the masses!” It should, because of what I say the next section (see “Do Hackers Care What You’re Running?”), but the short is that your site content tells them. They can run scrapers to pull your site data, the layout, the way files are stored, and they can tell. It’s like figuring out what car you’re driving.

In fact… Think about that for a second. What kind of car are you driving? Does having the car logo on the car make it more or less secure? It may, if there’s a specific ‘hack’ for your car, but the trained professionals will still know, even if you pull off the logos, so in the end, you’re not really protecting yourself.

Do Hackers Care What You’re Running?

No, they don’t. Sorry. They don’t. Once a hacker has a list of websites, they don’t care if you run WordPress or Drupal or Joomla or Ghost. They’re going to attack with what they know is vulnerable and keep at it until they have a success. Then they take that success and leverage it to get to the next site. And on and on.

So when you get hit by 100 bot-net computers, being tagged for timthumb when you don’t even have it installed, that’s what’s going on. They do not care what you’re running.

How can you protect yourself?

Use a good host who cares about security. Use up to date versions of all web tools and their extensions. Follow those tools and get updates regularly as to any security issues with them.

WordPress is not “Set it an forget it.” You have to keep paying attention.

3 June, 2015
Command Line Cleaning WP
I’m a huge fan of the scorched earth clean up for WordPress. By which I mean when I clean up WP, I rip it out, scrub it, and reinstall. This scares the heck out of people sometimes, and if you’re doing it in a GUI, yeah, it can be sucky and time consuming. Me? I do it in 5-10 minutes, depending on if my cat wants to be petted.

I’ve been asked ‘How do you do it that fast?’ so here are my steps for cleaning up WP, with the following assumptions:
1. I’m working in the folder where WP is installed
2. wp-config.php is in this folder
3. WP is in ‘root’ (i.e. I’m not giving WP it’s own folder)
If any of those aren’t true for you, adjust the folder locations in the commands:

Download WP: wget -P ../ http://wordpress.org/latest.zip

Unzip it: unzip -qq -d ../ ../latest.zip

Backup DB: wp db export

Pause. Here I’m using WP CLI, which makes my life way easier. If you’re not, you’ll need something like this: mysqldump --opt --user=username --password=password --host=yourMySQLHostname dbname > domain_com.sql

Zip up the files I want to backup: zip -r ../domain.zip *.sql wp-config.php .htaccess wp-content/

Set glob. Glob is scary, I know, but read about glob before you dismiss it (if you’re on korn, you can usually skip this): shopt -s extglob

Delete files: rm -rf !(wp-config.php|wp-content)

Pause. At this point, It’s probably wise to consider that my hack may be in my theme and/or plugin. If so, I want to nuke them and JUST keep my uploaded files, so I use this instead…

Delete files: rm -rf !(wp-config.php|wp-content) wp-content/!(uploads|blogs.dir)

Pause again. No matter what, want to scan for evil files, but this way I do it over a much smaller group of files. Either way, though, I do want to scan the folder for evil, because leaving behind hacks in themes and plugins is really common. Also it’s a good idea to delete every plugin you don’t use, and theme as well. Since you really can’t delete all themes but one on a Multisite, this gets harder. Generally I don’t delete the themes automatically, but instead go in and nuke them one at a time, so I run this…

Delete files: rm -rf !(wp-config.php|wp-content) wp-content/!(uploads|blogs.dir|themes|mu-plugins)

Now we can move on, knowing our personal files are clean.

Copy it back: cp -r ../wordpress/* .

Clean it up: rm -rf ../wordpress ../latest.zip

And now you’re done! When you want to reinstall plugins and themes, I do via wp-cli because it’s faster: wp plugin install NAME and wp theme install NAME

Then I activate as needed and I’m off to the races. If I deleted my mu-plugins, I copy those back from my backup zip, one at a time, checking each file for hacks.

The best thing about this is you can apply the logic to any CMS out there. Just know what you have to delete and keep. The downside? It doesn’t touch your database. Rarely is this an issue for me, except in the case of the Pharma hack. I’ve not had a DB infected yet.

Do you have a solid methodology for cleaning it up?
25 November, 2013
Recovering Your Cape
One of the odder “hacks” out there is one where the person, once they get in, de-frocks your Super Admin on a Multisite. This isn’t always a hack, sometimes it’s just a simple mistake.

To quote my friend Jen Mylo:
1. People give away admin rights like logo-encrusted keychains at a car show and then the new admins abuse the power.
2. Someone who has admin rights deservedly but doesn’t know code makes a mistake.
[…]

Some people make bad decisions about who to give admin roles.
There’s an extra level of problems with making everyone and their pet monkey a super-admin on Multisite. You may think it’s a great thing, because now someone else can add new users, install plugins, edit themes and plugins, and of course, use iframes and PHP and such in widgets.

We run a Multisite at work, and they let me ‘secure it up’ recently. The first thing I did was demote pretty much everyone except five of us to ‘Editor.’ I told them all that I’d done this, and if they found something they couldn’t do, tell me, and I’d fix it. At this point, I’ve changed only three people to Admin, and dropped even more to ‘Author.’ Why? Because they don’t need to have high levels of access to do what they need to do! The admins on the site can tweak theme settings, play with widgets, and add ‘existing users.’ Everyone else? They just write content. Heck, most of them don’t even need to be Editors, but we gave them that level so they could help us copy-edit other posts. Two people complained “I need Super Admin access!” and I gave them my best Enda: NO CAPES.

Limit your admins, and there is less of a chance someone will accidentally remove access from the wrong person.

So now that that’s out of the way, how do you get it back?

Normally, reinstating an admin account is pretty easy. You go in via mySQL, pop open the wp_usermeta table, find your ID, and toss this in for meta_value for wp_capabilities: a:1:{s:13:"administrator";b:1;} That won’t restore all the roles, if you happen to be using Role Scoper, or some other management tool, but if you’ve got that, you can do anything. If you’re using WP-CLI, wp user update 1 --role=administrator (assuming you’re user ID 1).

There’s a sidebar/caveat to this. Sometimes this doesn’t work, and it happens if you change your DB prefix. So normally you have the prefix wp_ and the table wp_options. In that table you have a option named wp_user_roles and everything works. But then you make a new site, and you pick a different DB prefix, maybe you heard it was more secure, or maybe you wanted both tables in the same DB. Either way, now you have wp_wdssrr_options instead, and when you copy over your old options content, no one can log in. It’s because you have to rename that option to wp_wdssrr_user_roles

I just had a site with this problem last week.

On the other hand, getting back Super Admin access is less straightforward, but by no means is it impossible.
1. Go into wp_sitemeta and look for site_admins.
2. In there you will see something like this: a:1:{i:0;s:7:"Ipstenu";}
3. If your userID is ‘superman’ then it would be a:1:{i:0;s:8:"superman";}
Capitalization and stringlength matter. Add one user, and use that to correctly restore power to the others.

Can you do this via WP-CLI? Yes, if you’re on the latest versions. Kind of. You can get a list of super admins via wp network-meta get 1 site_admins and in theory wp network-meta update 1 site_admins USERNAME would work except that the data is serialized. I opened a ticket with WP-CLI, and it’s a ‘plugin territory’ issue right now, so I’ll have to see if I can code it myself.
25 June, 2013
Scorched Earth Security
This post is dedicated to Matthew Freeman, who donated to help me get to WCSF. I have not forgotten coffee.

Napoleon’s invasion of Russia
There’s been a lot of kerfluffle about hacked systems again, especially that the ‘auto upgrade’ isn’t safe. I want to point out that your automatic upgrade of WP and its plugins is prefectly safe, if your system hasn’t been infected. Once you’ve been infected, however, it’s a whole different ball game. I subscribe to the salt-the-earth philosophy of cleanup, but more on that in a moment.

Odd as this may sound, I tend not to spend any time determining where the hack was. My feeling is that the longer a hack sits on my live server, the worse off I’ll be. If it starts to happen repeatedly, I may look into it more. But generally speaking, a hacked site boils down to some pretty obvious avenues of attack:
1. Insecure password on your server
2. Insecure behaviors
3. Bad plugins/themes/extensions
4. An insecure webserver
You notice that I’m leaving the apps themselves off the list? For the most part, a hugely explioted hack isn’t an app vulnerability. Most well used apps, like Drupal and WordPress, are remarkably well tested when it comes to that, and the developers are quite attentive. The weakest point in the security tripod is going to be the user. When I was exploited, you bet your ass it was 100% on my head, and no one else’s.

So when I see a web-app get hacked, my first thought is not ‘debug from whence it came’ but ‘get the file off the server — now.’ If you leave the hacked files on the server, the odds of your site going down again and again increases, so the very first thing I do is download everything. Every single file, the database, and everything that sits on that server. I back it all up on a computer, preferably one with a good security/virus scan tool, and then I get started on the real work. I’m going to come back to those files and review them, but that’s later. Right now I need to get what I have clean.

Make a list of everything on your server. Separate your ‘personal’ files from the application files. For example, in WordPress I would list my themes and plugins as the ‘application’ files, because I can easily download them from the repository. My ‘personal’ files would be the images in /wp-content/uploads and /wp-content/blogs.dir, the .htaccess file and my wp-config.php file.

Now here’s the scary bit. Every file gets deleted off the server. Yes. Every file. When it’s WordPress, I kill it all with fire except those personal files.

Then I download fresh copies from WordPress.org (and only WordPress.org) but I don’t copy them up. No, instead I change my server password, and my SQL password. If I’m having an extra neurotic day, I may make a new SQL id and use that instead. Regardless, it’s Password Changing Day. If I used that password anywhere else, it gets changed there too.

Still with my site down, I look over my .htaccess and config files with a fine toothed comb. I know what’s supposed to be there, and I know what’s not. I’ll also scan my personal files (all those image folders) for any .php or .htaccess files in there. See, nothing but files I uploaded are supposed to be in there, so if anything is, it’s bad.(If you use caching plugins, you may have other files in there, but you should already know that. Still, it’s best to turn off any caching you have while you rebuild. Change the cache constant in wp-config to off, and remove the cache folders from wp-content.) If I find anything, I delete it (though I will make a note of the time/date that file was updated, and since I have my backup, I can look at it in depth later). I’m also going to make sure permissions are right. I want things to be secure.

Finally I upload every new file back up from my fresh copies, and then make sure my site still works. It should.

It used to be that people told me I was silly for doing this. It was overkill, surely I could just change passwords and remove the infected file. Sure, that might work. The problem is these guys are getting smart. Denis uncovered a pretty cool (if evil) hack, where your updates are compromised, and basically from now on, you’re getting hacked code. With my method, you’d be ‘safe’ from that continuing.

Of course, you’re not safe from it happening again, as you could be hacked again, and this is where we have to start digging into logs and sorting out what the hack was and how it happened. And that is a different post all together.

If all of that is too much for you, and it can be, I recommend hiring Sucuri. For $90 a year, they’ll monitor your site for you. If that sounds like a lot, that’s $7.50 a month. You can spare the latte.
12 July, 2012
Phishing Games
One night, not so very long ago, I got a scam email that reminded me how few people actually pay attention to these things. It’s funny, but we’re all pretty lazy about these scams. You rarely get them from your real banks and money places anymore, or they’re very obviously not real, so you ignore them. Far more people fall for cold-calls on their cell, you know, like ‘This is Mary from Cardmember Services, calling about…’ And I always just hang up. But with so many emails, a lot of us blindly follow them. We click a link, we go to the site, and we don’t think.

This not thinking lead to a few WordPress developers being phished. This is not being ‘hacked’, this is a simple ‘You accidentally gave someone your password’ type mistake. While sites do the best they can to protect you from yourself, we can’t stop you from posting with your real name and not your handle (someone did this recently and asked me to remove the post, which I did), and we can’t stop you from not paying attention.

So we repeat this over and over again. Read the email, look at the site you end up on, use your brain.

Here was the email I got (one of three copies, from two separate email addresses):

Dear WordPress Plugin Developer,

Unfortunately, a plugin you are hosting has been temporarily removed from the WordPress repository. We’are going to manually review your plugin because it has been reported for violating our Terms of Service. If your plugin is not approved by this review then your plugin will be permanently removed from the WordPress repository.

You can check if your plugin has been approved or rejected at

http://wordpress.org/extend/plugins/my-plugins-status/

Four things were wrong with this.
1. The email did not come from plugins@wordpress.org – the only official email for plugin yanks.
2. The email didn’t come from someone I know on the pluginrepo ‘team.’
3. None of my friends who work for WP poked me directly (and I’m fairly sure Otto, Nacin or Mark would have).
4. The email source showed the wrong URL.
I quickly did a few checks on the email source, traced it back, verified it wasn’t WordPress, posted on the forums, and alerted the masses. Because ignorance is where this sort of thing festers. I’m a little impressed, though, since I’ve not seen a phishing attempt aimed at WordPress like this before.

Clearly it’s time to go over a quick reminder about what phishing is, it’s goals, and how it works.

Phishing is when you try to get someone else’s login credentials by mimicking a real site, so you can log in as them and do naughty things. It works by having people not pay attention to a URL when they go to a site. PayPal was an early hit on this, and they finally said “We will never send you an auto-login link or a link to our site in our emails. Just go to paypal.com and log in.” I don’t know if they still do it, but it was a very smart idea.

Too often we blindly trust our emails. The email appears to come from our bank? We click the link, log in, and … hey, it didn’t work? Banks are a huge target for this, and as I work for one, I’m very familiar with making sure we’re not phished. I mean, an email like this looks pretty safe right?

That link, if you’d clicked on it, would take you to a fake site. Now some of those fake sites are smart, and when you enter your ID and password, will redirect you to the real site’s bad password page! That would make you think you only typoed, which happens to all of us.

You may have noticed that most banks and money-type places have you enter your username and then take you to a page with a picture and a passphrase. As long as those are yours, you know you’re on the right site. That helps take care of a lot of attempts, but when you’re faced with something like a phishing attempt on WordPress, there’s less security because there’s less at stake. A bank can make it annoying and inconvenient to log in and get your money and you’ll put up with it because, well, it’s your money. You’ll put up with a lot to get to your money.

But if you have to jump through the same hoops to log in to a forum, or check in code to open source, you’d probably walk away. This is a complicated problem, trying to balance out the needs of the many and the protection of all. I’m not going to delve into possible answers, since they’re always going to be specific to your community.

Also, you can usually easily spot the fake emails. Here’s one I got today:

This came from “Delta Air Lines – support_8312@delta.com” which looks ‘legitish’, but as soon as you look at the email body, it seems weird. No real airline sends out your tickets in a ZIP file for one. Without looking any further, I know this is fake and I can delete it. But what if they’d sent a link? Would I have clicked on it? Again, no, since I’ve only been to Newark twice in my life, and I know I’m not going any time soon, but that’s not the point. The point is the email would have been less off if there’d been a link. If I’d really been concerned, I would have looked at the email headers, but before we jump into that, let’s review what you can do!

The rules to not be phished:
1. Look at the URL before you enter your password and ID.
2. Copy and paste those URLs, never click.
3. If the email looks ‘off,’ don’t click.
4. If there’s an attachment and there isn’t normally, delete the email.
That’s really the best you can do for most people. The rest of us, though, can go the extra level. When you get that weird email, the one that looks just a little off and hits your spider sense, view the email source, which looks like this:(This is the actual header from the phising email, by the way. You can see the whole thing here)
```
Return-path: 
Envelope-to: ipstenu@ipstenu.org
Delivery-date: Sat, 24 Mar 2012 18:14:57 -0500
Received: from blu0-omc4-s14.blu0.hotmail.com ([65.55.111.153]:4132)
	by gamera.ipstenu.org with esmtp (Exim 4.77)
	(envelope-from )
	id 1SBaAh-0001wn-Sk
	for ipstenu@ipstenu.org; Sat, 24 Mar 2012 18:14:56 -0500
Received: from BLU0-SMTP348 ([65.55.111.135]) by blu0-omc4-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);
	 Sat, 24 Mar 2012 16:14:54 -0700
```
By the way, notice how this came from Hotmail? 1990 called, it wants Nirvana back. WordPress emails don’t come from Hotmail, and I really hope that I’m not about to get a comment from someone at Automattic about how they still use it. Hotmail is like an AOL account. You’re not old school, you’re living in the icky past.

Now in that email, once you have the raw source, you scroll down to the body of the email and see this:
```
<HTML><HEAD>
<META name=GENERATOR content="MSHTML 8.00.7601.17744"></HEAD>
<BODY>
<P>Dear WordPress Plugin Developer,</P>
<P>Unfortunately, a plugin you are hosting has been temporarily removed from&amp;nbsp;the WordPress repository. We&amp;nbsp;are going to manually review your&amp;nbsp;plugin because it has been reported for violating our Terms of Service. If your plugin does not get approved then it will be permanently removed from the WordPress repository.</P>
<P>You can check if your plugin has been approved or rejected at</P>
<P><A href="http://wordpresss.comule.com/bb-login.php">http://wordpress.org/extend/plugins/my-plugins-status/</A> </P>
<P>&amp;nbsp;</P></BODY></HTML>
```
I don’t know about you, but something’s fishy in that email. comule.com has nothing to do with WordPress, we have a winner.

How do you see your raw source? For most email apps, select the message, go to the view menu and look for ‘message’ or ‘message source.’ If there are further options, like in mail.app, you want ‘Raw Source.’ Outlook has it under options, I believe. Once you get that view, just take the time to look at the ‘content’ of the email. If you’re extra paranoid, you can even turn off your email’s ability to automatically render HTML, so you’d see that right away (I actually no longer do that because of the values in HTML emails).

Now you know how to protect yourself just a little bit more. What are your best anti-phish-tips?
4 April, 2012
SOPA Blackout
I’m lazy and I don’t want to write a plugin, so I asked on Twitter if someone had one to black out a site for SOPA on the 18th of January. If you don’t get why this is a thing, please read WordPress.org’s post on SOPA. A lot of sites are going black from 8am to 8pm. I am, and I to didn’t want to use a plugin.

My solution for this involves two files and is all thanks to Pete!

@Ipstenu add a .maintenance file

— Pete Mall (@petemall) January 12, 2012

To do this is really simple. Go in and make a file called .maintenance in the top level of your WP install. For most people, it’s the same folder as your .htaccess and wp-config.php files.

Now edit that file and put in the following content:
```
<?php
 
// Let's make sure you're not an admin/logged in!
 
function is_user_logged_in() {
    $loggedin = false;
    foreach ( (array) $_COOKIE as $cookie => $value ) {
        if ( stristr($cookie, 'wordpress_logged_in_') )
            $loggedin = true;
    }
    return $loggedin;
}
 
if ( ! stristr($_SERVER['REQUEST_URI'], '/wp-admin') &amp;&amp; ! stristr($_SERVER['REQUEST_URI'], '/wp-login.php') &amp;&amp; ! is_user_logged_in() )
 
// If it's after 8:00:00 on the 18th, we're going to show the blackout page
 
if ( time() >= mktime(8,0,0,1,18,2012) ) {
	// When we hit 8pm (20), we're back.
	$upgrading = mktime(20,0,0,1,18,2012);
}
?>
```
What does this do? It’s pretty simple. First it checks to see if you’re logged in and, if so, lets you get where you need to go. If you’re not logged in, though, it checks the date and if it’s after 8am on the 18th, you get a maintenance page. After 8pm on the 18th, it swings back. (All this code, except for the date stuff which I wrote, is from Matt (Sivel):
WordPress Maintenance Mode Without a Plugin and WordPress Maintenance Mode Without a Plugin Part 3/ ) Pretty cool right? And the 8am to 8pm is based on your server’s time, so it’s all local. It’s also pretty easy to see how you change that for your own time. I would say pick your busiest time to go black.

But if you want it to look pretty, you need to do a little extra. (Code from WordPress Maintenance Mode Without a Plugin Part 2 and text from Blaccupy) Make a file called maintenance.php and put it in your wp-content folder. Here’s an example:
```
<?php
/* Tell search engines that the site is temporarily unavilable */
$protocol = $_SERVER&#91;"SERVER_PROTOCOL"&#93;;
if ( 'HTTP/1.1' != $protocol &amp;&amp; 'HTTP/1.0' != $protocol ) $protocol = 'HTTP/1.0';
header( "$protocol 503 Service Unavailable", true, 503 );
header( 'Content-Type: text/html; charset=utf-8' );
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
        <title>BLACKED OUT</title>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <style type="text/css">
        body {
                background: black;
                text-align:center;
                color: #eee;
                font-family: Helvetica;
                font-size: 2.2em;
                }
        </style>
</head>
<body>

<div style="width: 960px; margin: 0 auto;">
<h2>This website is..</h2>

<h1>BLACKED OUT!</h1>

<p>In protest of pending US legislation, which threatens the freedoms of websites like this one and the freedoms of the people who use them, this website is offline on January 18th, 2012 from 8am to 8pm EST.</p>

<p>Please <a href="http://americancensorship.org/">help protect our free speech</a> against the corporate and political interests which seek to take them away!</p>

<p>(And don't worry, we'll be back in business tomorrow!)</p>
</div>

<?php
die();
?>
```
Which means your site will look like this on January 18th. You’ll notice I made some tweaks on mine. This is a default feature of WordPress, by the way. You can design your own maintenance mode page just with this one file, so y’know, party time.

Now there’s only one catch. If you update WP via the automatic updater between now and then, you lose the .maintenance file. I don’t have a fix for that, but if you do, please comment!

And yes, my sites are going dark on the 18th.

ETA: If you have a Multisite and only want SOME sites dark, use Customize the Suspended blog page from WordPress Must-Use Tutorials. Suspend the sites and boom goes the dynamite.

ETA 2: If you’re using MediaWiki (like I am on another site) I came up with this idea to go dark for SOPA. Its just a normal extension that, between those hours, redirects to the same page I use for WordPress. You could have it point to any page, of course.
```
<?php

if ( !defined( 'MEDIAWIKI' ) ) die();

if ( time() >= mktime(8,0,0,1,18,2012)  &amp;&amp; time() <= mktime(20,0,0,1,18,2012) ) {
     
        include('/location-of/wp-content/maintenance.php');
    exit();
}
?>
```
That code, sans the Mediawiki line, will also work as an extension for ZenPhoto, so pass it on.
12 January, 2012