Jump to content

fapafap

Active Members
  • Posts

    12
  • Joined

  • Last visited

Posts posted by fapafap

  1. Um, if something has already been exploited, the more than likely, there is an exploit out there with POC code. Not to be all script kiddie, but check http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=&filter_exploit_text=&filter_author=&filter_platform=0&filter_type=0&filter_lang_id=0&filter_port=&filter_osvdb=&filter_cve=2011-1938

    I think what they've explained is the crash, how to trigger it manually, server side, but they state that "might allow context-dependent attackers to execute arbitrary code via a long pathname for a UNIX socket" meaning you would probably have to work out the remote end of that exploit.

    Ah ok thanks, so I was on the right track then in thinking it looked like a local exploit, wish 'other' people would just spit it out :P

  2. damn, I think that might ruin my chances of getting an answer here, damn you for replying first! ;) (As a side note- isn't the autopwn angle where Hak5 shines the most, so why not the forum follow same basis? :()

    http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-1938 thats another link to the vuln. And I understand how the exploit works, but it seems to me to be a local exploit...?

  3. Hello, trying to integrate nexpose with metasploite but getting an error after nexpose scan:

    Connecting to Nexpose instance at localhost:3780 with username root...

    msf > nexpose_scan -x 192.168.0.6

    [*] Scanning 1 addresses with template pentest-audit in sets of 32

    [-] Error while running command nexpose_scan: NexposeAPI: Action failed: Nexpose service is not available

    Call stack:

    /opt/framework/msf3/lib/rapid7/nexpose.rb:211:in `execute'

    /opt/framework/msf3/lib/rapid7/nexpose.rb:654:in `execute'

    /opt/framework/msf3/lib/rapid7/nexpose.rb:265:in `scan_statistics'

    /opt/framework/msf3/plugins/nexpose.rb:532:in `cmd_nexpose_scan'

    /opt/framework/msf3/lib/rex/ui/text/dispatcher_shell.rb:380:in `run_command'

    /opt/framework/msf3/lib/rex/ui/text/dispatcher_shell.rb:342:in `block in run_single'

    /opt/framework/msf3/lib/rex/ui/text/dispatcher_shell.rb:336:in `each'

    /opt/framework/msf3/lib/rex/ui/text/dispatcher_shell.rb:336:in `run_single'

    /opt/framework/msf3/lib/rex/ui/text/shell.rb:199:in `run'

    /opt/framework/msf3/msfconsole:134:in `<main>'

    However, in console the following was displayed which showed the scan worked(extract):

    t)

    Nexpose 2012-01-01T19:01:07 [192.168.0.6] Closing service: CifsDomain[192.168.0.6:445] (source: CIFS-NT-0002)

    Nexpose 2012-01-01T19:01:07 [192.168.0.6] Closing service: CifsConnection[METASPLOITABLE/192.168.0.6:445] (source: CIFS-NT-0001)

    Scan 2012-01-01T19:21:04 [site: Metasploit-1325443802] Scan [Metasploit-1325443802] completed in 30 minutes 46 seconds

    Nexpose 2012-01-01T19:21:08 WARNING: CMS Old Gen memory usage at 88% capacity (init = 260046848(253952K) used = 685582216(669513K) committed = 771751936(753664K) max = 771751936(753664K))

    Scan 2012-01-01T19:21:19 [site: Metasploit-1325443802] Scan [Metasploit-1325443802] discovered 1 live devices, 73 vulnerabilities.

    Nexpose 2012-01-01T19:21:19 WARNING: CMS Old Gen memory usage at 88% capacity (init = 260046848(253952K) used = 681920544(665938K) committed = 771751936(753664K) max = 771751936(753664K))

    Nexpose 2012-01-01T19:21:21 Attempting to stop most recent report generation activity (650.3 MB\736 MB)

    Nexpose 2012-01-01T19:21:38 WARNING: CMS Old Gen memory usage at 88% capacity (init = 260046848(253952K) used = 681660504(665684K) committed = 771751936(753664K) max = 771751936(753664K))

    Nexpose 2012-01-01T19:21:38 Attempting to stop most recent report generation activity (650.1 MB\736 MB)

    Nexpose 2012-01-01T19:21:40 Attempting to stop most recent report generation activity (650.1 MB\736 MB)

    ScanMgr 2012-01-01T19:21:59 Scan default:3 is being stopped.

    ScanIntegrat2012-01-01T19:22:36 Correlating asset information for scan ID default:3

    ScanIntegrat2012-01-01T19:22:50 Performing data transformations for scan ID default:3

    ScanIntegrat2012-01-01T19:22:56 Updating synopsis for scan ID 3

    ScanIntegrat2012-01-01T19:23:09 Full-text indexing device data for scan ID 3

    ScanIntegrat2012-01-01T19:23:11 Completed integration of results for scan ID default:3

    WebContentGe2012-01-01T19:23:22 Queueing web content generation for scan default:3...

    WebContentGe2012-01-01T19:23:35 Finished queueing web content generation for scan default:3.

    WebContentGe2012-01-01T19:23:35 Generating web content for site default:3...

    WebContentGe2012-01-01T19:24:49 Finished generating web content for site default:3

    ReportManage2012-01-01T19:24:57 Generating report: Metasploit Export 1325443802

    Nexpose 2012-01-01T19:24:57 NeXposeSimpleXMLReportExporter exporting to /opt/rapid7/nexpose/nsc/htroot/reports/00000003/00000003

    I know its working then, but not sure why the error? I am running Backtrack5r1. The command sequence went:

    In metasploit:

    msf > load nexpose

    msf > nexpose_connect myusername:mypassword@localhost:port

    msf > nexpose_scan -x 192.168.0.6 - which is the VM I have metasploitable setup on. Nmap scan on this host shows that its reacheable.

  4. Disclaimer: I am not a pentester, I don't claim to know everything, and have no real world experience breaking into and rooting others servers, but I know enough to know I don't know everything and enough that I keep myself out of trouble.

    If you haven't gained root, then no, you probably haven't exhausted all resources. Yet... Just depends on your knowledge and skill set. You could look at the drupal installation for the config file, find the database user and password, upload a php script to then dump the database and hashes to your browser, crack the passwords, look for admin email in drupal, then either crack the hash, or if too secure(might be salted, although you should be able to find the salt as well to use with online crackers) just spear phish the admin with some email to target them, hope you can social engineer them into clicking something, then compromise the admin, do more research from there. If you can look at the access logs, you can see who(by IP address, browser info, OS, etc) and what they are accessing, like specific pages - logging into admin only areas.

    I would say nothing is impossible, just a matter of whether or not you've tried things that no one else has thought of or done more recon to know your targets. I'm not a pentester, and I don't even know how to use half the tools installed in backtrack, nor do I hardly ever use it other than testing in VM's at home(something I really need to use more). Most vulns I've found have been from just poking around client side in the browser and working from there to see what I can find(dumping databases, persistent xss, read and write to the web server, ftp, ssh, etc) and if I find something I can get into or vulns that could take down the sites, I generally contact the admin and let them know what flaws I've found. Sometimes, the servers are already compromised by someone else, and its a matter of finding their left overs and then getting in through the backdoor they left in place.

    Thanks for your insights. I found a suid'd binary this afternoon which is root/root ------other:rwx :) I feel the net is closing in tonight! Thanks again.

  5. Whatever you do, obviously, is on you and this is all for educational purposes. It kind of goes without saying, we don't condone hacking machines that aren't your own, so I won't preach too much, but its all on you if anything happens.

    If the context of everything is as www-data, then you pretty much only have control of the web site and where the files are stored for the www area. This could be leveraged to gain root access if you can somehow get the admin passwords from drupal(if they are the same as for the servers root as well, which most likely won't be the same). Although, if PHP can issue SYSTEM level SHELL commands, you might be able to just create a new root user from there. If not, try to do a directory traversal to see if you can go higher than the home directory, or even see other directories by calling them manually if navigation doesn't work by going up one level, like calling / or /var /bin /etc directly. Most of these directories should be off limits, but if one of them is readable like say /etc might be able to dump the plain text of /etc/passwd (without hashses) to get a list of user names to brute force. All in how you want to work it. Even issuing shell commands, like uname -a to get the kernel info in use, search for installed software and their version numbers, all to see if there are exploits for them against the server itself.

    Thanks for replying- n.b noted disclaimer, all this is for learning, and of course anyone hacking does so at their own risk.

    I traversed right back to root directory- most directories are readable, none lower than the var/www are writeable. I did a search for all SUID programs and they are all in user/bin which are root group. The etc/password file is off limits, I can call some restricted commands such as uname -a, and safe mode is off. I haven't found anything other than an open var/mail file which give me insight into the admins username, but agreed its probably not going to be the same username/password for the FTP/SSH- just based on what I have leared about drupal so far since that installation comes later than setting up your apache etc.. Have we exhausted all of the possibilities?

  6. If you have read and write access to any part of the web side, and say they have PHP or MySQL installed, you could upload a reverse shell to peer into the rest of the server, possibly gain root access, depending on how the Host set up the web server, and what user level things run at. SQLi is also a target, since gaining access to the database, could potentially yield admin passwords for the site, then lead to further login and escalation of privileges through upload of tools to root the server. Mind you, all of this is detectable, but depending on how they secure the site, you could also clean up after yourself, wipe syslogs, access logs, backdoor the server with new accounts and chattr your files so they can't be removed even as root unless a smart enough admin bothers to lsattr the files to see what their attributes are.

    Hi already have a shell up and it is under wwwdata user. Permissions all seem to be standard throughout the server. There are no SQLi vulns as far as i am aware- it is a drupal based site fully patched up.

  7. Hi I am interested in learning more about the following suggestions:

    3) Just like an Exploitable Kernel, an exploitable suid'd program could contain vulnerabilities/security loopholes within its source code thus allowing an attack to take advantage of it, and gaining unauthorized access to a system.

    What I have read so far on this (thank you for bringing me onto it!) is that this is really only ever going to be a realistic opportunity where you are in a bulky corporate or personal network where third party programs have dropped miscrient SUID'd programs unchecked by admins- the standard linux distro apps are clearly going to be 99% bug free.

    For my purposes of hacking the server a website is hosted on makes this not really a high chance of success, and thats before getting into the actual shell coding!

    4) Writable home directories, if your system or webserver has a writable directory, anyone can save or even execute malicious files, which could potentially give them access to a system. Make sure home directories only have read or no access at all to the public. This will improve the security of the system as well.

    Lets say I have access to: /var/www/www.website.com/htdocs/

    Can you elaborate from there? How could malicious files give root access from here?

  8. Yes because thats hacking now isn't it ;)

    -------

    If you are on the out side looking in with no way what so ever to login to the system, then the first thing that i would normally do is run a port scan against the system in order to generate a list of open ports and what services are listening on these ports. From that information one can then do a few searches in some public db for known exploits. If nothing comes up then you get a copy of one of the services that is running on the system and analyze the program in order to find a bug that can be exploited, once you have found a bug the next step would be to write an exploit for it.

    Hi and thanks for your input too.

  9. Things that could give an attacker root on a system (not an exhaustive list)

    • running your web server as the root user
    • exploitable kernel
    • exploitable suid'd program
    • writeable home directories (if they can edit your files they can set up trojan versions of su or sudo to grab passwords)
    • patience, if they wait long enough an exploit may be found that would give them root

    Hi thanks for your reply, I have googled around the topics you have mentioned but cant find any decent information- can you elaborate at all please mate?

  10. first post here.

    After getting a web-shell up on your target website the next step is to try and root the box and then backdoor it. The only methods I seem to be able to find so far are to search for a local kernel exploit and run it through a backconnection. When your target has a 2011 kernel thats obviously not an option (to 99% of us), but nobody can tell me so far what the alternative course of action (if any) is to still manage to root it.

    I haven't left this topic alone despite not getting any information on it because I think that there must be other ways to do this, after you have access to the box via the shell and can potentially upload/run malware which surely could include things like rootkits which could circumvent kernel level authentication, or key loggers, or whatever? Ok enough newbie notions, please any knowledgeable hackers enlighten me!

×
×
  • Create New...