#ics382

As with any other test in the real world, biometric security is subject to both false negatives (cases of individuals who should have access being denied) and false positives (cases of access being  granted to influencers lacking clearance). According to Motherboard in an article whose link is posted below, researchers at the N.Y. University’s Tandon School of Engineering have managed to create sets of generic ‘master fingerprints’ that have been engineered through machine learning to cause false positives in fingerprint identification systems at a rate 30x greater than brute-force testing with random real fingerprint samples. While this hasn’t been implemented in physical systems yet (e.g. no capacitive false fingerprints have been manufactured), the implication here is that a potentially feasible brute-force attack can bypass biometric identification and erode the security of assets secured with those systems.

The DH key exchange is a method by which two entities may establish a so-called ‘shared secret’ which can be used to facilitate secured communication over an unsecured line. It exploits what are essentially shared arbitrarily long primes to mutually agree on a third, secret prime in such a way that any eavesdroppers cannot derive that third prime.

Included below are a series of slides from University of TX, Austin, as well as a YouTube video posted by Computerphile on the DH key exchange.

U of Tx : Dr. Bill Young, https://www.cs.utexas.edu/~byoung/cs361/lecture52.pdf

Welp, it looks like I missed Week 8. I’ll be posting for “Week 8″ later, even though it’s extremely late.

Anyways! Today’s topic is the recent vulnerability in LibSSH. On BleepingComputer, there is an article discussing the recently-discovered issue whereby users of LibSSH were easily compromised by an unexpected and fairly simplistic attack vector - sending a userauth success message to the target SSH server will cause an unpatched server to provide the attacker login access as though they had successfully authenticated, when in reality no authentication had even been performed.

Read the article below for more information:

I would like to preface this post by saying that implementing any attack mentioned forthwith against any entity that is not yourself (on your own network and targeting your own devices) or anyone for whom you do not have explicit, written, informed consent is an ethical violation, and potentially, a criminal act. Don’t try it.

One common threat to internet-exposed entities is the denial of service attack. Quite often, this is accomplished by sending an overwhelming load of traffic to a singular webserver, and by using a distributed network of malware-infected devices in the so-called Internet of Things. However, other attack vectors exist, and I like to talk a little bit about one of these.

The slow loris is a protocol exploit that can be used to attack certain http webservers which doesn’t require all that much bandwidth to execute. Simply put, it takes advantages of the fact that some webservers a) use a blocking connection algorithm and b) assign threads for pending connections. One computer can send dozens of partial connection requests, and then prevent them from timing out by periodically sending additional packets after that initial partial request. It affects Apache and other server solutions that have similar implementation, but it notably does not affect nginx, which does not use a blocking algorithm according to the article/post linked below. One attacker targeting a machine that’s not up-to-date could totally seize up the webserver, preventing valid connection attempts from landing.

Slow loris attacks are preventable, through patches, updates, or modules provided by developers of a given server solution (Apache provides a module to prevent slow loris). They’re also mitigable through actual OS configuration, such as proper use of Linux’ iptables rules to prevent abuse from specific hosts as identified by malformed traffic or excessive connection requests, and by configuring the server to strictly discard partial requests. See the below attached Computerphile video, as well as a related post, for more material.

Video: https://www.youtube.com/watch?v=XiFkyR35v2Y

According to an entry last year in May from Business Insider, Windows XP saturates approximately 7% of the total PC operating system market. At EOL (and having been there for some time now), there is no justifiable reason to continue the use of Windows XP; it’s not receiving any official backports, software development has all but ceased, and security updates are no longer being provided by Microsoft, ergo issues with Windows that Microsoft may patch out in 7’s extended support phase or in 10’s active support phase have the potential to be glaring issues in XP, along with XP’s own quirks and vulnerabilities that are still now coming to surface. This becomes an issue when you consider that critical- & very important-level components are still running what is now an antiquated operating system on an antiquated architecture, notable example being most of the elevator systems produced and operated in the United States – these often use a microcontroller to operate the elevator, and a control interface (running Windows XP) enforcing the selected access control mode, more on this in a later post.

Bearing all this in mind, let’s change gears for a second. Process-hollowing is a concern that Microsoft considers to be ‘addressed.’ That is to say, a user running normal security precautions (strong passwords on an up-to-date system, running Defender or some other antivirus, with an active firewall) can expect to be minimally vulnerable to known methods of process-hollowing, a malware tactic that injects arbitrary instructions into executable memory of an existing process. Some attack vectors, Microsoft has indeed patched – in computers that aren’t End-Of-Life. For instance, XP is, and will always officially be, one-hundred percent vulnerable to the relatively recent exploits, Meltdown and Spectre. This also goes for the “atom-bombing” attack, relevant links included below.

Ultimately, what I want to convey in this post is that updates are important. Entire industrial sectors think that it’s completely acceptable to operate Windows XP, run the same utilities they’ve always run, on the principle that “it just works” and that it’s easier to use antiquated software than to update to a modern OS and architecture. If you’re going to use Windows, use 7 or 10 in your business. If you’re going to use Linux, use one of Canonical’s LTS solutions, or RHEL, or any other of myriad distributions with active support, but just make sure that your distributor stays up-to-date with their packages, and make sure you keep on top of your updates.

Atom Bombing: https://blog.ensilo.com/atombombing-brand-new-code-injection-for-windows

Computer and information security entails more than what you can accomplish software-side, more than what you can even accomplish with your computer hardware. In a world where corporate espionage is a fairly prevalent practice and information leaks are everywhere, you also need to put a little bit of thought into your physical security schema.

Are your doors as secure as you think they are? Ask yourself this. Is there any sort of a gap on the sides or bottom of your door? Does your ‘secure’ door have weatherproofing? Was your door installed without security pins, or with pins exposed on the ‘secured’ side of your door? Do you use an infrared monitor to open the unsecured side of your door in the case of egress? Do you use a door plate to prevent people from ‘carding’ your door open? If you answered yes to any of these questions, you may want to see the talk linked below. It’s a little unconventional, but it bears some good points along the lines of protecting your computers by protecting the physical building it’s stored in; when a determined attacker manages to physically compromise a facility, there’s a strong potential for data theft, data loss, systems sabotage, and acts of espionage, and the attacker’s toolset doesn’t even necessitate more than a few miscellaneous, easily-obtainable hand tools and a confident personal air. With proper care and preparation, it’s easy enough to harden a facility against most easily-exploitable physical entry vectors, but it takes a certain level of unorthodox thinking or scholarly research to actually identify the vulnerabilities in the first place - who would think of opening a locked push-bar or push-paddle door by bending a wire and slipping it through the weatherproofing to pull on the door? And who would think that the fix was so simple as deadbolting the door when the building has zero occupancy (e.g. at night, depending on the facility)? Furthermore, for warding against a similar attack vector, there exists the under-door gapless configuration; they’re slightly more expensive to install than a standard door, but in context they’re only truly important on an external access layer; perhaps not the outward-facing public doors, but perhaps with all doors one layer deeper, providing a significant degree of security against under-door attacks on those, and by extension all doorways within the perimeter formed by that layer of doors.

I recommend seeing the full talk, The Search for the Perfect Door, at Shakacon. The YouTube link is provided below.

A huge component of security, in computer and information sciences as much as in other areas, relies heavily upon who is given how much trust. A whole series of cryptographic utilities exist to prove who packaged a piece of software, when, and where (see the OpenPGP web of trust, as well as other signing authority and methods); we all know that we can’t implicitly or even explicitly trust software, and we all know that compilers aren’t perfect. What we may not all be aware of, however, is that we can’t explicitly trust our processors, either. The nature of proprietary development and engineering is such that trade secrets emerge, necessitating some sort of implementation that accounts for its own redactions. Furthermore, branding and competition issues lead to unequal, inequivalent implementation across manufacturers. As attested to in the below listed Black Hat orations, I’d like to point out two security-related issues related to the physical implementations of x86 processors: the x86 instruction set is not fully documented, and in undocumented instructions there exists the possibility of privilege escalation, eavesdropping, and sabotage.

Efforts have been undertaken to algorithmically determine ‘missing’ (unlisted) processor instructions. There exist, in some implementations of the x86 architecture, instructions that can circumvent rings and obtain higher permissions, instructions that will cause the processor to ‘halt and catch fire’ (enter high activity and accept no interrupts), and many more with unknown or no functionality. This is not a concern that has been fully and properly explored, and this is not something that can be easily sidestepped; if you use the x86 architecture, you are at risk of interesting behavior from malformed applications that utilize undocumented bytecode what has, for the most part, remained secure through obscurity (there aren’t really utilities to debug or observe a processor, at least not in the sense that one can debug and observe a piece of running software). There are no perfect solutions, but mitigation steps include adopting the ARM64 instruction set/architecture, which is a highly-documented reduced instruction set.

    I hope you find some interesting reading below in these two papers by one Christopher Domas, and if you only have the time to read one of them, choose Hardware Backdoors in x86 CPUs; Domas builds upon his original talk and goes into greater specificity in the second article.

Breaking the x86 Instruction Set:

https://www.blackhat.com/docs/us-17/thursday/us-17-Domas-Breaking-The-x86-Instruction-Set-wp.pdf

Hardware Backdoors in x86 CPUs:

Last week, I talked a bit about a few Linux security features that come standard with the kernel and with most distributions. This week, I’d like to go a little bit further in-depth about possible security measures with Linux specifically, namely the SELinux system.

SELinux is short for Security-Enhanced Linux, and it is comprised of a series of patches to the Linux kernel working in tandem with a few utilities outside of kernel-space to implement what is known as an MAC (mandatory access control) system, as opposed to Linux’s Unix-descendent DAC (discretionary access control) system.

Under normal, non-SELinux operation, processes are spawned by users, and access is restricted by the use of permission bits; this has the consequence that a malformed application, be it malicious or inadvertent, may have the ability to touch, read, write, or execute other objects owned by the user who spawned the process. This also implies that there is heightened danger in running superuser; an application spawned by root is considered to have elevated privileges and can potentially cause irreparable harm to a system if misused or malformed. However, this can be sidestepped through the use of SELinux, which may be conceptualized (somewhat inaccurately) as a sort of stateful ‘firewall’ between programs. Under SELinux, there’s no true concept of the superuser as implemented in standard Linux, and the entire system and all of its users and objects (files, directories, daemons, user programs) are broken down explicitly, granularly, and individually. The security administrator is enabled to write a policy for their system to the specific requirements of their system, which is used any time an object is accessed, be it for reference, or modification, or for execution. As mentioned in the text for ICS-382, this is an example of an ‘island’-type access control system. Used in conjunction with proper settings for things like ntpd, httpd, dhcpcd, ftpd, sshd, and other network-exposed services, as well as basic measures for information security such as redundant encrypted disks, SELinux can produce one of the most secure operating environments available today.

One important thing to note, however, is that SELinux should not be attempted without first reading the documentation thoroughly, as it is very easy for an inexperienced user to create a system that is inaccessible or that otherwise lacks the security SELinux is designed to provide if the fledgeling administrator does not have a complete understanding of policy-writing and the consequences of access limitation on their machine.