Robotic Riley

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.

MS Windows 10 has been a little bit fritzy recently. Actually, more than a little bit - Microsoft seems to have gotten into the habit of publishing updates and patches that end up breaking things in strange ways, and the two specific updates that I’d like to talk about today are the KB4462919 and the Insider Build 18277 updates.

It’s important to understand that computer security is a multifaceted construct; on the one hand, there are very real threats perpetrated by cyber-enabled individuals, organizations, and world governments whose onus may be averted through proper comp/info-sec ‘hygiene,’ active attempts to induce unwanted behavior and steal or corrupt information, but on the other hand security is also related to accessibility. Security can be related to the amount of time it takes to perform a given function on the user level, because, to quote an old Capitalist adage, “time is money.” If you have users who try, and are unable, to complete tasks in a timely fashion, you are losing capital in the form of morale as well as in the form of lost productivity, and one great way to prevent users from completing tasks in a timely fashion is to change things up on them unnecessarily. Update KB4462919 does exactly that, rendering Windows 10 utterly amnesic over file associations. It removes the capability to set which programs deal with which filetypes, forgets any previous such settings, and is a general nuisance. Most users of Windows expect to be able to double-click on a file and have it open with the proper utility mostly “automagically;” with this past update, when they try to do just that, the wrong utilities are opening, costing an ever-accumulating amount of time bit by tiny bit as every individual user and workstation running that (mandatory and automatically-installed) update are required to manually open the proper program and manually select required files.

Speaking of changing things up on users unexpectedly, that’s also exactly what Insider Build 18277 does. It’s causing Windows 10 Professional machines to downgrade themselves to Home Edition. Security here is impacted through lost functionality; Windows 10 Home artificially limits the effectiveness of Windows 10 as compared to Windows 10 Professional, leading to the conclusion that affected individuals have lost the extra functionality that they had paid extra for. MS has stated that this will be automatically fixed for affected individuals, and that the problem was related to their authentication servers. I say that MS has violated one of the core principles of computer security, in that they have caused unnecessary downtime with no notice and no recourse for individuals that have licensed with MS. It’s worth noting to say that the Insider Builds are opt-in, and there are disclaimers given to users running them, so normal users should not be affected by this issue.

See the three articles below for more information: top one is from HowToGeek on KB4462919 and bottom two are The Register and Forbes reporting on Insider Edition 18277.

https://www.howtogeek.com/fyi/microsoft-broke-windows-10s-file-associations-with-a-botched-update/

https://www.theregister.co.uk/2018/11/08/windows_10_activation/

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.

Today, I´d like to talk about some security features that either come standard with the Linux kernel, or can be compiled in as desired.

First on the list is the use of discretionary access controls. In Linux, this is handled through the use of users, groups, and permission bits. With some exceptions (notably NTFS and FAT), Linux-supported filesystems allow meta-information to be prepended to file entries that denote who can do what with a given file or directory, and this is represented by the aforementioned permission bits; any file can be specified as readable, writable, or executable (or any combination of the three) to three groups - the owner of the file, members of the single group mentioned in the file’s permissions, and any user of the system at all. This model of access control enables a file to enforce (through kernel-defined policy and the filesystem driver itself) exactly how visible and ‘touchable’ it is to anyone sharing a system. The notable exception to file access controls is the superuser; while ordinarily the owner of a file has powers over the permission bits of a file they own, the superuser in most standard Linux control models is empowered with unfettered access to the system and can ignore, at discretion, permission requirements. The superuser can modify any file, including that file’s permissions, regardless of user or group ownership, which is more-or-less necessary to maintain a system.

The second thing I’d like to mention is the netfilter framework, or more specifically the iptables system. Iptables’ game is packet filtering and manipulation at specific points in their routing, enabling a software firewall of sorts (although iptables can do more than just function as a firewall, but that’s outside of the scope of this post). Iptables compiles into the Linux kernel, and most package-managed distributions provide some variation on arno-iptables-firewall, which is a script that enables an indirect, fairly simple method of leveraging iptables’ firewalling capabilities; traffic is allowed or denied on the basis of predefined allowed ports.

Second-to-last, we have the Linux Unified Key system. LUKS uses a prepended header that contains meta-information about an encrypted volume or block device, and works with the dm-crypt module to provide transparent access to encrypted volumes. LUKS fulfils goals of portability and usability through its use of standardization, backup-able headers, and keyslots. Standardization allows a LUKS device to be used anywhere LUKS is supported, header backups enable volumes what would otherwise be lost to be restored without writing or reading more than a few megabytes of data (likely closer to a few KB), and the use of keyslots allow multiple passhprases and easy passphrase assignment/revocation while isolating the master passphrase of a volume. Using a LUKS device is as easy as decrypting it with your passphrase, which creates a usable virtual block device that manages writing to and reading from the volume, and ‘destroying’ a LUKS device is as easy as writing over the first few megabytes of the physical volume or partition with random values, eradicating the header and rendering it functionally unreadable save to those who would waste too much time on it.

Lastly, I’d like to mention two options that can be specified before compiling a kernel (not necessarily just Linux, on this one), namely strong stack protection (a ‘canary’, if you will) and address space layout randomization. GCC’s stack protection uses a randomly-selected machine word on top of a stack for the purpose of detecting overflow; operations on the stack trigger a comparison between the value of the canary on the stack and the known value of that canary (or in other implementations, the entropy used to generate the canary). If they differ, that is an indication that something has gone wrong. Address space layout randomization accomplishes exactly what it sounds like, with the IEEE stating that “ASLR works by randomizing the offset of key program segments in virtual memory, making it difficult for an attacker to derive the addresses of specific code objects and consequently redirect the control flow to this code.” If you deign to read through the sources, you will see that this is not without its flaws (although unfortunately, the IEEE chooses to paywall).

Sources and Extra Reading:

https://www.linux.com/learn/overview-linux-kernel-security-features

https://www.booleanworld.com/depth-guide-iptables-linux-firewall/

https://gitlab.com/cryptsetup/cryptsetup

https://wiki.osdev.org/Stack_Smashing_Protector

There can be a some amount of concern over system-affecting actions the repercussions of which are not known at start time. A prime example of this is the act of running executables found online; another is testing code that could have uncertain effects on block devices for one reason or another. To address this concern, and several other concerns related to how a computer system is compartmentalized, there exist such software as Xen, KVM, QEMU, Virtualbox, and a whole host of other virtualization managers that enable some pretty interesting behavior on a host machine. Xen, in particular, is an open-source “bare-metal hypervisor” capable of loading kernels, as well as assigning memory, cputime, PCI devices, serial/parallel i/o devices, and other resources (or even emulating nonexistent devices) to the tune of creating virtualized computing environments (in Xen parlance, a domU) that aren’t necessarily aware of the fact they’re being virtualized. This enables very specific applications such as multi-headed computing setups, ultra-dedicated servers, and most importantly to the context of this course an environment where hazardous or malicious code/binaries can, in most cases, be executed with mitigated impact on other, unrelated (unassigned) system resources. As an example, say you have some code that will attempt to indefinitely block the CPU. Run it in a domU with one pinned CPU core, and that program will only indefinitely block the single core it is aware of, leaving the other seven (or however many) free for the virtualized domains to which they were assigned. Part of the reason why Xen is effective for this is because of the specificity with which you can assign devices to it; a logical volume with disk mirroring on the host domain can be given to a child domain in such a way that it transparently acts as a HDD in that domU, effectively rendering the domU incapable of directly accessing any part of your hard drive that you didn’t explicitly give the ability to operate. Further reading is available in the documentation linked below, and I highly recommend anyone with moderate Linux or beginner BSD experience to attempt.