Flawed CSRF Protections

13.02.2008

Okuyucu : 2.220
Günlük Okuyucu : 23,4

Before going into the details and the vulnerability in WordPress, I need to say all of credit should go to Gareth Heyes, he talked about CSS Overlays before, but shame on me that I missed his point in the first place. When I looked into his new tool PoC for CSRF bypass in delicious, I realised that, this is a big deal. I know the exploitation requires lots of stuff but it's still important and this is something which can be fixed in server-side, therefore it should be fixed.

There are two common and wrong implementations of CSRF widely deployed;

CSRF Protection which requires confirmation if token / nonce doesn't match.
For example WordPress CSRF protection.
Form loads with default values thru POST or GET and then generates a new nonce and show you the form with this new nonce.
For example delicious.

First one is a smelly implementation, any security minded person won't love it even though they couldn't come up with an exploit.

Second one is quite legitimate and common usage and sometimes it's pretty hard to build some functionality without doing this.

Why WordPress is vulnerable?

Because if you do a request with a wrong token / nonce then WordPress will show a confirmation page with a new correct nonce. User need to click "yes" to confirm request. WordPress should cancel the request and error instead of a show a confirmation page to continue. I assume the motivation of WordPress developers was allow users to a more user friendly environment in case of nonce got lost in session or something like that. Generally it's a bad idea to try to fix stuff instead of rejecting them, and in here it's proven again.

How to Exploit?

Just like a CSRF attack, prepare your attack,
Point your attack to victim' s domain (GET or POST) in an iframe,
Iframe should mask everything but confirmation or save button. This can be done in several ways. The most efficient way is potentially using absolutely positioned divs and inner iframes.
Now user should click this button to carry out final confirmation. This bit might require a bit social engineering.

Obviously final step can not be automated by JavaScript, if you can then it'd a bigger issue, ability to bypass SOP (same-origin policy).

WordPress Exploit and Screenshot

WordPress CSRF Bypass Exploit, to able to test you need to modify form, details and target action. This exploit tested in default installation of WordPress and if admin GUI template or styles changes (unlikely) it's not going to work.

Picture below is from an actual exploit test, and Yes button is coming from WordPress server. When victim clicks it attacker can change admin's e-mail and password.

This is the response after victim clicks yes button. It's not perfect but no one is going to be suspicious because yes button turned to blue.

Patch / Solution for WordPress

This is an unofficial patch, I just scraped it to fix the problem quickly and I relied on that this is the only function deals with this issue.
Go to /includes/functions.PHP replace wp_nonce_ays() function with the new one below.

function wp_nonce_ays($action) {
    global $pagenow, $menu, $submenu, $parent_file, $submenu_file;
    $title = __('WordPress Nonce Error ');
    wp_die('WordPress Nonce Error', $title);
}

That's it. This will fix the problem. Now you will see a static error message instead of a confirmation page.

What Now?

I bet there are lots of other applications which are vulnerable to either of these CSRF Protection Bypass vulnerabilities.

Credits

CSS Attacks and CSRF Chat from Gareth Heyes
Sid of Notsosecure, helped me to test patch.

Yorumlar

Bu makalenin yorumlarını RSS ile takip et!

Biraz daha acik olabilir mi?

users [ # | 13.02.2008 ]

anladigim kadariyla acik olan sitenin admini bizim kodlari koydugumuz siteye girerse bizi otomatikman admin mi yapiyor :S

users [ # | 13.02.2008 ]

wordpress vuln, tebrikler
xss gibi ama csrf biraz daha farkli adminin tiklamasini beklicez, açikcasi vuln için tebrikler ama
en eglencesiz vuln diyebilirim :)

BORDO [ # | 13.02.2008 ]

wordpress vuln, tebrikler
xss gibi ama csrf biraz daha farkli adminin tiklamasini beklicez, açikcasi vuln için tebrikler ama
en eglencesiz vuln diyebilirim :)

Aslinda belkide beklemeye gerek yoktur iframe içerisinde get,post kullanilarak sanirim böyle bir saldiri yapilabilir . Söyle dersek belki yanlis olmaz amaç hack yapmaksa her yol mübahtir (!) . Dökümanin basindaki iframele scriptsiz post islemi gibi.

Bu dökümani yayinlamadan önce verilen hash'da CSRF saldirisyla mi alindi acaba ?

TunerX [ # | 14.02.2008 ]

Bu dökümani yayinlamadan önce verilen hash'da CSRF saldirisyla mi alindi acaba ?
Hash exploitin MD5 hashiydi, yani bu sayede ben bunu yayinlamadan baska bir ayni acigi yayinlarsa bak aslinda ben de bunu bulmustum ama daha yayinlamamistim diyebilmek icin :)

Ferruh Mavituna [ # | 14.02.2008 ]

Kardes vala helal diyorum ne diyeyim. Belkide bilmedigimiz nice açiklar var :) Gerçi hala "or''= gibi açiklar hala yiyorsa bu yeni açiklar gündemimizi bayagi mesgul edecek diyebilirim :)

Özelliklede sistemler karmasiklastikca bu açiklar ortaya çikiyor.

Mesela düz bir WP kurdunuz 3 -4 tane açigi var sonra birkaç tane Eklenti eklediniz alin size onlarin açiklariyla beraber 10 tane açik sonrada sisteme ek seyler koydunuz bir o kadar daha açik.. Host firmaniz güncellemeleri takip etmiyor.. Al bir o kadar dahaa..

Söylemek istedigim su :

Ilk zamanlar MS - DOS seklindeki sistemlerden simdiki Komplike sistemlere geldigimiz zamana bakarsaniz sistem iyicene komplike oldu artik bilgisayarinizdan TV nizi bile kumanda edebiliyorsunuz.. Sistem karmasiklasmaya devam ediyor. ve bence Güvenlik gelecegin Meslegi olacak...

Bu arkadaslardan biriside Ferruh Mavituna...

NOT: Arkadasim benim WP 'ye de bir el atsana bak bakalim açik maçik var mi ? :)

teakolik [ # | 15.02.2008 ]

Bir script kuracagimiz zaman mutlaka ama mutlaka hangi dille yazilmissa onu bilen bir kisiye kodlari incelettirmek wordpress ekibin hala fix etmedigi nice kodlar olabilir ya kendimiz ya da baskasina kontrol ettirmeliyiz.Insan önüne gelen eklentiyi kuruyor ama bun da bug olabilir mi diye hiç düsünmüyor baskalari bunda açik yok deseler bile mutlaka ama mutlaka kontrol etmelidir ama phpbb ya da wordpress gibi bütün kodlari nasil kontrol edebilecegimizi bilmiyorum :).Bilen kisiler Priv8 olarak bulduklari açiklari ya satiyor ya da kendisine sakliyor.Demek ki bu adam biliyor ki inceleyip hiç açik yok diyen bir scriptte açik bulmul?Iste buradan anlasiliyor ki güvenlik her seydir.

Koray YAMAN [ # | 15.02.2008 ]

Aslinda inanmicaksiniz ama ben zaten bunu bulmustum ama su anki hali pek kullanisli degil çünkü ne yapilirsa yapilsin _wpnonce degeri yüzünden otomatik olarak submit edilemiyor her durumda onayliyormusunuz diye soruyor bu yüzden su anda senin yaptigin hileyi yiyicek kisi sayisinin 1 elin parmaklarini geçmiyecegini düsünüyorum. _wpnonce degerini çekebilmenin bi yolu olsa güzel olur ama malsef öyle bisy simdilik mümkün degil.

Kral [ # | 15.02.2008 ]

Her bug tehlikelidir.Gel gör ki eskiden XSS kimsenin umrunda degildi küçümseniyordu simdi ortada XSS Shell var daha neler çikacak en ufak bir kod hatasi ihmale gelmez.

Koray YAMAN [ # | 16.02.2008 ]

Ewet dogru xss denen bir teknoloji var , maalesef webmasterlar icin cok kotu bir durum kimi zaman.
"Xss Shell Tunelling" projesini ortaya cikararak isi daha vahim duruma getiren ferruh abi ye de bir sozum var "netin gazabi uzerine olsun" ; amin ! . diyebilirim ancak. Oh be rahatladim fuck of 505 :D
ferruh abi kusura bakma biraz icden konusdum , sevgilerimle

bekiR [ # | 25.02.2008 ]

Yorum Ekle