Imagine that you want to check a small configuration file for malicious manipulations. Let's further assume that the file is very small (only 5 non-comment lines) and that you know the expected contents of the configuration file very well. Doesn't it sound like a really easy task to find out whether there is a backdoor in the configuration file or not? Well, it may have been a simple task until Linux distributions started to enable Unicode in the default installation. Today things are a little bit different and it is entirely possible to make a malicious manipulation to a simple configuration file which can't be seen when viewing the file in a terminal with cat, less or a text editor using a Unicode homoglyph attack .
Before we start, let's take a quick look at the file /etc/pam.d/common-auth:
[...]
auth [success=1 default=ignore] pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth requisite pam_deny.so
[...]
The entry "success=1" for pam_unix.so means that the following line (the call to pam_deny.so) is skipped if the module pam_unix.so (which does the standard unix password checking) succeeds. If the password checking fails (e.g. because the user entered an invalid password), the call to pam_deny.so is executed, which makes the authentication fail. The following two lines add a nearly invisible backdoor to this configuration file:
cp /lib/*/security/pam_permit.so /lib/security/pam_de
First of all, the file pam_permit.so is copied to /lib/security/pam_deոy.so (the 'n' in pam_deny.so is replaced with the Unicode character u+578, which looks more or less exactly like the real 'n' in many fonts). The perl script then changes the file name pam_deny.so in the configuration file to pam_deոy.so with the Unicode character u+578 instead of the 'n' so that it points to our copy of pam_permit.so instead of the original pam_deny.so file. The result of this is that if even if the password checking in pam_unix.so fails, the call to pam_permit.so makes sure that the authentication still succeeds. Since the two characters look exactly the same with many terminal fonts, the configuration file looks like the original when viewed with cat, less or a text editor. Therefore this backdoor is pretty difficult to detect even if the system administrator takes a close look at the manipulated configuration file.
\u578'y.so
perl -i -pe's/deny/de\x{578}y/' /etc/pam.d/common-auth
First of all, the file pam_permit.so is copied to /lib/security/pam_deոy.so (the 'n' in pam_deny.so is replaced with the Unicode character u+578, which looks more or less exactly like the real 'n' in many fonts). The perl script then changes the file name pam_deny.so in the configuration file to pam_deոy.so with the Unicode character u+578 instead of the 'n' so that it points to our copy of pam_permit.so instead of the original pam_deny.so file. The result of this is that if even if the password checking in pam_unix.so fails, the call to pam_permit.so makes sure that the authentication still succeeds. Since the two characters look exactly the same with many terminal fonts, the configuration file looks like the original when viewed with cat, less or a text editor. Therefore this backdoor is pretty difficult to detect even if the system administrator takes a close look at the manipulated configuration file.