230 likes | 623 Views
Hardening HTaccess. RSenic RSenic@hackphreak.org. Hacker Jokes (low quality). Hackers do it through the backdoor. Hackers exploit all your holes. Hackers always want to play with your box. Hackers probe all your ports. Hackers always scan you first. Hackers can finger you all night.
E N D
Hardening HTaccess RSenic RSenic@hackphreak.org
Hacker Jokes (low quality) • Hackers do it through the backdoor. • Hackers exploit all your holes. • Hackers always want to play with your box. • Hackers probe all your ports. • Hackers always scan you first. • Hackers can finger you all night.
Thesis • Htaccess can be a robust solution • one time passwords • token based authentication • SSL/browser encryption • Htaccess is insecure and can inadvertently cause DoS attacks
Auth-Type Basic password protection Pop-up Box integrated into browsers Out of the box Apache directory protection Insecure against sniffing (dsniff) Insecure against brute force attacks (wwwhack/whisker) Can cause DoS attacks by simple brute force attacks What is Htaccess?
Configuring Htaccess • AllowOverride All • typical .htaccess file: AuthUserFile /apache/data/.htpasswd AuthType Basic AuthName “Protected” <Limit GET POST> require valid-user </Limit>
Detecting (signature overview) • Zombied Processes / Spiked load • Gracefully restarting does not help load • hard (apachectl stop) stop and start improves load • many attempts from the same IP address (range) to access members area • Sequential username attempts
Cracking Methodology • Check for 200 OK return headers • Pattern match “Welcome” or “Please log in again” embedded in returned html
Headers Masking • First tried returning 401 Error • “Status 401 Authorization Required\nContent-Type: text/html\n\n” • IE/Netscape act differently with 401 errors • Browser detection is useless
Headers Masking 2 • Next tried 200 OK • “Status 200 OK\nContent-Type: text/html\n\n” • Results in no Pop-up window • Only modifying URI can pass username/passwords: • http://user:pass@www.site.com/private/ • Modified approach using form submission works in coordination with a client side token that corresponds with a local database entry.
Headers Masking 3 • Now we need a program to run interference between normal .htaccess scripts and the database. • mod_auth_external • mod_PERL • Proxy
Content Masking <html> <frameset cols=“100%,*”> <frame name=“/private/index.cgi?mainframe.html”> <noframes>Must have a browser that can use frames </noframes> </frameset> </html>
Content Masking 2 • Since the user has not been authenticated if the user attempts to see /private/index.cgi they will be redirected to /401.cgi but URI will still say /private/index.cgi. • ErrorDocument 401 /401.cgi • 401.cgi places a “one time try” token cookie • mainframe.html (non authenticated version) contains login form submission.
Why the cookie? • You need a token (AOL, proxies, etc…) • Extremely difficult to guess (based on time) • No more sending sensitive information over and over again. • cookie will time out, unlike usernames/passwords. • Used with OTPW, even problems in SSL are a non-issue.
Content Masking 3 • Using frames our index.cgi and 401.cgi page look identical (including cookies) • Working towards 100% perfection to prevent recursive cracking programs is inefficient and opens another security hole. • Ascii hex &20; = “ “ &41 = “a” (randomize) • including mainframe.html in comments • multimedia headers mismatch problem
Worst Case • As many as 10 connections or more opening per second, without cleanly shutting-down • 20 different proxy servers • 60k hits normal traffic (heavy day) • Can you find out who the original host is? • Nope and not like that would help you, they are using a proxy server, duh!
Morris’ Attack • Robert T. Morris 1985 attack against the ISN. “A Weakness in the 4.2BST UNIX TCP/IP Software” • If the return address in the initial SYN packet is spoofed, we don’t see it, but we can guess it. • Blind (half-duplex) httpd connection can be used to break IP based authentication.
Blocking • Two choices • mod_PERL/Apache mod to deny access from that IP (or “reinstate your password” page): • Mod_PERL has issues regarding IPC • if speed is a concern and fast-CGI will not work, mod_PERL will probably be equally problematic. • Connect mod_auth_external to ipchains or hardware firewall • could be used to create DoS without human logic
Alternatives • Auth-Type Digest • essentially based off hash of user/pass combination + one time pad • considered computationally unbreakable 2^128 • will not stop brute force attempts, and has the same problems with additional overhead that Auth-Type Basic has • No one has written such a tool
Alternatives 2 • Proxy server • Will work with any webserver and not just Apache (Windows/Mac/Solaris, etc…) • Could easily be integrated into existing IDS or Firewall architecture • Highly theoretical • must have a que from the webserver when/where to interfere with connection.
Conclusion • Without much effort htaccess can be a robust solution. • Knowing the symptoms of the attack can only help you. • Aware of the risks • You will know your own reaction strategy
Thanks! • RLoxley, Teeceep and Peter Shipley - idea bouncing • Ali Nazar - proofing • Ethan Brooks, Goose, Vacuum, Bronc Buster, John Stewart, Tattooman - technical help • Robert Morris - taking impromptu phone calls :)
Links www.shocking.com/~rsnake/htaccess.html (the paper in entirety along with links to resources and more details can be found on this site)