Threat Level: green Handler on Duty: Johannes Ullrich

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2006-04-19 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Banks use non-ssl login forms.

Published: 2006-04-19
Last Updated: 2006-04-19 21:08:55 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)
This is a bit an old issue I am having, but it seems to be getting worse and not better: Bank that use non-SSL login pages.

Now this is not about sending your credentials in the clear. The bank essentially uses a non-ssl "home page" which includes a login form, but the result of the login form is sent encrypted to an SSL page (e.g. you got to http://www.example.com, and the login form will submit your data to https:/www.example.com). Now why is this so bad, given that your login data is still encrypted? Well, there are two reasons for SSL: The first is to encrypt your data (which happens in this case). The second, as important function of SSL is authentication. A valid SSL connection confirms that you are actually talking to your bank, and that the login form is "real".

With the help of some handlers, we checked out a number of major banks. You can see the result at https://www.securewebbank.com/loginssluse.html . (I will gladdly add more to the list if time allows. If you want to submit any, please let me know the URL of the login page so I can verify).

Another problem, in particular with smaller banks, is the use of "brochure" pages on non-ssl (in many cases even shared servers) that link to an online banking site at a very different domain. Still working on collecting some data about this.


Keywords:
0 comment(s)

phpBB bots/worms

Published: 2006-04-19
Last Updated: 2006-04-19 20:58:31 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)
If you run phpBB, you are probably familiar with bots attempting to attack your sites. Typically, you will find entries in your web log like the following:
viewtopic.php? [...] &highlight=%2527%252esystem(chr(99)%252echr [...]

I omited the long string of URL encoded hex characters. If you run phpBB, grep your Apache access log for 'viewtopic.php', 'highlight' and 'system':

grep viewtopic < access_log | grep highlight | grep system

Now the part you are interested in is what is attempted to be executed as part of the "system" call. In order to quickly decode it, use php's "urldecode" function. Just open a shell, and enter:

$ php -e
print urldecode(" ... [paste gibberish here ] ... ");
?>

Make sure you do not copy any quotes. This will likely reveal an ftp command and with that the location of the actual bot code. Let us know what you find. I posted a quick analysis of a typical phpBB bot here  Important: a few users reported Antivirus alerts after clicking this URL. Since it quotes parts from the bot, it likely triggers some signatures. However, the page wil not execute any malware (trust me ;-) )

These bots typically work all very much alike:

  1. search google for vulnerable systems
  2. send the exploit
  3. the exploit will trigger the download and execution of a perl script
  4. the perl script will join an IRC channel and wait for commands.
Typically, the bot is able to launch DDoS attacks, execute local system commands and infect other phpBB systems. In the particular sample analyzed above, the bot makes an attempt to fix the actual vulnerability. If this is successful or not would depend on the bots ability to write to these files (after all, the bot will run as the apache user).
Couple simple counter measures to keep in mind:
  • First of all don't forget to patch your systems. Its all too easy to forget random web applications like phpBB.
  • make /tmp a non-executable partition. (and link /usr/tmp and /var/tmp to it). Its not perfect, but most of the web based exploits need a place to write their files to, and /tmp is the most common location available.
  • block outbound ftp/web traffic from your web server. Many web servers do not need outbound traffic on port 80/21.
  • run php in "safe mode"
  • for extra credit: chroot apache (not all that easy, but very effective once it is done).
  • use mod_security (thanks to Ramon for reminding me about mod_security. its GGGrreat!)
And don't forget: These bots will run on any platform which has php and perl installed. You may see them on Linux, OS X, Solaris ... maybe even Windows if the bot gets the paths right.

Keywords:
0 comment(s)

How to deal with Oracle patches?

Published: 2006-04-19
Last Updated: 2006-04-19 17:03:34 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)
Steve, who is using PeopleSoft, started to get exposed to Oracle's patches. He writes:

"I'm the security admin for a organization which uses PeopleSoft, which of course was purchased by Oracle last eyar. This meant, unfortunately, that I had to start subscribing ot the Oracle Critical Patch Update. [...] I've never figured out how to get actual details on the vulnerabilities it lists.
[...]
Maybe one [of your diary readers] can offer a tutorial or some tips"

Let us know if you have any pointers. I will add hints, URLs and other help to this diary. Among our group of handlers, we have kind of given up on covering Oracle patches due to the large number and missing details in advisories (plus, its not all that easy to get the advisories in the first place).

Kilynn writes that you can signup for notifications at http:/www.oracle.com/technology/deploy/security/alerts.htm . This will also provide access to the "Risk Matrix" which should also help in applying the patches. However, to know more you need to signup for a "MetaLink" account, which appears to be reserved for Oracle customers. (Actually the original poster, Steve, mentioned the risk matrix, but it wasn't too much help for him without details to adjust it for his environment. It wasn't clear to him how to get access to MetaLink as a former PeopleSoft customer).

Keywords:
0 comment(s)
Diary Archives