I haven’t had a website since I took my college design portfolio offline years ago. I’m completely new to blogging besides subscribing to a ton of other design blogs. I’ve been wanting to create a design blog for a while now. Finally sat down and did it. I really moved out of my comfort zone with the look of it. Tried to use a color scheme that I can’t use on some of my clients’ boring corporate sites.
I used Expression Engine CMS and updated to the newest version 2.0 yesterday. I really like it. Still getting used to the admin, it’s not as user friendly as I think it should be. Anyway, critique away!
you are running legacy php
disable track method
I didn’t test for it, but, it’s likely this site is vuln to directory traversal vulnerability
you are running legacy php
disable track method I didn’t test for it, but, it’s likely this site is vuln to directory traversal vulnerability |
Would you mind giving me some more details about what all that means? I could pass it to the CMS creators and my host…
I found a few vulnerabilities in the CMS…
1) .
A remote malicious user can redirect users from your website to a specified URL. This problem may assist an attacker to conduct phishing attacks, trojan distribution, spammers…
Here is the vector:
The POST variable RET can been set to
ACT=1&RET=http://&URI=article%2Farticles_posting_in_the_near_future &PRV=111-222-1933email@address.tst&XID=8969a5a65b7cc24bd42122d9 5e9a09be23c57f2e&entry_id=8&site_id=1&name=FOO&ema il=sample%40email%2Etst&url=http%3A%2F%2F&comment= 111-222-1933email@address.tst&submit=Submit
Here is another problem… I did NOT confirm this, but, I suspect with a little messing around, I could find a directory traversal vulnerability:
Note, that link INTENTIONALLY isn’t going to return anything… I don’t want an OT’er grabbing your etc/passwd file…
The implication of this vulnerability is that a remote atacker can download arbitrary files via directory traversal attacks.
This really isn’t a vulnerability per se, but, if it were me I would obsfucate:
It basically just allows someone to garner a better understanding of how your site is architected.
I found a few vulnerabilities in the CMS…
1) . A remote malicious user can redirect users from your website to a specified URL. This problem may assist an attacker to conduct phishing attacks, trojan distribution, spammers… Here is the vector: ACT=1&RET=http://&URI=article%2Farticles_posting_in_the_near_future &PRV=111-222-1933email@address.tst&XID=8969a5a65b7cc24bd42122d9 5e9a09be23c57f2e&entry_id=8&site_id=1&name=FOO&ema il=sample%40email%2Etst&url=http%3A%2F%2F&comment= 111-222-1933email@address.tst&submit=Submit Here is another problem… I did NOT confirm this, but, I suspect with a little messing around, I could find a directory traversal vulnerability: Note, that link INTENTIONALLY isn’t going to return anything… I don’t want an OT’er grabbing your etc/passwd file… The implication of this vulnerability is that a remote atacker can download arbitrary files via directory traversal attacks. This really isn’t a vulnerability per se, but, if it were me I would obsfucate: It basically just allows someone to garner a better understanding of how your site is architected. |
Thanks, I passed this info to the creators of the cms. Are these problems something that is common on other CMS’s? Such as WordPress and Drupal?
The vulnerability associated with the TRACE method is pretty ancient.
I don’t think it’s enabled on your server. I sent the header to your server, and the connection timed out. When I send GET or POST, I get a response right away. So I think your server ungracefully rejects all TRACE requests (ungracefully meaning, it doesn’t respond back denying the request with a 405 Method Not Allowed error; it simply ignores the request entirely).
Anyway, if it is enabled on your server, this is how you would disable it on a shared hosting plan:
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|DEBUG) RewriteRule .* - [F]
But really, the more proper method is to go into the server configuration files and simply set the TraceEnable variable to off. Note that "TRACK" and "DEBUG" are nonstandard alternatives to TRACE. I don’t really know much about either of them, other than they do the same thing TRACE does, and they’re not on all servers since they’re proprietary.
Disabling trace is really just a best practice…
URL redirection isn’t a huge problem – again, more of a best practice…
The directory traversal can lead to compromise of your username / password hash
Hey, do you have a contact name / email / phone for the company? If so, and you can put me in touch with them, I’ll give them a list of the issues, affected parameters, and the correct dir traversal path to etc/passwd
He said he’s using this:
Is it the CMS that is guilty of having a security hole? Or is it an improperly configured web server? I don’t really understand the other vulnerability you mentioned. Can you elaborate on it?
(The TRACE one I understand: basically, it’s a method to debug HTTP requests by having the server send all responses to a third party, which can be maliciously used to trick the server into sending a user’s cookie or some such other thing.)
Any thoughts on the design. layout, etc.?