Monday, March 20, 2017

Chop That Dollar

Its been quite some time since I've received a 419 spam message in my inbox. But - like matter itself - 419 never dies - only changes form. I found the message below in my inbox this morning.

I was pleased to note that the message originated from Yahoo, and contained several classic red flags for spam that even the neophyte mail server admin knows to watch out for, like from & reply-to headers with different different domains. This is the kind of l33t security I've come to expect from Yahoo. But hey, the Russians did it, and no one can be expected to secure their customers from state sponsored attacks. Susan here is no doubt a member of Nigeria's elite NIA.

From: Susan ***** desmondwilliams614
Subject: Hello,
Date: Sat, 18 Mar 2017 12:12:52 +0000 (UTC)
Reply-To: desmondwilliams614 Susan ***** deswill0119


Greetings. With warm heart I offer my friendship and greetings, and I hope that this mail will meets you in good time.

However strange or surprising this contact might seem to you as we have not meet personally or had any dealings in the past. I humbly ask that you take due consideration of its importance and immense benefit.

My name is Susan Williams from Republic of Sierra-Leone. I have something very important that i would like to confide in you please,I have a reasonable amount of money which i inherited from my late father (Nine Million Five Hundred thousand United States Dollar}.US$9.500.000.00.which I want to invest in your country with you and again in a very profitable venture.

Currently I am residing in Ivory coast now with my Brother Desmond Williams where my late father deposited the money, so i will like you to reply me immediatly so that i will give you more details about everything.

Iam expecting your reply for more explanation. Please i am urgently waiting for your response and I am conceding 15% of this money to you for your efforts assistance.

I will wait to hear from you.

Thanks and God bless you.

Our sincere regards to you,

Susan and Desmond Williams

The NIA's battle cry:

Tuesday, March 7, 2017

Wikileaks releases massive trove of CIA documents

Today Wikileaks released a massive new trove of leaks focused on the CIA's IT-based espionage capabilities. Wikileaks has named the document release Vault 7. The trove has just been released this morning, so details remain sketchy, however the included documents appear to contain detailed information related to dozens of malware tools used by the CIA's Center for Cyber Intelligence.

Earlier this morning I heard an NPR report claiming that Wikileaks was redacting the source code associated with these hacking tools. I'm not sure if that is correct; I've found a few files with executable scripts included, but none of the scripts I've found so far are essentially malicious (although they were almost certainly used in the development and packaging of malware). I have found indications that Wikileaks redacted exploit files that were ready for as-is distribution. For example, the files I reviewed in the dump appear to be part of an internal wiki. I reviewed a file list associated with one of the users registered for the wiki (; clicking through the link for a file named '~02.2.3.tmp` - - provided  me with this:

File: ~02.2.3.tmp
MIME: application/x-dosexec; charset=binary
Size: 389632

I have taken significant issue with Wikileaks in the past. My complaints have focused entirely on Wikileaks' unwillingness to remove dangerous (and almost certainly state-sponsored) malicious software from document dumps. The example I cited above is the first time I have ever seen any indication that Wikileaks removed malware from a dump. Unfortunately, this particular editorial decision is of substantially less value then the requests I repeatedly made to Wikileaks to inform their users of the presence of infected files within and older document dump that they continue to publish through the website. The censored malware files in Vault7 were contextually and obviously labelled as malware. The malware I found in earlier Wikileaks dumps included infected document files that were in many cases completely indistinguishable from normal document files and in several cases not detectable for a substantial variety of antivirus platforms.

If you are a journalist or concerned citizen preparing to begin reviewing the Vault 7 document dump, I strongly advise you to take strong security measures prior to beginning your review:

    1. Assume every file in the dump contains a malicious file & govern yourself accordingly. The principle here is similar to the sort of "universal precautions" utilized by medical professionals. This includes files that you may not think of as having the ability to infect your computer with malware, such as text documents, images, spreadsheets and PDFs.

    2. Download & inspect the documents using a computer dedicated to the task. An operating system designed for secure analysis of malware should be used, such as Kali Linux or TAILS. There is compelling evidence that Microsoft provides state-sponsored attackers with backdoors to the Windows OS. After downloading the files, completely disable the internet connectivity for your review computer by disabling (or even disconnecting) any network interfaces.

The inspection of malware is a complex topic that can't be covered in a single post, however the consequences of insecure handling of documents infected with state-sponsored malware are serious - while the advantages of safe handling are substantial. Would you feel comfortable providing a list of your sources to a random government intelligence service? Every reporter I have discussed the issue with feels a strong sense of responsibility for protecting their sources, up to and including a willingness to face incarceration. Securing your IT tools is not as dramatic as saying "No" to a judge threatening you with contempt, but for many sources the threat posed by an intelligence service dwarfs that of a court. Arrest is bad; being "disappeared" is worse.

The average reporter would not defend herself from a finding of contempt of court  - newsrooms invest substantially in legal resources under the calculation that protecting the sources and first amendment rights of journalists serves the both the bottom line & cultural interests of newspapers. Likewise, newsrooms must now consider the expense of an on-staff or consulting systems administrator with a background in security as a cost of doing business. Its not a happy thought, but this is the world we now live in: a world where every communication is spied on, documented, indexed and stored, secretly; and it has been for many years.

So thats the stick. What about the carrot? Malicious software contained within the files is as much a part of the story as the files themselves. Sourcecode comments and filesystem metadata can provide important clues related to the authors of, history behind and justification for distributing data. A thorough investigation of leak files can be the sole opportunity to reveal the true story behind a leak; the alternative, in the absence of communication with the true source of the leak, is to print a summary of a Wikileaks press release supplemented by a Government press release.

Tuesday, February 21, 2017

Testing Laptop Batteries

Since I was gifted a new Raspberry Pi this Xmas, I've found myself becoming much more interested in the details of computer hardware than I've previously been. Among the first thing that I've wanted to do with my Pi is build an on/off switch - Pi are very bare bones, and require you to shutdown or reboot using software. Cold booting happens immediately after plugging in a power cord. This sort of setup is less than ideal for a huge number of reasons - there is little to no in-built hardware to protect my Pi from a power surge, and I have a lot of uses in mind for this and future Pis that make an external surge protector unrealistic. Even for home/office use where the Pi is connected to a stable power source, I'd like something akin to the power button that comes with desktops & laptops that can send an ACPI signal which I can in turn manage a bit using /etc/acpi/

Anyway, I have quite a bit to learn in this area. I've worked with power, but its almost always been external / data center-scale power. Onboard power is less sexy but no less interesting and substantially more helpful to my own individual hacking efforts. This new-found interest has lead me in all sorts of directions. I've found myself testing laptop batteries instead of reflexively replacing them when they start acting funny. The video below has been quite helpful to me - testing the actual capacity of a laptop battery can be a bit complicated, and measuring the voltage of a battery requires you to run to ground (which in turn requires you to figure out which terminals the ground *is*). Check it out:

Tuesday, December 13, 2016

How to Authenticate WHMCS Admin Users with PHP

Over the past few days I've been working on a project that involved building an authentication mechanism for a new website which checks user logins against a WHMCS admin database. There are a variety of options for authenticating normal, non-admin WHMCS users: on the easy side of things, you can simply use the WHMCS API's validatelogin() call, or for a more advanced project its possible to implement OAuth within your WHMCS instance. For my project, neither LDAP nor Active Directory were options.

I was surprised to find that the WHMCS API did not contain a mechanism for authenticating admin users. I'm somewhat sympathetic given the security implications: WHMCS is a billing application and it should not be used to provide a sortof infrastructure authentication backbone, particularly given the many much more mature options available for this sort of thing. With that said, this project wasn't about looking to turn WHMCS into LDAP ... it was about allowing WHMCS admin to authenticate into a custom application that was directly and inextricably linked to WHMCS functionality.

When I came up empty on the API front I started Googling for a reasonable alternative, and I found a small number of other options. I became interested in the idea of building my own WHMCS API function to take care of this, but I still needed to take care of the authentication mechanism itself. WHMCS has a page in its documentation that describes in general terms how Admin passwords are hashed, and this page even contains PHP code samples that purport to allow you to auth admin user:password combinations. There are two samples; the first sample demonstrates how to use the WHMCS\Auth namespace and the comparePasswords() function, like so:

use WHMCS\Auth;
$authAdmin = new Auth;
if ($authAdmin->getInfobyUsername($username) && $authAdmin->comparePassword($password)) {
    $isValid = true;
} else {
    $isValid = false;

Pretty straightforward; and this sample works as far as it goes. However, WHMCS provides a second, more thorough example demonstrating how to use the function within a form. You can download a ZIP fie containing this sample here. Unfortunately, this second snippet is broken in a number of places. This second example provides a single file that contains an HTML form with some javascript to display a popup notification when an authentication failure occurs, and a PHP script that takes care of the password comparison. It is the PHP that has problems. I found a variety of fatal errors which made the example unusual: the WHMCS\Auth namespace was called in the wrong scope, the include for the WHMCS init Autoloader is called within a function in such a way that it remains unavailable for other functions, the example uses a class - WHMCS_Auth - which does not exist ... it took a little while for me to sort them out.

Anyway, I found the experience irksome enough that I posted a corrected version of the WHMCS Admin authentication script in a Github repo so that no one else will have to deal with this in the future. I've tested my new version in WHMCS 6.3.1; no guarantees for the latest version 7 at this time, but I can guarantee that WHMCS' example won't work in 7.

I hope it helps!

Saturday, December 3, 2016

Assigning default ownership to all new files in a directory

Getting the hang of Linux file-system permissions can be tricky for beginners. I still have problems every now and again translating symbolic permission notation to octal permission notation and back again. One common scenario which can be complicated to enact in practice is the creation of default permissions for files inside of given directories. Although not a direct translation, in Windows this sort of functionality is usually implemented by selecting the "Allow propagation on child objects" setting when viewing Security Properties for a directory. But how to get this done in Linux?

The preferred approach is the use of Access Control Lists using setfacl. Since Linux kernel 2.6, the acl flag is enabled by default with most standard filesystems. There's already several solid explanations for how to use Linux ACLs. But, there are scenarios in which this can be difficult or impossible to implement; using exotic filesystems or older kernels, etc. Or you just might find ACL syntax confusing and try to avoid it unless absolutely needed. Whatever the reason, if all you need is to have all files in a given directory owned by a specific group and/or assigned a specific set of permissions, here's a down and dirty way to do it using a set-group-id bit.

umask 002 /somedirectory/              ### With this mask default subdirectory permissions are 775
                                                         ###  and default file permissions are 664 (-rw-rw-r--)
chgrp somegroup /somedirectory/   ### here we assign our preferred group
chmod g+s /somedirectory/             ### here we assign a set-group-id bit to the directory

Keep in mind that the umask in this example is pretty wide open. If you're not familiar with umask, take a look at one of the many guides floating around. I am much more likely to use a umask of 022 or 077 in production than the above example.

Tuesday, November 8, 2016

A nasty pair of MySQL exploits grant attackers system root from any database user

Four days ago I received an email from Dawid Golunski through the list illustrating one of the more brutal pair of security vulnerabilities I have seen recently. Here's how it works.
    The exploit uses a vulnerability within MariaDB, PerconaDB (and/or XtraDB Cluster) and MySQL to, first, gain access to the 'mysql' system user using any mysql user that has CREATE / INSERT / UPDATE permissions. The first part revolves around a race condition when sql generates temporary files as part of the `REPAIR table` command. Then using the mysql system user the second vulnerability grants the attacker root access to the server using a clever hack that takes advantage of mysql_safe's approach to writing to file based error logs. Below I've provided a list of vulnerable server versions. Just about any server using the more recent (unpatched) stable releases of MySQL or MariaDB through CentOS is vulnerable (Percona isn't part of the standard CentOS repositories), with a few of caveats.
    The first caveat is that an unpatched vulnerable server can prevent at least the 2nd exploit by disabling symlinks through /etc/my.cnf using skip-symbolic-links or symbolic-links=0
    The next caveat is that the 2nd exploit also depends on using file-based mysql logging. Using syslog will avoid trouble.
    The third caveat is that for the 1st exploit to work an attacker needs a mysql user and password.
    There is some good news here. The latest stable versions of MariaDB at least disable symbolic links in my.cnf by default (its been a while since I installed MySQL through the repo but I'm fairly sure its disabled here as well). And how would an attacker get a MySQL user anyway?
    Consider that because *any* MySQL user to be used, an un-patched shared server used by a hosting company would depend on the security competency of every one of that c customers to securely handle database authentication. Not only are there a variety of exploits available for obtaining a standard database user, but its depressingly common for web designers to place their connection strings with un-encrypted database username and password into world-readable files. There are a variety of feeds and sites that scan the internet for and compile such files.
    And even without the use of the 2nd exploit, an attacker can still do an enormous amount of damage without server root with only the mysql system user. The attacker will have full access to the MySQL system files. An attacker could easily delete an entire database instance, for example.
    Of course the best part is that this is a vulnerability in MySQL itself. Upgrading MySQL is the scariest, riskiest upgrade there is among standard repo software. A lot of admins compile it from source or install it from a direct RPM (in which cases symlinks are enabled by default). And applications are closely linked with the database version. Even successful upgrades can easily break applications that run on that database as calls used by the application become deprecated. Upgrading applications has substantial costs, whether you develop the application itself or license it. A patch was already in circulation before these exploits were posted, but for all of the reasons listed above, vulnerable databases will be active for years.

Here are the impacted DB versions:

 < 5.5.52
 < 10.1.18
        < 10.0.28

 <= 5.5.51
 <= 5.6.32
 <= 5.7.14

Percona Server
 < 5.5.51-38.2
 < 5.6.32-78-1
 < 5.7.14-8

Percona XtraDB Cluster
 < 5.6.32-25.17
 < 5.7.14-26.17
 < 5.5.41-37.0

Here the first two links below contain a comprehensive breakdown of both exploits with example scripts that you can run to test.

This link includes a video illustrating how a compromise takes place using the example scripts: