Securing 7 Layers of Insecurity

DeepSec Vienna 2007 7 Layers of Insecurity t. ten n Co

f d o

ome s

copy les an i do d r n a fing.” g F h ca

ur I P a s o T ms s me T t 3 ous da H ri 6 ne f Servin

ing

r e t A o r

s d br ot

e rt n c Inte t

A a S

And

-- a the

“ P he

h T T



F C DeepSec Vienna 2007 7 Layers of Insecurity r om .c owing n unte de ung) r t foll i r e w

mons rbe on) t i a t a unde ite P c k Be om i T i be if n or r T e a a ec t be w l

od H ri r v s h i i m d ha st t ye n uc th a or a e a f Au nz ( n

und be e Ma , ify orbe ng t o P nc n ze d n v u o e

cr T z i ite e Li als nna ic F tia rde e r l t mo e (

e s

ht i - w.

d e Nut c V a

rbr e lbe us 3 ba nd , m e e le l e 6 a a l v

s Re nc a ww S i m

nnt we s e e ie r , te ngs r r r r zt, rc rz e na f fe bu e nig p:// i e o if r me nut t raini r f n: Ei unde

it unte n ge is T ge htt om be

e n Pfe omm d / d

i c d be t s I k e , e r

v né e 7 f ht r t work Ar 0 f c e e e r ngunge

Re us s 0 i ng an mus non v v , i h y i i ni s d t n müs l t t a re 2 or

e e a a f r ür ul g

s fk it da

f Be : v v e i hor or a ri ri n b nt fre be r K ght e y

De Only Nur De Aut Aut m ri

Ar y e

m Cons nde e . e

e e

ha p e s .T

e a o lge ou ma

o o N a Di f Mic C. Y Som

  C DeepSec Vienna 2007 7 Layers of Insecurity P T T H d n a

P T F -

3 6 P T view acks g r T verview 7 3 tt n V 0 H 6

O A A 0

eli 2 D r d r Ove

e e TP TP n nn b da t eb T T

u a m p

W T H H F e

v a P      g

h T N A

F C DeepSec Vienna 2007 7 Layers of Insecurity ) P P T T T H F d ( n

a l

P o s. T c r F - o 3 t sfe 6 o r ran P T

r e e il f

7 F 0 s 0

n 2 r

a e ical b r r

m T

s e i

o l i N H

 F DeepSec Vienna 2007 7 Layers of Insecurity CP T P C an T / th c P er T s d mi T n P H o an na i d

C y n P a d

T ect , P F T P TP 21/T F nn e 1971, old 1971, C -

el es o v n 3 c n 6

si od P an 14 i 20/T m

el assive F w TC ch , pas n C 1 ee e p P d r F i T 7 an v 0 ed r 0 h R e 2 t nd

i r es two es th v e mman w b

ata ch o O us us m

D C active F exte e r

v P     o

TP TP

T N F F B

sswo n en vin lters f a

r o ns P fi a T e s/pa F se r -

f tr us 3 ty to 6 gin i s are un s are e fo lo eca ex d s l r b eck o p e i y t m t fo r s mo nc 7 e co 0

ity ch 0 p smission r ou 2 late n r o ds ortan

e a r p ym b teg

P ad tr m

in h

I e

g P o n i 

TP TP

T N N F A H F

 F DeepSec Vienna 2007 7 Layers of Insecurity s d r erou g y swo tl an le P d as T en

b i p T e u

e H l ss d as n a

P d freq T F sit po d -mail writab se - r o

e ≠ u 3

6 o servers ar s ep s P wo d P se d i T l T ou P il F T ass

w file

n F

ym s o n s F o p 7 u sers u as

0 o gin u o 0 n

ou , e 2 lo an

r te m e us y li ym

b y gin ble an

x: b n i

m n

lo ta F A A Po e

v o ri     o n

n N W N A

R T n P X K o E → , po O T

T C P F O R C A ( : :

: : t r H l n d e e n v o li →B →B →C →B r a

C C C B C e c P T . o F e t - d o o t to S 3 r 6 c M

e e P n

iv 2 s e s ,a a g Con

P a1

, n : g 7 4 A a A 0 r

in ,A 0 e r h

3 → t v 2 te r c A r c

B , e n e e

R V S E n b X

S n O ,A 7

m e

o → 1 T A 2

P C A

v S 2 C

: : o

: :

t l

i N n

→A →A →C →A li

A C C C DeepSec Vienna 2007 7 Layers of Insecurity . ty ri l o P secu T c T o In

H t d o n r a

P P T

F r - e 3 f 6 s n a ity may create ity may r l T a

7 e 0 l 0 rivi i

2 r

) g T l b

P a

m i

din T

v v d

F i

N r A

T © 

( T DeepSec Vienna 2007 7 Layers of Insecurity n ) sion ssio s i se

d sm P a time T

T an at r H

t d ort an n a ne a

n at sp P T o d s i F r g - es

pt n 3 fo tran y 6

e sfers (o P cr istin s wn D w od d o

y l U e en m r ticatio i

an o 9/ o writes fil es v p / le tran n 6 en li r 7 0 p s s e ect 0 ds mm th v ir 2

r se se up k-ste

d au co gle fi e

s u rea O u b

o o o oc m P P P

P P

Sin L N N N e

v T     

FT FT FT FT

F N T T T T

g m , r ds P fo T o istin T in ssible o m l t o H f u

d i o n ory l o a

ed b P

ests T s m y u F rect acket n i - eless p t:

s p 3 , g req 6 t d ac r u n carr o b

uratio p file y everth Imp n fte p t

ames es i o fig n i o r ce m n su r

7 u u t le n i 0 tat ' ing fo c 0 co imag n fi

2 e en r o erver g nn te-

e ot d S s u b

itial r o

em m P P l

n P k: med L Sca B B I e

p v

s T i     

FT FT o

F N R I T T

 T DeepSec Vienna 2007 7 Layers of Insecurity l o P T c T o H t d o n a r .

P P T

eb F r - e 3 f 6 e W s h n t T a r l I T

al 7 t 0 0 x

2 e st C r e T ju b

m e

v p

et's

o y N L

 H DeepSec Vienna 2007 7 Layers of Insecurity l ols co ) to rt P T toc dy T e o ro H spo d d p n a se pro

er se b n P T o th us co F on n -

p n ble tran 3 h o a 6 t resp es i / atio mo w w reli

m e

r ies stat est e om i est/r c fo u v sed qu arr r mes in 7 e c

0 is e 0 e u e est typ er v IP 2 b

ssu

u ns e O a P/

b o

an eq ead ata (req C

m P

teless r teless C T H D R e TP

v T   esp T   

T N R H Sta

 H DeepSec Vienna 2007 7 Layers of Insecurity P T T H s d d n a o P h T t F - e

3 6 M

P T T 7 H

0 T 0 n S 2

r E o e EC E b

N T D m ION ET m

e T AC

v m ON EL EA

o N C OPT D T POS PU GET H

en resp realm

e T l T 64 “ tication to H n e d ab n d t r en SE i n o o a i ses MD5 ng A

th e P B n

T cat F ticatio i all o - se u i

assw t 3 n nt en p ch 6 e a r r th po s with c lt-in” au lt-in” th i i r t u au res n

st create a su st create a “b e e/ swe

7 s g h

0 t cess au 0 t mu t an fer u 2 len

f r ac

e o A al t

b ien ien l h l

m P

es C C Server asks fo Server asks Server asks fo Server asks C e TP

g T   i    asic access T

T N D B H

n b h wo t 3 sn to o 6 g n i th t ti i th tion i e ass w ex p w h

ca m/h n t k tica i

u s u i ce ce m nt en r r 7 u A ttac i ed 0

th he fo fo a 0 g

2 E64 i r au te- M te- n e i t

u T u b r AS r k m act: m

es k: med B MI B B

e a

p v s g i    i  asic aut e

m r N I R D B

 B DeepSec Vienna 2007 7 Layers of Insecurity d %0 n

nt d te n P T d) T rmatio co m

0a an g er e H u fo d n i % nt i

n %0 n ag e t a i ead t ed r P i er 0a, h l T m b p ff F de P i with p - t:

T ts n (% we 3 S ea T

o 6 e d ip t ac h r r H ti e

LF o s en d d st sc ca

st Imp n n li er

an o

ff m i ht pp p R 7 rect u ite fir a i i 0

r s C

t e w 2 es d r eb r red

e R er d a seco w

b se es mig se

d et

m k

n P k: med g Ov I A e

c v

s T i ach  ser  

o ri

T N R C U T T

n T es t T g o i 't H n d i d ) l est i em wo nd n a u g esn se P g o T F d u

req -

β P 3 est, te syst m 6 T a u 3.6 (SP4 n i S W T

y t g H

55 n req m s i d P u vasio e n n i m T e ermed u 7 u T P4-R i e Prox ed 0 S q iso

0 H e 2 f int ID r On /

-1/F e R n d seco

b e po te a

PS m

act: m P k: med be F Su e

eck i

p ea v

s T i ach  h  r

w/I o

T N R I C F C Em C

nd a

g P T in r T o H d th n a u

P A

T F -

ted 3 6 u b tri s i . 7 d D 0 g 0 n 2 V

i r ase n e A

-b D m sio

r b v eb

o e

N V W

 W DeepSec Vienna 2007 7 Layers of Insecurity r r ve e r ve ac ares” … se er

, s

K to “sh b sp

OC s of we P

led L P n T h , T o T t i ab iting H PY d ss wi HT n i ed -en & writing a t

V m e s P lap r v T r s to ing xi F ti L, CO DA e - a

O w od r 3 s eb 6 e o se pe n read i

't ove W eth o v i r lab r m es l MKC

l ts u , stn e ns s b D v t fo ien 7 l na dd IN O 0

c e a 0 exte for co

r 2 V V V V r ortan e OPF A A A A ares mu

p he

b sed D D D D m m

Sh I PR Ot U

e b v eb eb eb     

o e

N W W W

 W DeepSec Vienna 2007 7 Layers of Insecurity ory mem s n k P al T T w ies i tion H ts d d n g ry n us es a n y directive

n d P ha stio T qu ari o F e ex est bo - stio

irecto au

r u 3 y d 6 r au s e sh th estB s k u exh xh ep mo c e d eq use a ps req PU e ws fil t R ∞ t C ca L lo

7 e me l A l w 0 M

D a pac ry/ 0 s lo

2 V tX V IN r av kee i k al e A A ssib

b s s m i i _d D i D m

d D Memo D L Po e

OPF b v eb     

o e

N W PR mo

 W DeepSec Vienna 2007 7 Layers of Insecurity r ve r th se

n st au es S es o P ali ige T ri /TL d T c H s s om cto i d a d f e

n f o a

ir a P ch d r

T or an eth f F T h as SSL -

m e c

3 n k sed ers 6 P xy r o o ys su T o o r al n ati ead V access w c A exp HT t h tio ti an 7 p g g D e P n n n & 7 T yp N r 0 eb r T

yer he 0 a

H 2 V ito ut nc r t e limiti a e limiti A

b se l y y y y ec ect W D m

Mon U b b b b

e b v sp      

o e n

N I Prot

 W DeepSec Vienna 2007 7 Layers of Insecurity P T T ol. H d oc n a

P T F -

g Prot 3 6 g elin n i l nn u e n 7 0 n 0 2 ext T u

e T T

m P

v T yp

T N H

 H DeepSec Vienna 2007 7 Layers of Insecurity e t d this he ]. rne e t 1

r sinc [ e e

UDP) t hout e a / l s l t Inte on from ol, s i e

i r a t o w r ic e e a

he e r v v v t r c y n, (TCP propos e a o

ha of ol

protoc o ti e

oope t P oc W on l nd s i

ogy T t ova ture a ot o ls.

a r T on to tra n l c ol i s no c r c a e t P HTTP) on. n

in t i ( a ie

H h t w h t c P m hi a i e d ol ppli li

a ec ow n rc t W a l t

l Fir a gr a l

pp l .

a t a a i a t ll n nnov ny 1 P hnolog nd a i w 0 c t T to ns e Protoc e r Da e wa e 0 F t e r bi r o- re 2 y e - e ANY Fir

w m l Fi la FEP) i 3

n ( inhi to tra

ns r nd-t i /Us 6 e a e a e o f p to lows ol

t ol l c bl s e o nts a A n l i

h t Tr oc t t n w

x on of ne ly a rs i ot l t ia ode ogy 1 a ho a FEP a Prot v

rTe opme

s , Pr m l

y h 3 nt n pic he y pe t ve t e 9 nc , e n 7 nnov hodol ty 0 i me ntrol t

0 be uri re e e or t

3 r t d e Hy c t E 0

s e Co e

pa a a v nc th me

C en 2 s l

r ts r v l ns F ur on pera e e

e d

i he rec k O o ra R s a t b

c ov nd ha

Enha . ) ll -

t T - m a er, ll ll s owe

t w

e ll

wa P

ting e sm

v wa wa

rne k

e del

re e c i s

re re r ola f

i i N nt pa HTTP pa Fi Tran v a mo Fi ha How I

F ©

( F DeepSec Vienna 2007 7 Layers of Insecurity t oin -p d IP / P m en ary P fro T el T s es TC n s bin H n g d y ect n vid n l tu a i n

o d P r n T as l th F p ien co - r

3 od xies 6 o firewalls se it g rts al r xy-f eth g o n p i n s u m l i l

server sp c e gh T r co u n 7 an e i 0 r o

to EC t n 0 r

p N 2 h u r ro

r t

or web e T is very pro is very p TP

b s

fo at ON T

l i y k

m P r C H e

v T o ea   T

T N Med I W Man H

H d eb n a

P T n ut w F ts o o - s

ti l 3 6 ien o HP/Perl nta o P

le cl rk with l el i in

n b - e l leme n 7 wo el ne 0

tun n 0 s, n n imp

2 u k mo tp

e un T

b Ptu ht

hin tc/ht T

m P

U T Java h e TPt

v T  T  

T N H JH GN

 H DeepSec Vienna 2007 7 Layers of Insecurity n if rce. s. l tio ou e P n. T nn res T cryp tio H tu d en d

n tical a d

an P h cau T t s i F ivery service. e - n an l

3 xi 6 s ro are a cri atio er p c v s P ata de f ti T en T ser 7 2 d. erver th 0 H 6

is a d e 0 s

2 r d r P

ar uir e e TP n b t q se au se F T

ake care o a e m p

T U r T H U e

mm v a P . . . . .

h T N Su

F C DeepSec Vienna 2007 7 Layers of Insecurity P T T H d n a

P T F -

3 6 7 u 0 s? 0 o n 2

r Y o

b ti k

m n e es

v a

o h N Qu

 T DeepSec Conference © November 2007

Chapter 63 FTP and HTTP

 The Art of Serving Files and Content. D 7

eep L ayers o Sec “And bring me a hard copy of

the Internet so I can do some Vien f I serious surfing.” n secu n a 2007 rity -- Scott Adams

 Some rights reserved / Einige Rechte vorbehalten

 Michael Kafka, René Pfeiffer, Sebastian Mayer C.a.T. Consulting and Trainings, Vienna, Austria

 You may freely use, distribute and modify this work under following D agreement: 7

eep  Diese Arbeit darf frei genutzt, verbreitet und bearbeitet werden unter L

folgenden Bedingungen: ayers o Sec Authors must be referenced (also for modification) Autoren müssen genannt werden (auch bei Bearbeitung)

Vien

Only for non commercial use f I Nur für nichtkommerzielle Nutzung n secu

Derivative work under same licence n

Derivative Arbeit unter selber Lizenz a 2007

http://www.creativecommons.com rity

This presentation is published under the CreativeCommons License which can be viewed in detail on their hompage: http://creativecommons.org/licenses/by-nc-sa/2.0/at/ Read more on http://www.creativecommons.com

You are free:

to Share — to copy, distribute and transmit the work

to Remix — to adapt the work

Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). Noncommercial. You may not use this work for commercial purposes.

Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

● For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to this web page. ● Any of the above conditions can be waived if you get permission from the copyright holder. ● Nothing in this license impairs or restricts the author's moral rights.

Chapter 63 FTP and HTTP

 Agenda  FTP Overview  HTTP Overview D 7

eep  HTTP Attacks L ayers o

 WebDAV Sec  Tunneling

Vien f I n secu n a 2007 rity

File Transfer Protocol (FTP)

 Historical File Transfers. D 7

eep L ayers o Sec

Vien f I n secu n a 2007 rity

FTP Overview

 Born with RFC 114 in 1971, older than TCP  FTP uses three modes  active FTP, passive FTP and D 7

eep  extended passive FTP L ayers o

 FTP uses two TCP connections Sec  Command channel 21/TCP

Vien  Data channel 20/TCP, dynamic/TCP f I n secu n a 2007 rity

The active mode in FTP opens a data connection from the server port 20/TCP to a random dynamic port on the client side. This breaks NAT and renders static packet filters useless. Modern packet filters analyse the FTP PORT command and create dynamic filter rules to allow active FTP data connections. The passive mode lets the client open a TCP data connection from a dynamic port to a dynamic port on the FTP server. This solves the NAT problem on the client side, but requires a FTP-aware packet filter on the server side in order to avoid opening the whole dynamic port range for FTP data transmissions. Extended passive FTP mode is very similar to the passive mode. The only difference is the format of the PORT announcement. The PORT command uses a string consisting of the IP address and the port to be used for the data transmission. The string look like this: h1,h2,h3,h4,p1,p2 The first part is the decimal representation of all IP address octets. The port is calculated as port = p1×256+p2. In extended passive mode client only transmits the port number directly without IP address.

FTP Properties

 FTP transmissions are unencrypted  Important for logins/passwords  Anonymous mode for serving data D 7

eep  Higher latency because of commands L ayers o

 No integrity check of transmitted files Sec  FTP adds complexity to filters

Vien f I n secu n a 2007 rity

Anonymous FTP

 Anonymous FTP is used frequently  No login, no password  Any login will do D 7

eep  Polite users use e-mail as password L ayers o

 Writable anon FTP servers are dangerous Sec  Abuse as file deposit possible

Vien  Fix: anonymous ≠ writable f I n secu n a 2007 rity

File eXchange Protocol (FXP)

Client C → Server A Client C → Server B D 7

eep

C→A : Connect C→B : Connect L

C→A : PASV ayers o A→C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2 Sec C→B : PORT A1,A2,A3,A4,a1,a2

B→C : OK Vien C→A : STOR C→B : RETR f I n secu n B→A : Connect to Server A, port a a 2007 rity

FXP is an early addendum to the FTP protocol. At client can connect to two different FTP servers and links them by issuing a STOR and RETR command with port information pointing to the receiving FTP server. The original idea was to initiate file transmissions between well connected servers from a third location having limited bandwidth. A side effect of FXP is the so-called FTP bounce attack. A malicious client exploits the PORT commands and directs the second TCP transmission to another host. FTP servers susceptible to the bounce attack can be used to port scan victims or to act as agents for packet floods.

Trivial File Transfer Protocol (TFTP)

 Adding Triviality may create Insecurity. D 7

eep L ayers o Sec

Vien f I n secu n a 2007 rity

TFTP Overview

 TFTP uses 69/UDP for data transmission  TFTP uses no encryption  TFTP reads/writes files D 7

eep  No commands L ayers o

 No directory listings Sec  No authentication

Vien  TFTP supplies own transport and session f I n secu  Single file transfers (one at a time) n a 2007  Lock-step mode rity

The TFTP lock-step mode ensures that only one UDP packet is “in-flight”. Every packet is acknowledged after reception. Since UDP can't do any window scaling and only one packet is kept in-transit, TFTP is quite slow over high-latency links. TFTP is described in RFC 783, 906, 1350, 1785, 2347, 2348 and 2349.

TFTP Security

 TFTP server often carry boot information  Initial configurations  Boot images D 7

eep  TFTP don't support directory listings L ayers o

 Scanning nevertheless possible Sec  Brute-force file requests

Vien  Implementation bugs f I n secu  Long file names, packet floods, … n a 2007  Risk: medium Impact: medium rity

Mitigation: • Make sure TFTP is confined to management networks. • Monitor TFTP access for file harvesting/guessing attacks. • Disable write access to TFTP servers that are used to serve configurations or firmware.

HyperText Transfer Protocol

 Let's just Call It The Web. D 7

eep L ayers o Sec

Vien f I n secu n a 2007 rity

HTTP Overview

 Stateless request/response protocol  Request type  Header information D 7

eep  Data (request/response body) L ayers o

 Response carries status code Sec  HTTP assumes reliable transport

Vien  TCP/IP is common f I n secu  Can be used with other protocols n a 2007 rity

Common HTTP Methods

 HEAD  GET  POST D 7

eep  PUT L ayers o

 DELETE Sec  TRACE

Vien  OPTIONS f I n secu  CONNECT n a 2007 rity

HTTP HEAD, GET and POST are the only methods a web server has to support. These are the most common methods used. HTTP PUT allows uploads via HTTP and can be configured on the server. This method must be processed by a suitable CGI script that directs uploads. It is usually deactivated. Apache Week has an article about PUT. HTTP DELETE can be used to delete a resource in similar fashion. HTTP CONNECT establishes a TCP connection to a specific target address. This enables an user to create a transparent TCP/IP tunnel. It is commonly used with proxies and TLS/SSL traffic. HTTP TRACE echoes the HTTP request back to the client. This is very useful to detect intermediate network devices that alter the HTTP traffic (such as proxies for example). HTTP OPTIONS tells the server to state its capabilities in terms of HTTP methods.

HTTP Authentication

 HTTP offers “built-in” authentication  Basic access authentication  Server asks for password to realm D 7

eep  Client answers with BASE64 “encryption” L ayers o

 Digest access authentication Sec  Server asks for challenge

Vien  Client must create a suitable response f I n secu  Challenge/response uses MD5 hashes n a 2007 rity

The authentication mechanisms user the WWW-Authenticate: header in the challenge. It is usually transmitted with a 401 Authorization Required status code. The client uses the Authorization: header in order to send the response. In basic access authentication the response is the BASE64-encoded password which is practically clear text since this operation can be reversed easily. Digest access authentication uses MD5 hashes both in challenge and response. A sample session looks like this: WWWAuthenticate: Digest realm="Computer programmers never die, they just get lost in the processing.", nonce="NyveX4I+BAA=e3daa238e35239e5d6590b76823494a9e73edfc5", algorithm=MD5, domain="/ http://www.example.net/", qop="auth" Authorization: Digest username="user", realm="Computer programmers never die, they just get lost in the processing.", nonce="NyveX4I+BAA=e3daa238e35239e5d6590b76823494a9e73edfc5", uri="/admin/", algorithm=MD5, response="0fe14676230438afaf452d622c43f3d3", qop=auth, nc=00000001, cnonce="0860596ee0c48d29" The user name and the realm is transmitted in clear, but the other values are hashed. RFC 2617 describes how the values have to calculated. The nonce value protects from replay attacks. The cnonce value is a protection from chosen plaintext attacks and allows the client to verify the server's challenge. The Quality Of Protection (qop) value is optional, it is not proposed in RFC 2069, the original digest authentication method. It is nevertheless possible to attack the hashing algorithm by using brute-force methods and dictionaries.

Breaking Authentication

 Basic authentication  BASE64 is next to no challenge  Brute-force passwords, sniffing D 7

eep  Digest authentication L ayers o

 Brute-force with sniffed nonce/response Sec  MITM attack with brute-force

Vien  Risk: medium f I n secu  Impact: medium/high n a 2007 rity

While digest authentication is cryptographically weak, its security is sufficient for many applications. The data transmission is not protected, but the username/password pair is not transmitted in clear text. This is the main remedy against the basic authentication method (apart from the replay protection). Mitigation: • Avoid HTTP basic authentication. • Rate limit HTTP digest authentication. • Combine authentication with SSL/TLS. • Always use HTTP authentication as one component in a multi-layered security configuration.

HTTP Response Splitting

 Trick web application with %0a and %0d  Target redirect scripts  Insert CR and LF (%0a, %0d) D 7

eep  Add a second HTTP header L ayers o

 Overwrite first header information Sec  User sees different web page

Vien  Caches might store different content f I n secu  Risk: medium Impact: medium n a 2007 rity

There is an article on the SecuriTeam™ web site with an example of response splitting: GET /~dcrab/redirect.php?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3E%3Cfont color=red%3Ehey%3C/font%3E%3C/html%3E HTTP/1.1\r\n Host: icis.digitalparadox.org\r\n User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2\r\n Accept: text/xml,application/xml,application/xhtml xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5\r\n Accept-Language: en-us,en;q=0.5\r\n Accept-Encoding: gzip,deflate\r\n Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n Keep-Alive: 300\r\n Connection: keep-alive\r\n \r\n

Server to User 302 Found Response: HTTP/1.1 302 Found [First standard 302 response] Date: Tue, 12 Apr 2005 22:09:07 GMT Server: Apache/1.3.29 (Unix) mod_ssl/2.8.16 OpenSSL/0.9.7c Location: Content-Type: text/html HTTP/1.1 200 OK [Second new response created by attacker] Content-Type: text/html

hey [Arbitrary input by user shown instead of redirect] Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html

HTTP Request Smuggling

 Create a HTTP request, send it to proxy  Embed second HTTP request in header  Check if intermediate system works correctly D 7

eep  SunOne Proxy 3.6 (SP4) doesn't L ayers o

 FW-1/FP4-R55W β doesn't Sec  Fw/IPS/IDS evasion

Vien  Cache poisoning f I n secu  Risk: medium n a 2007  Impact: medium rity

The second HTTP request can be in an additional header line. 1 POST http://web.example.net/foobar.html HTTP/1.1 2 Host: web.example.net 3 Connection: KeepAlive 4 ContentType: application/xwwwformurlencoded 5 ContentLength: 0 6 ContentLength: 44 7 [CRLF] 8 GET /poison.html HTTP/1.1 9 Host: web.example.net 10 MyHeader: [add space after the "MyHeader:", but no CRLF] 11 GET http://web.example.net/page_to_poison.html HTTP/1.1 12 Host: web.example.net 13 Connection: KeepAlive 14 [CRLF] Intermediate HTTP servers (proxies, firewalls, layer 7 filters) may have bugs in their parsers and may slip these requests through to the target server or even other web servers. There's a white paper available from Watchfire that discusses the attack vector. Mitigation: • Inspect HTTP headers (application firewalls may be able to do this, the Apache mod_security module does inspect HTTP requests and responses). • Check implementation of intermediate proxies/filters and web servers for handling of HTTP headers.

WebDAV

 Web-based Distributed Authoring and Versioning. D 7

eep L ayers o Sec

Vien f I n secu n a 2007 rity

WebDAV Overview

 WebDAV enables reading & writing to server  Used for collaborative editing  Other extensions exist D 7

eep  WebDAV adds methods to HTTP L ayers o

 PROPFIND, MKCOL, COPY, LOCK, … Sec  WebDAV clients use permissions of server

Vien  Important for WebDAV-enabled “shares” f I n secu  Shares mustn't overlap with web space n a 2007 rity

WebDAV Attacks

 mod_dav keeps request bodies in memory  Possible memory exhaustion  LimitXMLRequestBody directive D 7

eep  PROPFIND causes directory walks L ayers o

 Memory/CPU exhaustion Sec  Disallow ∞ depth requests

Vien  WebDAV allows file sharing f I n secu  Disk space exhaustion n a 2007 rity

WebDAV Network Traffic

 Protect WebDAV access  by authentication such as digest auth  by encryption such as SSL/TLS D 7

eep  by limiting exposed directories on server L ayers o

 by limiting HTTP methods Sec  Inspect HTTP headers

Vien  Use layer 7 proxy f I n secu  Monitor & analyse for anomalies n a 2007 rity

HTTP Tunneling

 Hyper Text Tunneling Protocol. D 7

eep L ayers o Sec

Vien f I n secu n a 2007 rity

Firewall Enhancement Protocol (FEP)

Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1]. However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation. We propose the Firewall Enhancement Protocol (FEP) to allow innovation, without D violating the security model of a Firewall. With no cooperation from 7

eep a firewall operator, the FEP allows ANY application to traverse a L

Firewall. Our methodology is to layer any application layer ayers o Transmission Control Protocol/User Datagram Protocol (TCP/UDP) packets over the HyperText Transfer Protocol (HTTP) protocol, since Sec HTTP packets are typically able to transit Firewalls.

Vien -- RFC 3093, 1rst April 2001 f I n secu n a 2007 rity

HTTP Tunneling

 HTTP is very proxy-friendly  Many protocols use it as tunnel  CONNECT method provides TCP/IP D 7

eep  HTTP transports all things binary L ayers o

 Ideal for piercing firewalls Sec  Works through proxies

Vien  Mediator web server connects from end-point f I n secu n a 2007 rity

HTTP Tunnel Tools

 GNU httptunnel  htc/hts, work without web server  JHTTPtunnel D 7

eep  Java implementation L ayers o

 Think mobile clients Sec  HTTPtunnel - in PHP/Perl

Vien f I n secu n a 2007 rity

Chapter 62 FTP and HTTP

 Summary . Use FTP servers with caution. . TFTP servers are a critical resource. D 7

eep . HTTP is a data delivery service. L ayers o

. Use authentication and encryption if Sec required.

Vien

. Take care of proxies and tunnels. f I n secu n a 2007 rity

Thank You

 Questions? D 7

eep L ayers o Sec

Vien f I n secu n a 2007 rity

99 - Things in Life 28