Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in an operating system or software application to gain elevated access to resources that are normally protected from an application or user. The result is that an application with more privileges than intended by the application developer or system administrator can perform unauthorized actions.
Privilege escalation means a user receives privileges they are not entitled to. These privileges can be used to delete files, view private information, or install unwanted programs such as viruses. It usually occurs when a system has a bug that allows security to be bypassed or, alternatively, has flawed design assumptions about how it will be used. Privilege escalation occurs in two forms:
This type of privilege escalation occurs when the user or process is able to obtain a higher level of access than an administrator or system developer intended, possibly by performing kernel-level operations.
Examples of vertical privilege escalation
In some cases a high-privilege application assumes that it will only be provided with input that matches its interface specification, and doesn't validate the input. An attacker may then be able to exploit this assumption so that unauthorized code is run with the application's privileges:
A jailbreak is the act or tool used to perform the act of breaking out of a chroot or jail in UNIX-like operating systems or bypassing digital rights management (DRM).
In the former case, it allows the user to see files outside of the filesystem that the administrator intends to make available to the application or user in question. In the context of DRM, this allows the user to run arbitrarily defined code on devices with DRM as well as break out of chroot-like restrictions. The term originated with the iPhone/iOS jailbreaking community and has also been used as a term for PlayStation Portable hacking; these devices have repeatedly been subject to jailbreaks, allowing the execution of arbitrary code, and sometimes have had those jailbreaks disabled by vendor updates.
iOS systems including the iPhone, iPad, and iPod touch have been subject to iOS jailbreaking efforts since they were released, and continuing with each firmware update. iOS jailbreaking tools include the option to install Cydia, a third-party alternative to the App Store, as a way to find and install system tweaks and binaries. To prevent iOS jailbreaking, Apple has made the device boot ROM execute checks for SHSH blobs in order to disallow uploads of custom kernels and prevent software downgrades to earlier, jailbreakable firmwares. In an "untethered" jailbreak, the iBoot environment is changed to execute a boot ROM exploit and allow submission of a patched low level bootloader or hack the kernel to submit the jailbroken kernel after the SHSH check.
A similar method of jailbreaking exists for S60 Platform smartphones, which involves installing softmod-style patches which involves patching certain ROM files while loaded in RAM or edited firmware (similar to the M33 hacked firmware used for the PlayStation Portable) to circumvent restrictions on unsigned code. Nokia has since issued updates to curb unauthorised jailbreaking, in a manner similar to Apple.
Operating systems and users can use the following strategies to reduce the risk of privilege escalation:
Horizontal privilege escalation occurs when an application allows the attacker to gain access to resources which normally would have been protected from an application or user. The result is that the application performs actions with the same but different security context than intended by the application developer or system administrator; this is effectively a limited form of privilege escalation (specifically, the unauthorized assumption of the capability of impersonating other users).
Examples of horizontal privilege escalation
This problem often occurs in web applications. Consider the following example:
This malicious activity may be possible due to common web application weaknesses or vulnerabilities. Potential web application vulnerabilities or situations that may lead to this condition include:
Review those logs
Time-consuming, tedious, and absolutely necessary for the health of your network: review your log files. Once you understand what "normal" looks like for your network, you're more likely to spot dangerous abnormalities.
What should you look for? In two words: weird stuff. Examples: You know Bob is on vacation at Disney World, and his laptop is sitting in your office, but someone keeps logging into your network as Bob. Time to investigate. If, normally, your Web server can run six weeks at a time without requiring a reboot, but it rebooted itself three times last night, some attacker may be trying to perfect his buffer overflow attack against it. If your database server is locked in a closet in your server farm but the log files report a console login attempt on that server (which has no keyboard), investigate further. Get the idea?
Keep up-to-date on patches
Another painful but necessary task. We're surprised to see the Frethem virus spreading as we write this, because it works primarily on Internet Explorer systems that have not been updated in over a year. A diligent sys admin may patch daily. Lately, advisories about buffer overflows are being reported in the popular press. You can't assume "no one knows about them." Plug all known holes.
We have often advised in LiveSecurity articles, "Use strong passwords." The problem with passwords that are cryptographically strong (e.g., "1@3gg]+nP915f~") is that no one can remember them, and they're hard to type. A nice balance between that and a too-easy password (e.g., "bob") is the passphrase. Try using bits of poetry, lines from plays or movies, anything lengthy but memorable. In Star Wars: A New Hope, an embarrassed Han Solo tells his mocking sidekick Chewbacca, "Laugh it up, fuzzball." Modified slightly to "L4ugh it up, Fu22ball!" you have a strong passphrase, hard for an attacker to brute force or guess, but easy for you to live with. Pick your own favorite. Just don't read it from anything hanging near your workstation.
Manage settings aggressively
Sure, it's easier to set your firewall to permit "Any" to "all." But that's not secure. Work out a security policy that grants employees the minimum amount of access they need to do their jobs. Then set your routers, switches, and firewalls to enforce the policy. While you're at it, consider installing interdepartmental firewalls: that way, if an attacker breaks in somewhere, you've limited the damage to a smaller network segment.
Further countermeasures are really up to application developers. Buffer overflows don't succeed in a well-written program. But you can't do a lot about that right now. What you can do is make sure your people use strong credentials, then protect those credentials.
Please register yourself and will keep you informed as soon as we update collection of attacker controllers or payloads or chunk of data such as Injections [SQL, XML, XPATH, LDAP], Cross-site scripting [HTML4, HTML5], Inclusions [Remote, Local], Path traversal, Commands execution and many more action utilities.