How do I: hack (nearly) any OS?
(Another random thing from the same zine)
First we must define what it means to hack an OS.
I am sure many of you conjure up images of Trinity gaining root access via an SSHD exploit, or perhaps of the NetBus GUI after connecting to an "0wned" Win98 box, or perhaps a directory listing in your web browser after unicoding an IIS box. Yes all of these are different hacks, though they are not actually OS hacks. Why are these hacks not OS hacks? In the first, Trinity compromises the SSHD and not the OS, the OS acts as it should in given the SSHD root access, which it needs to bind to port 22. The Win98 architecture is designed without a trusted computing base, as such it cannot separate objects and subjects so it is working well within its design to give the NetBus server and client full control over the system. The IIS attack is the same, IIS has been compromised to act in a new way, but still well within the OS's intended scope, as with the SSHD attack you will note that the IIS process gains no extra privileges or permissions beyond what the OS has already granted to it.
So, what is an OS hack?
An OS hack would be a method of forcing or tricking the OS into doing something it wasn't designed or configured to do. This could be attacking the kernel directly to elevate your privileges or even simply gaining access to an object that the OS has not granted access to. The former has been covered a zillion times over, all about how to "root" something. That latter however is very frequently glossed over despite the fact that it is mathematically infeasible to accurately predict rights propagations in your standard single level system (NT, UN*X, Linux, etc). The Harrison, Ruzzo, and Ullman (HRU) model from 1976 (you'd think this would be fixed by now) discusses how read/write permissions are transitive for example:
HRU Path:
if X cannot write to Z
and X can read write to Y
and if Y can read write to Z
then X can write to Z
The same works for read from, this is a clear case where standard rwx controls will fail and allow an attacker to bypass the security policy. Rights propagation of this type, as I stated above is infeasible, if not impossible to predict especially in an environment where subjects are allowed to set the permissions of object they own. Additionally the UN*X protection model requires multiple security operations per command, so individual grants cannot be approved. The end result? The OS cannot effectively protect anything! Remember, it isn't always needed to "root" a system, sometimes gaining read access to something you shouldn't have read access to can be enough to cost a company millions of dollars.
A simple solution to this problem was proposed by Bell and LaPadula as (amazingly enough) the Bell-LaPadula Confidentiality Model (BLCM). The BLCM uses confidentiality labels to divide the system in a hierarchical manner eg. "Unclassified", "Classified", "Confidential", "Secret", "Top Secret", and "If we even told you the name of this level we'd have to kill you". The way these levels work is quite simple and has been mathematically proven to never disclose anything they oughtn't, thus the issue of rights propagation is greatly cured. (Although it lends rise to other problems not covered by this text) The BLCM has two rules:
S=Subject
O=Object
L=Level
S(L) can only write to O(>=L)
S(L) can only read from O(<=L)
In short subjects cannot write to objects below their level (*-property) and may not read objects above their own level (simple security property). This ensures that data only aggregates up, never down so confidentiality is maintained. How then is it possible to hack this type of system? To make data flow down rather than up?
If the security policy won't let you do what you want, go around it.
"A covert channel is any communication channel that can be exploited by a process to transfer information in a manner that violates the system's security policy. There are two types of covert channels: storage channels and timing channels. Covert storage channels include all vehicles that would allow the direct or indirect writing of a storage location by one process and the direct or indirect reading of it by another. Covert timing channels include all vehicles that would allow one process to signal information to another process by modulating its own use of system resources in such a way that the change in response time observed by the second process would provide information."
- DOD-STD-5200.28
And to think, some of you still think the Orange book is useless. (""covert timing channels" linux" returns 41 results on Google, most are references to the orange book glossary or talk about networking, heh.)
But how do we use a covert channel to defeat the BLCM? Remember, the BCLM applies to everything on the system, so your devices like the printer, untrusted net connection, and floppy drive will all be the lowest security levels, thus preventing high security data from being removed as you cannot write to these devices (*-property). Robert Mullen came up with perhaps the first example of a good use of a covert timing channel attack way back in 1976 (Gotta love security issues from before I was born that still have yet to be resolved heh) in a Multics lab at MIT. With a user of level "Unclassified" he wrote a trojan horse process up to level "Top Secret." (as allowed by the *-property) This trojan would then read or not read from a predefined set of pages in a public library file, the receiver process running at the level of "Unclassified" read from the same predefined set of pages and determined if they were already in the core. Timing the page reads allowed the processes to communicate in a manner similar to Morse Code. The data is written down and may now be removed from the system. Keep in mind, this can be done both as a trojan horse or as an insider hack. As good security minded folk, we must never forget the inside job.
Now again we have a situation where two resources sharing just read access to a single resource allows the propagation of rights. Could it possibly be worse? It could!
Covert storage attacks work in an even more basic transfer of data via predictable changes in an area of storage, by it memory used by a particular application, available sectors on a particular drive, and changes in swap space are all examples. I don't think a more in-depth description of this type of attack is required as I suspect its most basic forms are quite obvious.
I have seen many of various types (NT, 2k, Linux, OBSD, Trusted Solaris, Tru64 to name a few) all owned by covert channel attacks. These attacks of course require near minimal access to two accounts on the system. This is not as complicated as it might sound at first. Start with a low level legit/hacked account than using the issues presented by the HRU model above either by an access hack (following the HRU path) or by using one of the services running on the system (which is likely and you are likely to have some level of access to them) these services tend to spend at least some time as an administrative level user and from there you should be back in more familiar territory. Also, do not be fooled by root's having access to everything, this doesn't follow the HRU Path, root needs to have explicit rights, not implied root rights. Once you have your second account it is a trivial matter to use the covert storage channel to transfer data as you please. This is most useful against servers with sandboxing and process protection (HYDRA and BRICK Server come to mind, but to be fair, BRICK server only claims to protect against "naïve attacks"-http://www.thirdpig.com/security.htm ) and is frequently overkill on standard systems and only most useful if you wish to bypass various types of auditing or to monitor user sessions in real time.
As for code examples, heh good luck! If you had these would you give them up? (But seriously, the application will vary so widely from need to need that packaged code is gonna be worthless)
catch
