I have one noob question.I tried to exploit shellshock on my Slackware linux server, but after I connect with reverse shell and User Agent I get that I am apache user and apache user don't have too much privileges, so I think there is no way to anyone can get access to root account or to do anything wrong on system. Am I right?

some tries

  • Is it a default install of Slackware? And which version of it? Can you tell if you're using SELinux and whose SELinux policy you use? If yes, can you paste the SELinux domain of your Apache and your Apache TE policy? Sep 27 '14 at 14:12
  • Yes it's default instalation, ver 13.1, don't use selinux...
    – Vladimir
    Sep 27 '14 at 15:14

You are right that you gain access to the UID of the process/script you exploited. In the case of the Apache identity with no mandatory access control and no proper separation of developer and apache roles, you can:

  • destroy or deface the websites run by your Apache
  • change websites' code to leak all the user database at a fixed URL that you can then consult
  • add malicious scripts to pages to serve malware to the site's visitors
  • host your own websites (e.g., to grow the command and control infrastructure of your existing botnet)

With a basic mandatory access control (e.g., SELinux/AppArmor) policy that does not separate the Apache admin role from the actual process (typically, which allows the domain that runs the actual Apache binary to write to apache_*_t files) and with a read-only access to web code you can probably:

And probably a couple of other things... Here you don't care at all about the OS in itself, you care about the ability ot host content, steal data and alter existing and visited websites. The security you retain post-exploit really depends on how well you compartmentalised your OS in the first place.

  • Steve thanks for answer it is default conciguration of Slacware linux, 13.1 v and no selinux. And I am interste how is posibble to do that much without root access, when I even don't have premission to list /home/username folder...And apache belongs to nobady group?
    – Vladimir
    Sep 27 '14 at 15:15
  • I would expect an apache account to have no home directory, which is why the third command failed. The first fails because apache cannot read /etc/shadow, only root can. You should be able to touch things in /var/www if left with the default permissions (assuming umask 022) and owned by apache rather than another account. I don't use Slackware but you can look up /etc/group to find which group apache belongs to, /etc/passwd to verify it has no home and shell and finally ls -l /var/www to verify whether apache can read your websites' files. Sep 28 '14 at 2:34
  • It's all default settings apache belong to group nobady... It's possible to read from /var/www but on most hosts apache files are here: /home/user .
    – Vladimir
    Sep 28 '14 at 17:43

They may only have access to the Apache user account, but there may be another exploit or misconfiguration on your particular system that would enable an attacker to elevate their privileges to those of root.

Local privilege escalation happens when one user acquires the system rights of another user. Network intruders have many techniques for increasing privileges once they have gained a foothold on a system. The initial intrusion could start from anywhere. A guest account? A local user who has carelessly written a username and password on a Post It note? Everyday users typically operate at a relatively low privilege level – specifically to prevent someone who obtains their credentials from gaining control of the system. Once inside, the intruder employs privilege escalation techniques to increase the level of control over the system.

For example, simply running the Linux Kernel <= 2.6.36-rc8 - RDS Protocol Local Privilege Escalation exploit will elevate the current shell to root on a vulnerable kernel:

[limited@fedora ~]$ whoami
[limited@fedora ~]$ id
uid=500(limited) gid=500(limited) groups=500(limited)

[limited@fedora ~]$ ./linux-rds-exploit 
[*] Linux kernel >= 2.6.30 RDS socket exploit
[*] by Dan Rosenberg
[*] Resolving kernel addresses...
 [+] Resolved rds_proto_ops to 0xe125ca1c
 [+] Resolved rds_ioctl to 0xe124706a
 [+] Resolved commit_creds to 0xc0444f65
 [+] Resolved prepare_kernel_cred to 0xc0444dc6
[*] Overwriting function pointer...
[*] Triggering payload...
[*] Restoring function pointer...
[*] Got root!
sh-4.0# whoami
  • Could you show me some example?
    – Vladimir
    Sep 28 '14 at 17:37
  • @user56215: Example added. Sep 29 '14 at 10:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.