Module ideas/improvements

[treadie]

I have been thinking a lot about this lately anyway, and then noticed this ticket (#350), and thought I would give you some ideas for for some of the existing modules, its your call whether you take them on-board or not... But before i go on, AWESOME project, good work, and thanks.

File/Path Traversal:

The way i see it, through a path traversal it may be possible to call/display the contents of a file. this should include php, asp, jsp pages etc. without the server executing the content. Currently the 'path traversal' module will not detect file/path traversals that are within the web root. this is more a problem with IIS but can easily include others. for example

ie. /load.asp?file=login.asp will reveal the server side code within login.asp.

I think this is necessary as you will not always be able to detect/call files outside of the web root such as /etc/passwd or boot.ini. I think an easy way to implement this would be to call the landing page (eg index.asp or equivalent) if the response includes ASP code then its vulnerable. This leads me to another module idea below! obviously this will only work for pages with server side code ie. this wont work if the landing page is index.html. other potentially simple ideas.. try and call .htaccess, or web.config etc.

Server Side Code Disclosures:

Pretty simple really, but if any response contains any server side language, this should be flagged. at least for further investigation.

LFI:

maybe covered a bit in the file/path traversal, but to me, the difference between a file/path traversal and an LFI is that in an LFI vulnerability, the sever will execute the code being called. It should easily be possible to test by loading a known page within the vulnerable one.

ie. vulnerable.asp?file=index.asp this will result in the index.asp page being displayed within the vulnerable.asp page. or you could call the same page within itself. ie. vulnerable.asp?file=vulnerable.asp this will obviously result in the same page being displayed twice.

visually this is easy to detect, and i assume it should also be easy to detect using some sort of dynamic page analysis?

RFI:

Currently the RFI module is testing this by requesting a text file stored on github. the problem with this is that it assumes the webserver will have access to the internet. often these days the firewall will be (or at least should be) preventing/restricting internet access for the web server. If this is the case, then Arachni will be unable to test the website for actual RFI vulnerabilities. A simple way to test this is to call the servers own landing page.

ie. /load.asp?file=http://127.0.0.1/index.asp where index.asp is a known file on the server. this would also require the same dynamic page analysis foo that you use for the lfi.

The key difference with RFI is that your able to specify both the protocol and the remote host. even if the host isn't remote (ie. localhost) it should still prove that the page is vulnerable. And for a bit of extra thought processing, whats stopping them from pulling something from another internal server or even using another protocol. this could also be tested by the RFI module

ie. /load.asp?file=smb://127.0.0.1/c$/boot.ini ie. /load.asp?file=//fileshare.acme.local/c$/boot.ini

etc. the list goes on... but i thought i would give you something to think about. Like i said, there are plenty of testing options and i don't think it would be that much overhead to testing. and in my opinion, I would prefer a scan to take a few extra minutes if its going to potentially find a few extra vulns.

Either way, awesome work, I'm a big fan!

P.S. When is the auto update feature coming, i noticed its not a feature request at the moment.

[user021]

Good point about RFI treadie, i knew this module could be improved but wasn't sure how, didn't pay much attention on it mainly because you don't see many of those kind of vulnvs today but even so. Atm im more concerned about File/Path_traversal ...gonna see how Tasos will deal with it.

[Zapotek]

File/Path Traversal:

Well, it's certainly do-able, a bit tricky but do-able.

Server Side Code Disclosures:

Lots of false positives, any page that contains any code snippet will be flagged.

LFI:

That'll take some clever analysis but again, do-able.

RFI

The way I see it, the point of an RFI is to be remote, if loading remote resources has been disabled then there's no RFI.

Auto-updates

I had an idea all worked out but it would be too time consuming to maintain and when you're an 1-person team you need to pick your battles carefully. There is an arachni_web_import executable which imports DB and config from previous packages so that you'll be able to upgrade that way. What I figured I'd do is write a script to just download new packages as they become available, run the arachni_web_import of the new package and rename the old one to <package-name>.bak. It's dumb but it's simple and doesn't require any maintenance. Don't know when I'll do this though, probably with v0.5.

[user021]

<RFI

The way I see it, the point of an RFI is to be remote, if loading remote resources has been disabled then there's no RFI.>

Hmm can't a webserver be configured to allow remote loading of data only from a specific list of servers based on a whitelist ? if so, would make sense trying to include a know page from the audited server since we can't know what the whitelist is, but we could find that out later maybe

[treadie]

The only reason I bring up the RFI checking using a payload of the server itself is because you don't always know what egress ports are going to be open on the firewall. I'm pretty sure that although the application is calling a file that is hosted on the same server, the way in which it is called means that the application will be vulnerable. Its then up to the pentester to figure out a way to take advantage of it remotely.

Tasos is correct though, its not really a RFI when the check is local. maybe this type of check could be included in an LFI module. that way when Arachni detects the LFI, but not an RFI we then need to maybe think about other ways that we could leverage the payload to allow us to connect remotely using different prots/ports.

something to think about though..

Thanks for the update on auto-update etc.

[Zapotek]

By the way, your path traversal suggestion isn't actually a path traversal since it's missing the "traversal" part. It will be covered though by your LFI suggestion. As far as code execution vs no execution, I don't think that it matters, they're both LFIs.

I'll be referencing this and #351 from the relevant commits so that you can check out the progress.

[Zapotek]

I got another brainwave (takes me a while because I'm context switching between this and the on-going work on the DOM/AJAX stuff).

vulnerable.asp?file=index.asp including either index.asp or vulnerable.asp is not actually a vulnerability, it does what it's supposed to do, it's only a vulnerability if you can access a file other than these -- like /etc/passwd or something.

[Zapotek]

Closing this, if there's any discussion about LFI it should take place in #350.

[user021]

Some new about RFI, i was wondering if we could extend the payload diversity, so far we only have 'hTtP://arachni.github.com/arachni/rfi.md5.txt' and 'arachni.github.com/arachni/rfi.md5.txt'

found a server that i am only able to include pages from servs that run php, tested manually since Arachni failed to detect the rfi vuln

[user021]

Or if not, i think the solution would be to include 'http://some-inexistent-website.arachni/some_inexistent_file_with_long_name?%00.jpg"

and look for error messages like

Error message found: Failed opening required 'http://some-inexistent-website.arachni/some_inexistent_file_with_long_name?%00.jpg.php' xistent_file_with_long_name?%00.jpg.php'

that way ...we won't be 100% that is a RFI indeed but it will be less likely to miss something.

[Zapotek]

You mean that it requires the php extension in order to load the file? Yeah I should do that, like with the path_traversal module.

[user021]

Not really, it just need to be PHP and /index like http://www.site.com/index in order to load the content.

[Zapotek]

I lost you, do you mind sending me the details of the vuln privately?

[Zapotek]

The site appends .php to the resource and then uses file_get_contents to load it and then outputs the content. The easiest way to go about it would be to add this file http://arachni.github.com/arachni/rfi.md5.txt.php on the server and job done.

[user021]

Do you think it would make sense to add also .html .htm ? or other extensions

[Zapotek]

Sure why not...couldn't hurt. Ideally, I'd like to add a page that responds to any sort of extension, mod-rewrite should be enough to do the trick.

[Zapotek]

Done: http://tests.arachni-scanner.com/rfi.md5.txt.whatever.blah

[user021]

Let me know when nightfiles will be updated to the new rfi change.

[user021]

Hmm i still don't get detection, i guess is smth wrong with the rewrite rule because http://tests.arachni-scanner.com/rfi.md5.txt.whatever.blah can be included manually

[Zapotek]

Did you try with the latest nightlies? I uploaded them a couple of hours ago.

[Zapotek]

Yep, you're right, looking into it.

[user021]

Yes, they contain the new modifications 'hTtP://tests.arachni-scanner.com/rfi.md5.txt','tests.arachni-scanner.com/rfi.md5.txt'

[Zapotek]

Yeah, it couldn't load the hTtP://tests.arachni-scanner.com/rfi.md5.txt one, I just added http://tests.arachni-scanner.com/rfi.md5.txt which works. Pushing nightlies now.