3

There's several places in my ‘personal security infrastructure’ (is there a better phrase for that?) where I find myself typing very important passwords into text-fields on OS X (for instance, dis-encrypting and mounting thumbdrives containing very sensitive data.)

I'm (perhaps unreasonably) afraid of keyloggers, as these are the only method I can think of short of a system-level vulnerability or physically watching (or recording) my activities when entering the password. In other secure systems I use, there's an option to enter a final part of the password using the mouse or similar, to help avoid keyloggers making an attacker's job too difficult.

tl;dr: Is there any way to (partially) defeat keylogger attacks against system-level password entry on OS X?

Edit: Because I'm not here to discuss the feasibility of keyloggers on OS X, let's presume I'm talking about defending against a physical keylogger being injected into my keyboard's data pipeline. (Either a replaced keyboard with the logger hidden inside, or something attached on its' USB cord.)

5
  • 2
    My ‘personal security infrastructure' - My lab.
    – pavanw3b
    Jan 4, 2015 at 10:04
  • No, there is no sureshot way of detecting a keylogger. Using a good antivirus and a separate password-protected user account does help, though. Keyloggers wouldn't be in the market if they could be detected easily. Jan 4, 2015 at 13:09
  • Sorry, the question wasn't about detecting keyloggers, but about helping to mitigate the danger. (Detecting keyloggers is a rather pointless task, as somebody could just throw one on your keyboard's USB cord, behind your desk.) Jan 4, 2015 at 23:02
  • (Researchs have shown that even a phone with an accelerator lying next to the keyboard can be used to record keystrokes, so do not put your phone on your desk!)
    – idmean
    Feb 5, 2015 at 19:21
  • You could just use a hardware 2FA device. Oct 23, 2015 at 2:20

3 Answers 3

2

Is there any way to (partially) defeat keylogger attacks against system-level password entry on OS X?

Yes. The traditional keylogger is a hardware device that intercepts data between the the keyboard and the intake of character data at the Keyboard Controller (mostly USB Device, HID Keyboard). The physical components are few and various tamper evident seals may be used to assure the integrity of the physical system. You would need a initial check to insure that no physical keylogger exists then attach or install the seals. Frequent or periodic checks of the seals must then be performed to verify that the hardware's integrity is intact.

However most modern keyloggers are software or firmware based and thus may only be defended against by software security methods. This includes the chain from the keyboard controller IC firmware, keyboard controller device driver, OS level USB subsystem, keyboard buffer, and shell software.

This would require you to find the firmware or software for each component in the chain and verify that it has not been tampered with. This is usually done by obtaining from the manufacturer a cryptographic hash of the firmware or software for the component and computing the cryptographic hash of the software currently in use on the system in question. If the cryptographic hash values match then the firmware or software is unmodified.

The more software in the chain, the harder it is to protect and verify just by the nature of growing complexity and more permutations of instruction sequences.

There's several places in my ‘personal security infrastructure’ (is there a better phrase for that?) where I find myself typing very important passwords into text-fields on OS X (for instance, dis-encrypting and mounting thumbdrives containing very sensitive data.)

I'm (perhaps unreasonably) afraid of keyloggers

In hardware keyloggers yes, in software keyloggers no.

as these [Keyloggers] are the only method I can think of short of a system-level vulnerability or physically watching (or recording) my activities when entering the password.

No, there are many other ways of determining your password. The most common one is to find a exposed password or phrase from another system and attempt to use it on the system in question. This is usually successful as most people reuse passwords.

Another trivial example is to attempt to find frequently used keys on your keyboard either from dirt or ware and try the limitied combinations of those frequently used keys to find the password;

frequently used keys

Additionally there are various forms of social engineering and phishing that are quite effective.

In other secure systems I use, there's an option to enter a final part of the password using the mouse or similar, to help avoid keyloggers making an attacker's job too difficult.

There are two posibilites here. They keys is split, meaning that part of the key is stored in a container on the system and part of the key is stored in you mind. Or the full key is stored in a container and the system only needs a few charactors to determine which key you need.

There are also two general types of key splits: one I call sectioned, and one I call full key length split. The sectioned one takes a key with n bits and divides it into two or more parts.

For example: take a key 0xA55AC33C and split it to 0xA55A and 0xC33C.

The full key length split takes a key of n bits and divides it into two or more parts of length n.

For example: take a key 0xA55AC33C and split it into 0x42244224 and 0xE77E8118.

The sectioned split is a poor choice for several reasons including exposure to brute force attacks, and problems recombining the key in the correct endianess and order.

A sectioned split might seem to foil a keylogger, but not if entering the same split allows an attacker to access the sensitive data. For example: if you only need to enter 0xC33C and the keylogger records this then an attacker can enter 0xC33C and gain the same access.

Generally, shell level commands which do not output sensitive charactor data to the screen or to the shell log buffer are more secure than graphical components.

3
  • None of those ‘many ways’ of finding my password apply, trust me. In the sorts of situations described above, the passwords are very rarely used, and completely unique to the specific use to which they're put. Apr 7, 2015 at 12:26
  • Re: the ‘container’ necessary to do mouse-based keyboard entry … I must be missing your point; I don't see why the key as a whole would have to be stored unhashed anywhere to use an secondary form of entry for part of the key? Apr 7, 2015 at 12:27
  • 1
    You could also by some dint of sheer force of mind, regularly remap your keys and sight read off the keys.
    – munchkin
    Apr 17, 2015 at 9:07
0

on mac os X its ( just like on all *NIX's) not that easy to just "capture" the keyboard without the user being able to find that out. You would need a kernel module for that and its not that easy to trick OS X into loading it for you (apple has some nasty features for when it updates). you can just ask the system what keyboards it knows, and there are even some features (like for the password box) that REQUIRE a direct keyboard 2 app interaction (so called secure-keyboard functionality) With secure-keyboard no other program is allowed to interfere with your input (enforced by the kernel), so just plugging in a HUD-device would not yield the input (a MITM Capture device would though, as would a modified keyboard firmware, e.a. the program in the keyboard itself).

Enabling a on screen keyboard would bypass the OS X security measures (can be done, but requires you put the system into an unsafer running mode that disables secure-keyboard) On os X each keyboard works independently (check the caps lock for example) so you could get the same advantage by typing in your key using 2 keyboards.

3
  • 1
    (Er, depends on exactly what you meant by ‘without the user being able to find out’; but by my definition thereof: it's pretty trivial to write a non-kernel, non-root keylogger on OS X, without a normal user noticing. Any application can observe other applications' keyboard events unless the primary application is in EnableSecureEventInput mode. Not a 'nix thing, an OS X-specific thing.) Jan 6, 2015 at 17:57
  • on your own dev systeem yes. but running such an application on just any mac requires that the user actually "runs" your software (its not from the appstore so apple warns the user). And its easy to find out that thats beeing done. (that's where the nix thing comes into play) you can just ask the kernel where it routes the keyboard events (or so I am told)
    – LvB
    Jan 8, 2015 at 9:50
  • Good information in this answer, but I think the question was more about how to protect against keyloggers without being paranoid all the time and having to audit the codebase of every program you run/compile. I too am curious about this, as with a dev machine I run a lot of software that's not signed by Apple. If there's a way to have OS X literally prompt me every time a process requests keyboard access, that would be awesome.
    – AJAr
    Feb 5, 2015 at 22:14
0

You can partially defeat the keyloggers, you can update to OS X 10.11 which added the rootless SIP feature. Keyloggers such as Aobo keylogger for Mac won't work if SIP is enabled. Also check system preferences -- security and privacy ~ assistive devices to stop any keylogger access. But some workplace monitoring software like Easemon employee monitor for Mac won't be affected by SIP so this is only a partial solution.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .