Outlook macros and self-signed certs on Windows 7

If you are trying to get some custom macros to work with Outlook as outlined, for example, here and here, you may be befuddled to discover that that your macros fail silently; usually after restarting Outlook. This is because Outlook is quietly disabling all macros because it hates youI mean, because it doesn’t trust you.  That is to say, it doesn’t trust your self-signed cert.

In Windows 7 it appears as though self-signed certs have to first be copied into a “trusted” group before they can be used. Here’s how to do it:

  1. Run certmgr.msc as an Administrator.
  2. Open the “Personal” tree node in the left pane.
  3. Open the “Certificates” node under the Personal node.
  4. Note that your self-signed certificate appears in the right pane.  It may have a red “X” through it.
  5. Double-click the certificate in the right pane to see instructions about copying the certificate to the “Trusted Root Certification Authorities” store.  Good thing these important details are so easy to discover.
  6. Hold down the control key and drag the cert into “Trusted Root Certification Authorities > Certificates” which should appear immediately below the Personal node.
  7. Follow any prompts to completion.  The red “X” should disappear and your cert should know have a key icon attached to it.
  8. Inside Outlook, re-associate this cert with your macro.
  9. Restart Outlook for the new cert to be applied.

And voila, Outlook trusts you again.

Not, of course, that you should every fully trust it back.

Resetting rkhunter

Here’s another memory crutch.

# rkhunter --propupd will “update the entire file properties database, or just for the specified entries”. Run after a significant system upgrade or prepare for a few moments of self-inflicted panic a day or two later.

Securing Mantis

Any Mantis users out there running older versions should consider upgrading immediately. Recently crackers have been using an exploit in pre-1.1.4 versions of Mantis to execute arbitrary code via a sort parameter. The exploit attempts to execute a call to create_function from manage_proj_page.php.

See the CVE on Mitre and details in the Mantis forums.

It would appear that this exploit is used to create a cron under the username of the web server. When fired, the cron generates a new “mc-root” directory within the Mantis tree which would appear to contain some kind of root kit or similar.

In addition to upgrading, I recommend adding the following to your Mantis conf_inc.php if you do not run an open-access Mantis system:

#############################
# Signup and Lost Password
#############################


# --- signup ----------------------


# allow users to signup for their own accounts.
# Mail settings must be correctly configured to work
$g_allow_signup = OFF;


# Max. attempts to login using a wrong password before
# lock the account.
#
# When locked, it's required to reset the password
# (lost password)
# Value resets to zero at each successfully login
# Set to OFF to disable this control
$g_max_failed_login_count = 3;

How to segfault Apache 2+ with mod_security

Build mod_security against the wrong set of headers, and Apache 2 will mysteriously begin to segfault in a persistent manner. Check which version you’re running with dpkg --get-selections | grep apache2.

Seems my shiny new Debian distro running the prefork version of Apache had the threaded (worker) headers installed against it. Duh. apt-get install apache2-prefork-dev reinstalled the correct prefork headers and Apache is happy again.

Mathiew Dessus has a great article about installing mod_securty on Debian for those interested.

Alternative authentication methods with Apache 2.2

Quick note on how to make alternative authentication modules work with Apache 2.2.

mod_auth_imap kept complaining about a missing password file:

(9)Bad file descriptor: Could not open password file: (null)

Turns out with Apache 2.2 you have to explicitly turn off Basic authentication even when you are using an alternative module. So a proper Apache 2.2 mod_auth_imap configuration would look something like this:

Auth_IMAP_Enabled On
AuthBasicAuthoritative Off
AuthType Basic
Require valid-user
Auth_IMAP_Authoritative On
Auth_IMAP_Server mail.server.com
Auth_IMAP_Port 143
Auth_IMAP_Log On

Turning off AuthBasicAuthoritative forces Apache to ignore the standard password file authentication.

MJ12Bot Virus Robot

There seems to be a “virus bot” out there just now starting to attack servers in Japan. It spoofs the distributed open source search engine Majestic 12 with a user agent string of MJ12bot/v1.0.8 (http://majestic12.co.uk/bot.php?+. (The real Majestic 12 is up to version 1.2.x.)

Use mod_rewrite in Apache to block it:

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^MJ12bot/v1\.0\.8.*$
RewriteRule .* - [F]

Add the above to either httpd.conf or a local .htaccess config file. See the Majestic 12 FAQ for more information.

Note that the way the virus has been hitting some of our sites appears as though it actually attempts to coordinate DOS attacks from multiple servers. Scary if true. And it seems to be smart enough to stop attacking as soon as it realizes that access has been denied.

Update: If you run mod_security, consider appending evil MJ12’s user agent string to the rogue web crawler portion of the bad robots conf file modsecurity_crs_35_bad_robots.conf:

SecRule REQUEST_HEADERS:User-Agent "(?:e(?:mail(?:(?:collec|harves|magne)t|(?: extracto|reape)r|siphon|wolf)|(?:collecto|irgrabbe)r|xtractorpro\
|o browse)|m(?:ozilla\/4\.0 \(compatible; advanced email extractor|ailto:craftbot\@yahoo\.com)|a(?:t(?:tache|hens)|utoemailspider|dsarobot)|w(?\
:eb(?:emailextrac| by mail)|3mir)|f(?:astlwspider|loodgate)|p(?:cbrowser|ackrat|surf)|(?:digout4uagen|takeou)t|\bdatacha0s\b|hhjhj@yahoo|chinac\
law|rsync|shai|zeus|mj12bot/v1\.0\.8)" \
"deny,log,auditlog,status:404,msg:'Rogue web site crawler',id:'990012',severity:'2'"

mod_security returns a 404 Not Found error instead of Access Denied which should further help to confound the virus.

Simple protection for Windows Media streams…

For whatever reason this was virtually impossible to find. Even the Great Google knew not.

Hoyasoft Screenshot

Hoyasoft’s Windows Media Server plugin, VideoGuard, enables a wide range of simple content protection mechanisms for video streams: From basic HTTP authentication to referer URL checking to MD5 ticket validation. VideoGuard’s snap-in admin interface is intuitive and makes setting up URL-level authorization and/or authentication strightforward.

Though the documentation could do with a serious overhaul, Hoyasoft’s email-based technical support is quite good. (Thanks Steve!)

And most importantly, VideoGaurd seems to be the only product on the market offering this kind of simple security functionality. (Which should probably have been built into Windows Media Server in the first place…)

pmafind

Ugh. Nobody seems to know what this thing is, though it seems to be some kind of PHP worm roving the internet looking for phpMyAdmin exploits. It appears to have been around since 2005 and searches for an exploit in the phpMyAuth class of older phpMyAdmin distributions.

I’ve seen it knock one of my servers on three seperate occasions; this from the first:

[05/Jul/2007:20:26:42 -0500] "GET /mysql-admin/main.php HTTP/1.0" 404 280 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /phpMyAdmin-2.5.6/main.php HTTP/1.0" 404 285 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /main.php HTTP/1.0" 404 268 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /phpMyAdmin-2.5.1/main.php HTTP/1.0" 404 285 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /phpMyAdmin-2.5.4/main.php HTTP/1.0" 404 285 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /phpMyAdmin-2.2.3/main.php HTTP/1.0" 404 285 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /phpMyAdmin-2.2.6/main.php HTTP/1.0" 404 285 "-" "pmafind"

Interesting that it looks for specific versions of PHP. And odd that it announces itself by specifying a user-agent. (“Hi, worm here. Please let me in. Got a bit of infesting to do.”)

Deadmoo has a good, recent-ish post about it, though mostly Google just returns random posts and stats pages listing the pmafind referer. Where do these things come from?

sudo sanity

How to have to punch in your password only once per day (or less):

Practicing Safe Emacs

This has been bugging me for years and I finally got around to looking up a solution.

Everyone knows that Emacs is the greatest editor on the planet, superior in all ways to vi. Unfortunately, Emacs has this nasty habit of tossing tilde-terminated backup files around whatever directory in which you happen to be editing. Not only does this clutter up the file system, it can also be something of a security risk; especially if you’re working on web servers. And really, snapshots of your most recent save is not so useful if, like me, you pathologically ctrl-x ctrl-s your code every few characters or so.

After a bit of hunting I discovered that Emacs’ built-in versioning could solve both of these problems. Cons the following two commands into your local .emacs:

;; Enable versioning with default values.
(setq version-control t)

;; Save all backup file into the designated directory.
(setq backup-directory-alist (quote ((".*" . "~/.emacs.d/backups/"))))

and not only will Emacs remember all saves:

$ ls .emacs.d/backups/
!home!gates!GPLv3.txt.~1~ !home!gates!GPLv3.txt.~2~

but, as you see, it also tucks your backups safely out of harm’s way.