Archive for January, 2014

Tags used by OWASP CRS ModSecurity rules

Saturday, January 18th, 2014

I couldn’t find a definitive list of the tags used by the OWASP CRS ModSecurity rules, so after a bit of faffing around, here’s what I’ve come up with for the “base” rules in OWASP CRS version 2.2.9 (current at the time of writing).

I’ve tried to group them together as best I can:

Web Attack:

OWASP_CRS/WEB_ATTACK/XSS
OWASP_CRS/WEB_ATTACK/DIR_TRAVERSAL
OWASP_CRS/WEB_ATTACK/RFI
OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION
OWASP_CRS/WEB_ATTACK/CF_INJECTION
OWASP_CRS/WEB_ATTACK/SQL_INJECTION
OWASP_CRS/WEB_ATTACK/FILE_INJECTION
OWASP_CRS/WEB_ATTACK/PHP_INJECTION
OWASP_CRS/WEB_ATTACK/LDAP_INJECTION
OWASP_CRS/WEB_ATTACK/SSI_INJECTION
OWASP_CRS/WEB_ATTACK/REQUEST_SMUGGLING
OWASP_CRS/WEB_ATTACK/SESSION_FIXATION

Protocol Violation:

OWASP_CRS/PROTOCOL_VIOLATION/IP_HOST
OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ
OWASP_CRS/PROTOCOL_VIOLATION/INVALID_REQ
OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_HOST
OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT
OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_UA
OWASP_CRS/PROTOCOL_VIOLATION/EVASION
OWASP_CRS/PROTOCOL_VIOLATION/PROXY_ACCESS

Policy:

OWASP_CRS/POLICY/SIZE_LIMIT
OWASP_CRS/POLICY/EXT_RESTRICTED
OWASP_CRS/POLICY/FILES_NOT_ALLOWED
OWASP_CRS/POLICY/PROTOCOL_NOT_ALLOWED
OWASP_CRS/POLICY/ENCODING_NOT_ALLOWED
OWASP_CRS/POLICY/METHOD_NOT_ALLOWED

Leekage:

OWASP_CRS/LEAKAGE/INFO_STATISTICS
OWASP_CRS/LEAKAGE/INFO_DIRECTORY_LISTING
OWASP_CRS/LEAKAGE/INFO_FILE
OWASP_CRS/LEAKAGE/SOURCE_CODE_ASP_JSP
OWASP_CRS/LEAKAGE/SOURCE_CODE_CF
OWASP_CRS/LEAKAGE/SOURCE_CODE_PHP
OWASP_CRS/LEAKAGE/ERRORS_IIS
OWASP_CRS/LEAKAGE/ERRORS_CF
OWASP_CRS/LEAKAGE/ERRORS_PHP
OWASP_CRS/LEAKAGE/ERRORS_ZOPE
OWASP_CRS/LEAKAGE/ERRORS_SQL

Malicious:

OWASP_CRS/MALICIOUS_CODE
OWASP_CRS/MALICIOUS_SOFTWARE/TROJAN
OWASP_CRS/OWASP_CRS/MALICIOUS_IFRAME (not sure why this one has “OWASP_CRS” in it twice)

Automation:

OWASP_CRS/AUTOMATION/MALICIOUS
OWASP_CRS/AUTOMATION/SECURITY_SCANNER

Miscellaneous:

OWASP_TOP_10/A6
PCI/6.5.6
WASCTC/WASC-13
CAPEC-272

XenConvert fails to import OVF to XenServer

Saturday, January 11th, 2014

I recently ran into a problem when trying to P2V a server with the Citrix XenConvert tool.

XenConvert would successfully create the local VHD file for the disk image as well as the OVF file for the server and then copy them to XenServer, however at the vert last hurdle (actually importing the OVF into XenCenter), it would then fail with a rather unhelpful “Failed to import the OVF Package” message.

The relevant part of the XenConvert.txt log would look something like this:

Physical to OVF Package stopped at <date/time>
Physical to OVF Package lasted <duration> seconds
Source is <path>.
Destination is <XenServer IP>.
OVF to XenServer started at <date/time>
Importing OVF Package…
Failed to import.
Failed to import the OVF Package.
OVF to XenServer stopped at <date/time>
OVF to XenServer lasted <duration> seconds
Physical to XenServer stopped at <date/time>
Physical to XenServer lasted <duration> seconds

It turns out that the OVF package has in actual fact been successfully imported in to XenServer, it’s just that for whatever reason XenCovert fails to remove the “hidden” flag from the resulting Virtual Machine.

You can see the hidden Virtual Machine in XenCenter by selecting “Hidden Objects” from the “View” menu.

In order to make the virtual machine permanently visible, you need to switch to the console and find the UUID of the virtual machine using:

xe vm-list

Once you have the UUID, you can remove the “hidden” flag from the virtual machine with the following command:

xe vm-param-remove uuid=<UUID> param-name=other-config param-key=HideFromXenCenter

Obviously you need to replace “<UUID>” with the UUID that you found in the output of the vm-list command.

You should now have a normal, fully functioning Virtual Machine which you can see without “Hidden Objects” enabled in XenCetner.

OpenVZ reboot loop

Thursday, January 2nd, 2014

I recently encountered a strange reboot loop with a server running OpenVZ.

When booting the server, the host would come up and start the process of booting the containers, then at some point during the boot process it would reboot without any errors.

I managed to break the reboot loop by quickly SSHing in to the host node whilst it was starting the containers and disable the “vz” service so that it wasn’t started at boot time:

chkconfig vz off

On the next reboot, this broke the reboot loop and allowed me to get in via SSH and look around the system properly.

The only hint that I had to go on was that whilst most of the containers brought up during the boot sequence said “starting container”, the container immediately prior to the unexpected reboot said “restoring” instead.

This prompted me to look in the “/vz/dump/” folder, where I found a file called “Dump.” (Obviously was the container ID of the container which was being restored instead of started).

Simply removing this dump file allowed the “vz” service to be started without causing a reboot and everything started working as normal.

The only thing left to do at this point is to remember to enable the “vz” service again so that it will start during the next system boot:

chkconfig vz on

cPanel breaking Dovecot in 11.40

Thursday, January 2nd, 2014

Recently I’ve had a couple of cases where cPanel randomly breaks Dovecot with one of the cPanel 11.40.x updates.

In one of these cases, cPanel actually uninstalled the Dovecot RPM as part of the automated, overnight upcp process! In the other cases, Dovecot was still running and accepting connections, but POP3/IMAP clients were getting messages that their passwords were wrong.

Reinstalling Dovecot if upcp has decided to remove it for some reason is quite simple – just use the cPanel script to check and repair their RPMs:

/scripts/check_cpanel_rpms –fix

Whilst the Dovecot RPM is now installed, chances are that Dovecot is still left in a broken state with any login attempt failing and messages like this in /var/log/maillog:

dovecot: auth: Fatal: execv(/usr/local/cpanel/bin/dovecot-wrap) failed: Permission denied

If you look at the ownership and permissions on /usr/local/cpanel/bin/dovecot-wrap, you’ll find that it’s root:root instead of root:dovecot and so you need to run the following in order to fix the ownership:

chgrp dovecot /usr/local/cpanel/bin/dovecot-wrap

At this point, you won’t be seeing any of the permission errors in the maillog, but you’ll still be seeing failed authentication attempts. Now you want to trick cPanel into thinking that the RPM has been removed so that it will try and re-install it. This should mean that the scripts from the RPM are executed without replacing any of the files:

rpm -e –nodeps –justdb dovecot
/scripts/check_cpanel_rpms –fix

If you are still having problems at this point, then try running the following to set the setuid flag for the owner on the script:

chmod u+s /usr/local/cpanel/bin/dovecot-wrap

Then you just need to re-run the above RPM trick and Dovecot should spring back into life with successful authentication attempts being logged into the maillog.

According to cPanel support, this is a “known issue” which has somehow made its way through the EDGE, CURRENT and RELEASE tiers into the STABLE tier…