TCP Port 6503
We have noticed that earlier today there has been an increase in both sources and targets of port 6503. The first thing that went through our heads was "What would Jack Bauer do?" And then we realized, Jack is currently in a Chinese Prison. Better for us to call on Chloe for help.
Or we could turn to our readers for packet captures. So if you are seeing increased traffic to this port, and have packet captures of something other then just SYNs, please submit them to us.
*Note: For those that don't realize, many of the ISC Handlers are big fans of the tv show "24" whose season premiere is Sunday night in the states. So it is party time for those of us who are fans of the show.
Update: (2007-01-15 16:30 UTC) Several readers (thanks, Peter and Marcel) have written in to suggest that these packets may be attempts to exploit the CA Brightstor vulnerabilities mentioned below (from Nov 2006).
Reference:
http://www.kb.cert.org/vuls/id/860048
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-5143
Or we could turn to our readers for packet captures. So if you are seeing increased traffic to this port, and have packet captures of something other then just SYNs, please submit them to us.
*Note: For those that don't realize, many of the ISC Handlers are big fans of the tv show "24" whose season premiere is Sunday night in the states. So it is party time for those of us who are fans of the show.
Update: (2007-01-15 16:30 UTC) Several readers (thanks, Peter and Marcel) have written in to suggest that these packets may be attempts to exploit the CA Brightstor vulnerabilities mentioned below (from Nov 2006).
Reference:
http://www.kb.cert.org/vuls/id/860048
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-5143
Keywords:
0 comment(s)
DMG Handling Vulnerabilities on MacOSX
In the past week, the Month of the Apple Bugs website has shown a number of vulnerabilities with how MacOSX handles DMG files. DMG files are the Macintosh OS X Disk Copy Disk Image Files and similar to ISO images. As they can be mounted, read, opened using various software packages (such as the Safari web browser and the command line utilities like hdiutil), specially crafted forms of this file may cause denial of service attacks, and remote execution flaws.
Of particular note, on January 10 a vulnerability was identified which could allow attackers to execute arbitrary commands. This is caused by a flaw in the ffs_mountfs() function when handling specially crafted DMG files. The Safari web browser can be used as a conduit for exploitation of this and other DMG vulnerabilities. I would assume that alternate browsers on MacOSX, do not have the same support for this format enabled by default. But if the attacker tricks the user to download the specially crafted image file, then I would suspect exploitation could occur through other installed software.
While Apple computers is correcting for the vulnerabilities, I would recommend that you disable the "open safe files after downloading" option in Safari preferences. I would also be cautious handling DMG files with any other applications on MacOSX.
For more information on all of the Apple DMG vulnerabilities released so far, please see:
Apple DMG HFS+ do_hfs_truncate() Denial of Service Vulnerability
Apple DMG UFS ufs_lookup() Denial of Service Vulnerability
Apple DMG UFS byte_swap_sbin() Integer Overflow Denial of Service Vulnerability
Apple DMG UFS ffs_mountfs() Integer Overflow DoS and/or Code Execution Vulnerability
Apple Finder DMG Volume Name Memory Corruption DoS and/or Code Execution Vulnerability
For more information on the ffs_mountfs() vulnerability, please see:
http://projects.info-pull.com/moab/MOAB-10-01-2007.html
http://applefun.blogspot.com/index.html
http://secunia.com/advisories/23703
http://www.securityfocus.com/bid/21993/info
http://www.frsirt.com/english/advisories/2007/0141
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-0229
Of particular note, on January 10 a vulnerability was identified which could allow attackers to execute arbitrary commands. This is caused by a flaw in the ffs_mountfs() function when handling specially crafted DMG files. The Safari web browser can be used as a conduit for exploitation of this and other DMG vulnerabilities. I would assume that alternate browsers on MacOSX, do not have the same support for this format enabled by default. But if the attacker tricks the user to download the specially crafted image file, then I would suspect exploitation could occur through other installed software.
While Apple computers is correcting for the vulnerabilities, I would recommend that you disable the "open safe files after downloading" option in Safari preferences. I would also be cautious handling DMG files with any other applications on MacOSX.
For more information on all of the Apple DMG vulnerabilities released so far, please see:
Apple DMG HFS+ do_hfs_truncate() Denial of Service Vulnerability
Apple DMG UFS ufs_lookup() Denial of Service Vulnerability
Apple DMG UFS byte_swap_sbin() Integer Overflow Denial of Service Vulnerability
Apple DMG UFS ffs_mountfs() Integer Overflow DoS and/or Code Execution Vulnerability
Apple Finder DMG Volume Name Memory Corruption DoS and/or Code Execution Vulnerability
For more information on the ffs_mountfs() vulnerability, please see:
http://projects.info-pull.com/moab/MOAB-10-01-2007.html
http://applefun.blogspot.com/index.html
http://secunia.com/advisories/23703
http://www.securityfocus.com/bid/21993/info
http://www.frsirt.com/english/advisories/2007/0141
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-0229
Keywords:
0 comment(s)
SSL and Ecommerce Authentication
Good afternoon all. I know that there is a chance that this may come off as a rant, but it is not intended as one. I guess that this really should just be a followup of Johannes' diary from last year called "Banks use non-ssl login forms". But it does seem that some commerce sites have not learned.
In the past 24 hours it came to my attention that Citibank has somewhat recently made a change that one of our readers (Thanks Dan) to their authentication website. In 2006, if you visited http://www.citicards.com it would redirect your browser to their secure site located at https://www.citibank.com/us/cards/index.jsp . This is very appropriate as we have trained our users to look for the HTTPS and the lock in the web browser to help protect their information. However, as of today by default Citibank is no longer redirecting you immediately to the secure site. So one can connect to the website and end up on an authentication page that is not encrypted. However, the post action of the form does actually use the HTTPS server for its communication.
I have seen other e-commerce and web based mail systems that have done similar things. I have also seen many of the popular web email sites only protect the authentication portion of the communication. This does protect the authentication tokens, but how well does it protect all of the other communication that occurs after this point.
So how are we as security practitioners supposed to educate our developers and/or our end users when things are or should be encrypted and when things are not absolutely necessary. In the case of Citibank, is it appropriate to require their customers to either read the source code to verify the authentication form is encrypted, or are we supposed to just trust that they are doing thing appropriately?
While I try to find a new way to educate our users, I will continue to recommend that authentication web forms should start on an SSL page, and should remain SSL until the end user logs out. I also recommend that developers be aware of recommendations like those developed by the OWASP Project when building secure sites.
In the past 24 hours it came to my attention that Citibank has somewhat recently made a change that one of our readers (Thanks Dan) to their authentication website. In 2006, if you visited http://www.citicards.com it would redirect your browser to their secure site located at https://www.citibank.com/us/cards/index.jsp . This is very appropriate as we have trained our users to look for the HTTPS and the lock in the web browser to help protect their information. However, as of today by default Citibank is no longer redirecting you immediately to the secure site. So one can connect to the website and end up on an authentication page that is not encrypted. However, the post action of the form does actually use the HTTPS server for its communication.
I have seen other e-commerce and web based mail systems that have done similar things. I have also seen many of the popular web email sites only protect the authentication portion of the communication. This does protect the authentication tokens, but how well does it protect all of the other communication that occurs after this point.
So how are we as security practitioners supposed to educate our developers and/or our end users when things are or should be encrypted and when things are not absolutely necessary. In the case of Citibank, is it appropriate to require their customers to either read the source code to verify the authentication form is encrypted, or are we supposed to just trust that they are doing thing appropriately?
While I try to find a new way to educate our users, I will continue to recommend that authentication web forms should start on an SSL page, and should remain SSL until the end user logs out. I also recommend that developers be aware of recommendations like those developed by the OWASP Project when building secure sites.
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
© 2024 SANS™ Internet Storm Center
Developers: We have an API for you! 
Comments