chris.gg

Blocking “unsafe” ports is something that Google Chrome has done for a while now, but I’ve only just discovered this feature, trying to connect to an internal host via HTTP on a non-standard port:

The error message is slightly misleading as the endpoint isn’t down, it’s just being blocked by Chrome – ERR_UNSAFE_PORT is the crucial clue.

This seemed odd to me, but there’s a great explanation here. In a nutshell, it’s an attempt to prevent Chrome being used as a way to attack potentially vulnerable services. Because many implementations of simple plain-text protocols such as SMTP, FTP and Telnet are very tolerant of errors (i.e. simply ignoring commands that don’t make sense), it may be possible for a malicious or compromised website to trick a user’s browser into sending a specially-crafted HTTP request that contains valid commands in the target protocol.

There is an unofficial list of restricted ports here – in my case, the port’s being blocked as it is one of the ports commonly used for IRC (Internet Relay Chat). On desktop Chrome, there is a workaround that allows you to disable this behaviour on a per-port basis, but as far as I can see, there’s no way to do this on the Android version of Chrome. The only real solution is for developers to avoid using these specific non-standard ports for HTTP (there are plenty of other ports to choose from!)

It’s quite an interesting idea, and while in an ideal world there wouldn’t be any services vulnerable to this sort of attack, we all know the reality is quite different. On balance, I think I’m in favour of Google (and Mozilla, who include similar functionality in Firefox) including this simple protection to help make the Web a safer place.

At the time of writing, Internet Explorer on Windows 10 doesn’t seem to block unsafe ports, but the latest version of Edge (which is based on Chromium) gives the same ERR_UNSAFE_PORT error as Chrome.

I’ve just been reading about the CSV Injection attack – a new one to me, and somewhat surprising that it exists. The source of the problem seems to be a gap between what the CSV format was originally conceived to be (a flat-file format containing only “safe” alphanumeric data) and how modern applications such as Microsoft Excel and OpenOffice/LibreOffice Calc actually interpret the contents of a CSV file.

Many web applications allow users to download bulk exports in CSV format, and if this attack isn’t mitigated, an attacker can potentially include a malicious formula that could execute an arbitrary command on the user’s machine, or enable data to be exfiltrated. In most cases, the user will be presented with one or more warnings, but normally these are worded such that users are likely to dismiss them because they deem the CSV file to have originated from a “trusted” source.

The mitigation is to ensure that no fields within a CSV file begin with the equals sign (=) or any of the several other characters that may cause a spreadsheet application to interpret the contents as a formula to be executed. Additionally, field separator characters such as comma (,) and semicolon (;) should also be disallowed anywhere within the user input, as these could be used to start a new field to defeat the protection above.

The Veracode API is new to me, so to get to grips with it I decided to fire up Postman and make a few requests. I was initially unsure where to enter my API ID and secret key, and despite trying a few things I kept getting authorisation errors, because the API uses HMAC authentication which is not directly supported by Postman.

The solution I eventually stumbled across was thankfully simple. You just need to grab the pre-request script from here (thanks to Veracode’s Chris Campbell!) and paste it into the Pre-request Script section of your request tab. Finally, add two variables to the Globals tab: veracodeApiKeyId and veracodeApiKeySecret, paste in your Veracode API ID and secret key respectively, and you should now be able to make a successful API request.

Note that you don’t need to select anything in the Authorization section for this to work (just leave it as No Auth).

In Windows 10, you can type cmd in the address bar of any File Explorer window, and it’ll open a command prompt with the working directory already set. Much quicker than opening a command prompt the usual way and having to cd to the right directory, especially for long nested paths.

Having used Windows 10 since it first came out, and Windows Vista/7/8/8.1 before it, I was surprised when I recently discovered this trick!

The Synopsys (Cigital) web app officially supports only Google Authenticator, Microsoft Authenticator or Authy for 2FA. However, if you already have Okta Verify installed on your phone, and don’t want to install another authenticator app, you can follow this process.

1. Log into Synopsys and click your username in the top right
2. Click 2-Factor Authentication Settings then Edit
3. Select Google Authenticator
4. On your phone, open Okta Verify and tap the + icon
5. Click Organization then Scan a QR code
6. Scan the Synopsys QR code
7. Type the resulting 6-digit code and your password into the Synopsys window

At work, I maintain an Access 2010 database that interfaces with Word, Excel and Outlook. Recently, Lync 2013 was rolled out across the office, without upgrading the rest of Office. Suddenly all interop calls started failing with “Automation error. Library not registered.” errors.

A bit of digging revealed that the Lync 2013 installation process adds registry entries for the Office 2013 (i.e. version 15) automation libraries, regardless of whether the individual 2013 applications are installed. The solution is to remove the offending registry keys, keeping the version 14 keys in place.

I put together the following .reg file to remove the keys for Outlook, Word and Excel respectively:

Windows Registry Editor Version 5.00
[-HKEY_CLASSES_ROOT\TypeLib\{00062FFF-0000-0000-C000-000000000046}\9.5]
[-HKEY_CLASSES_ROOT\TypeLib\{00020905-0000-0000-C000-000000000046}\8.6]
[-HKEY_CLASSES_ROOT\TypeLib\{00020813-0000-0000-C000-000000000046}\1.8]

There doesn’t seem to be an official Microsoft solution for this – I previously repairing the Office 2010 installation but this had no effect.