Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
If you have some interesting news or want to throw up a link to discuss it, here's the place. Anything is okay, even shameless vendor launches (since that is often applicable to what we work on). 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Phishing vulnerability reported at American Express site
Posted by: digi7al64
Date: December 06, 2006 07:25PM

http://blogs.securiteam.com/index.php/archives/754

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'

Options: ReplyQuote
Re: Phishing vulnerability reported at American Express site
Posted by: maluc
Date: December 06, 2006 09:36PM

malorn.. are you italian..? they might be one and the same .-.

either way, atleast it'll hopefully get fixed soon. Open redirects are really bad for a big credit card company to have. They don't quite match visa's security team's speed though

-maluc

Options: ReplyQuote
Re: Phishing vulnerability reported at American Express site
Posted by: rsnake
Date: December 06, 2006 10:49PM

Eesh... That's no good. Redirects are way harder to fix than XSS holes if they are already being used (whitelists are a pain).

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: Phishing vulnerability reported at American Express site
Posted by: maluc
Date: December 06, 2006 11:54PM

well i think the only smart way to implement a redirector, is to use a look-up table of hardcoded links (and not domains)

http://example.com/redir.php?link=3

with a table:
1 | http://asdf.com/
2 | http://sla.ckers.org/forum/read.php?13,3766,3768#msg-3768
3 | http://test.com/login.php
4 | http://example.com/page3.html

In whatevar language you want to implement it, a simple array works nice. it's fast and easy to prevent tampering (like link=99999 or link=-1)

-maluc

Options: ReplyQuote
Re: Phishing vulnerability reported at American Express site
Posted by: rsnake
Date: December 06, 2006 11:59PM

You're absolutely right when you're doing it from scratch. What I'm saying is that it's hard to fix once implemented because you have to know where all the links are that are pointing to it and account for each of them. Let's hope you have that list and you're the only one using that redirector. This is the exact reason Google could never fix their redirector. It would break tons of stuff. Not that that makes that secure, just because it's hard.

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: Phishing vulnerability reported at American Express site
Posted by: maluc
Date: December 07, 2006 01:09AM

ah, i see what you mean now.. ya that's a sticky situation. Still, sometimes you've gotta sacrifice backwards compatibility for progress..

Google would indeed have to parse tons of pages and maybe patch a few of their trojans - i mean applications - to remove it. Gotta be done eventually nonetheless.

-maluc

Options: ReplyQuote
Re: Phishing vulnerability reported at American Express site
Posted by: jungsonn
Date: December 07, 2006 06:17AM

Yeah numbers maluc.. numbers, numbers! for heaven's sake use numbers!!

^-^

Options: ReplyQuote
Re: Phishing vulnerability reported at American Express site
Posted by: digi7al64
Date: December 07, 2006 06:11PM

There is no difference between a number and a URL from a whitelist perspective. One is the primary key and the other is the URL so either way it is still just another value being passed to the database.

The problem is management. What constitutes a safe redirect, how long should we allow redirects to that url for. What infrastructure do we need in place to control it?

The actual code solution is easy. Managing it is not.

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'

Options: ReplyQuote
Re: Phishing vulnerability reported at American Express site
Posted by: maluc
Date: December 07, 2006 11:28PM

yes, the only purpose for switching to numbers is for speed. If you're a big website and have 10,000 redirects in a whitelist .. using numbers, you can put all the links into an array with a worst-case of constant time O(1) - which is always ideal.

Using the actual link, you could sort all 10,000 in alphabetical order and use a binary search to check it, but that's a worst-case of O(log n). Or you could use a hashing function and hash table with a worst-case of O(n) i think, although almost constant time for a sufficiently huge hash table.

Anywayz, the point being that numbers is the fastest possible method, and should be used.

-maluc

Options: ReplyQuote
Re: Phishing vulnerability reported at American Express site
Posted by: jungsonn
Date: December 08, 2006 07:35AM

@ digi7al64 who said:
There is no difference between a number and a URL from a whitelist perspective.

Yes there can be, cause if they don't filter on the URI's given or they do filter it's still possible to trick the filter into parsing another url, think about nullbyte issues e.d.
By assining an URI to a fixed number and fixed length this becomes impossible, and moreover filtering isn't needed anymore if you just typecast the number param.

Options: ReplyQuote
Re: Phishing vulnerability reported at American Express site
Posted by: jungsonn
Date: December 08, 2006 07:50AM

To add a theoretical example:

In white list:

http://www.cnn.com

Filter used:
RegEx filter or eval(), preg_match() to strip things and match out.

I give this URI:
Given: redir.php?site=http://www.cnn.com%00http://www.google.com


This could lead to TRUE cause it confirms the first based on the whitelist, but it redirects to the second cause the filter/match function ignores the second.


You can't do this when you use numbers, like:

In white list:
183236|http://www.cnn.com

Typecast it to an integer:
int($redir);

This ain't a real world example, but still it could be possible.

Options: ReplyQuote
Re: Phishing vulnerability reported at American Express site
Posted by: digi7al64
Date: December 10, 2006 11:12PM

I agree that numbers are the fastest no doubt but I was sort of talking about the context in which google might undertake it (A mixed approach to a timeline when it would just revert to numbers).

In relation to jungsonn's approach I am assuming (again in the context of google) that they already have the required filters in place to stop these injections, hence that would not equate to true in a sql query. Thus no-redirect.

As for all the phishing scams - encoded urls/ip's etc it is fair to assume that the system that creates the url for redirects would have a standardized mechanism for developing them. hence, if the url's use different methods for encoding the values (and it doesn't match the database value), then it does not redirect.

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'

Options: ReplyQuote
Re: Phishing vulnerability reported at American Express site
Posted by: jungsonn
Date: December 11, 2006 10:17AM

There is also another option, most of the time programmers forget to kill the script after an redirect. Then it is still possible (if you know the variable that contains the redirect url) to execute endlessly, or try to traverse a directory on the server.

to solve this they need to kill the script like this:

# some logic:

$url = $_POST['url'];

if($url) {

# here goes a filter.

header("Location:$url");

die(); # just put a die();

} else {

# other scripting when url is empty.

}

edit: adjusted example.



Edited 1 time(s). Last edit at 12/11/2006 11:02AM by jungsonn.

Options: ReplyQuote
Re: Phishing vulnerability reported at American Express site
Posted by: rsnake
Date: December 11, 2006 10:24AM

There is one disadvantage to fixing your script by using numbers only. If you have an open redirect and then want to close it all the URLs that pointed to it will break. Using a whitelist of URLs will at least allow you to continue using your current system until you move everyone off of it. It's troublesome and error prone, but URL whitelists do fit a short-term need until you can fix it properly (using numbers or hashes, etc...).

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote


Sorry, only registered users may post in this forum.