:: Phishmarkt :: at ::

Welcome to the Phishmarkt, full of new offers!

Article 19, Universal Declaration of Human Rights
Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers.
Disclaimer
All shown vulnerabilities can be found by using the corresponding web site in a legal way. All links are published for educational purposes only and not to harm anything or anybody. All used techniques are well known for many years and can be considered state-of-the-art.
Though it is obvious, that the shown vulnerabilities can be used for fraudulent purpose anonymously.
Most examples will work without JavaScript in the browser. If JavaScript is used, then it makes the whole thing even more simple.
None of the examples will store data permanently in the the users browser!
None of the examples will start other programs on the users browser!
Technical details of the functionality of the examples are not shown. This would be obvious for advanced users anyway.

What does that "--FIXED(?)" mean?! (21st Feb. 2007)

As it is not only our aim to blame banks for their mistakes, we also check if they fix their problems or if they just ignore it. The "--FIXED" sign means, that a bank seems to have taken the warning seriously and now filters input. This does not necessarily mean, that their page is secure from now on, but THIS specific flaw does not work anymore. "--FIXED?" means, that it can not be said for sure if the bank really solved the problem or just changed the sites name (for example if a 404 error occurs).
The first check has been done after 5 days and the banks listed below fixed the vulnerability:
Sparkasse (DE), Alpenbank, Stuzza, Bawag, Erste Bank (sparkasse.at), Österreichische Nationalbank, Baader Bank, Bank Austria Creditanstalt, eBase, OeKB, Generali Bank...
The second check has been done after 10 days with a shocking result:
Nassauische Sparkasse (DE) and Volksbank Tirol have now fixed the XSS vulnerability, but still about 20 banks (!) are totally ignoring their customers security, not fixing the problem and opening a hole for Phishers...

Why we do it?!

Short: Because we can!
Long:
First of all you should realize, that this is not the first time, that we are doing such a website. The last time we hit a vast number of sites, mostly german banks. We have shown, that those sites, that should be most secure are not! Many visitors saw the site and also the banks seemed quite upset, nevertheless they fixed the problems, that we pointed at
You can check out the archive at: [English version] and [German version]
This project has been done as a direct reaction to the poll done in austria not long ago and which was reported at [this article] from Heise. For the english readers of you, this article basically says, that 9 of 10 people using online banking in austria trust the security, that their banks offer.
Some banks as the "Bank Austria Creditanstalt" even proclaim, that they are very secure and do a lot about it, which you can read in [this article].
Coming back to the question "Why we do it?!" we can say, that it is necessary, still banks ignore the security, still customers do not realize the risk and still it is necessary to do such a Full Disclosure to make both groups react!

How to cook the phish?! (For beginners)

- Replace " with "
- Replace ' with '
- Replace > with >
- Replace < with &lt;

... and get your meal :)

Who is responsible for all that?!

Dear company, these informations are for free! use the saved money and fix (up) your web site.
Dear marketing manager, tell your web developers, that pages with active content (in particular JavaScript, ActiveX) are a security risk.
Dear web developer, why is there no data validation done? it's so simple:
" becomes &quot; etc..
Dear hedge lawyer (if you feel addressed, you're meant:), some buzzwords which don't apply to any of the shown examples:
  • data modification on the server
  • data sniffing on the server or the client
  • bypassing security measures on the server
Though, following applies from the view of a victim, who is attacked by such an malicious example:
  • data modification on the client
  • data sniffing on the client
  • bypassing security measures on the client
The application (= web page) is the source of all these risks! The Application sends the malicious code, at least the link to the malicious code.
Dear webmaster, some pages and hints according security are realy funny. In most cases you are not the author, then simply sign the page with the author's name :-)

How about some links?!

April 2004 T-hack
This site is not related to this kind of vulnerabilities, but shows clearly how companies try to force down the people finding security holes.
This paper shows how to use JavaScript to analyze a network (LAN) behind a firewall very silently.
October 2006 Full Disclosure
An argument for Full Disclosure.

A never ending story...

 

 

 


powered in 0.13s by baseportal.com
Get your own Web Database - for FREE!