Posted in TYPO3/ on October 16, 2009 by .
If you are running a TYPO3 installation that makes use of SSL, following new feature will enhance your website's security (starting with upcoming TYPO3 version 4.3):
You probably know that the HTTP protocol is stateless and therefore sessions try to solve that "problem". TYPO3 uses cookies to exchange session identifiers between server and client.
Currently, if you are running e.g. the TYPO3 Backend (BE) with SSL (HTTPS) enabled and call the BE, the server will issue a cookie with the session ID. This cookie will be transferred over an secured/encrypted channel that prevents an eavesdropper to read the session ID from the cookie. If you call the BE again using standard (insecure) HTTP, your client will transfer the same cookie with the session ID exposed in plain-text for everyone who is sniffing your traffic.
Now, with feature #7461 ("Transfer cookies via SSL only whenever possible") implemented in upcoming TYPO3 v4.3, you can decide if TYPO3 should transfer created cookies only over a secured/encrypted channel or if cookies, initially issued by the server over a secured/encrypted channel should again only be transferred (by the client a.k.a. your browser) over a secured/encrypted channel.
This is done by setting a specific cookie declaration that current browsers understand and therefore will apply to your client-server traffic.
To use that new feature, please adjust a new parameter $TYPO3_CONF_VARS['SYS']['cookieSecure'] (through localconf.php file):
Even if e.g. your TYPO3 Backend is accessible over SSL only, you won't be safe from cookies with session IDs transferred in an insecure manner and exposed SIDs as plain-text. So, whenever using SSL with TYPO3, please make sure to be familiar with that new feature and its options.
Posted in advisory/ on October 15, 2009 by .
On October 13, 2009 developers of phpMyAdmin have published an advisory (PMASA-2009-6) for XSS and SQL Injection vulnerabilities in their product.
Today, on October 15, agency mehrwert - the maintainer of TYPO3 extension phpMyAdmin - has published new packages that fix above mentioned vulnerabilities:
(Source: mehrwert's original news item [DE])
Posted in TYPO3/ on August 18, 2009 by .
I'd like to use this posting to point to an unfortunately underestimated or even unknown possibility to get to know what's going on in the TYPO3 world.
Every three months, the TYPO3 Association is publishing (or at least is supposed to be) a Quarterly Report. It's a nice way to get informed about what several (official) TYPO3 Committees / Teams are currently doing or planning.
Today, the T3A has published the 2nd Quarterly Report for 2009. The TYPO3 Security Team is also mentioned in this document.
In detail:
Especially the last item needs a bit of explanation:
The TYPO3 Extension Repository (TER) is constantly growing. With about 4000 different extensions, the TYPO3 Security Team spends almost 100% of its time on extension vulnerabilities.
The bulletin publishing process alone can eat up several hours for a single bulletin. The bulletin is a standard content element. It needs to be in a common form. Every mentioned extension and linked resource has to be manually inserted, links need to be double-checked. Vulnerable extension versions need to be removed from the repository. Bulletin information must be reflected in the according issue in the separate TYPO3 Security Team Trouble Ticket System. The bulletins then will be proof read, comments reflected in the bulletin. New extension versions with the security fixes need to be uploaded. Besides to the bulletin, a dedicated mailing list posting and news item has to be created.
You certainly understand that we really like to reduce the time spend on such tasks. The planned Incident Handling System will change that. Bulletins by default will be in a common structure, extensions and their versions can be selected, automatically added and vulnerable extension versions marked insecure. Mailing list posting and news item are instantly created when publishing the bulletin.
I hope to see it implemented soon.
If you or your company is able to contribute resources (manpower or money) to this IHS project, please don't hesitate to contact the TYPO3 Security Team! Any help is appreciated.
Posted in TYPO3/ on August 15, 2009 by .
The TYPO3 Security Team currently asks for your opinion on providing WAF blacklist rules that address vulnerabilities in TYPO3 Core and TYPO3 third-party extension.
If you are a TYPO3 agency or a TYPO3 hoster, this might be an instant help to protect against newly published vulnerabilities.
An use case would be the immediate installation of such rules when a new TYPO3 bulletin has been published. You then would be protected against upcoming exploits in no time. Afterwards, you have plenty of time to upgrade e.g. a vulnerable extension version in each of your TYPO3 installations.
So please help the TYPO3 Security Team and decide if it's worth to put further efforts into it. Participate in this kind of survey!
Posted in exploit/TYPO3/ on August 06, 2009 by .
Today, a "TYPO3 exploit" appeared on a well-known exploits platform/database website.
The title is TYPO3 CMS 4.0 (showUid) Remote SQL Injection Vulnerability.
Quote:
Vulnerability:
http://www.host.com/index.php?id=[xxx][showUid]=[SQL-injection]&cHash=[xxx]
SQL-injection:
-1+union+select+username,2,password,4,5,6,7+from+be_users--
Admin Panel: /typo3/index.php
The fact that I'm actually writing on it once again prooves that there is no such vulnerability.
In detail:
First of all, the TYPO3 4.0 branch is quite old but still supported in regards to security fixes. If you are using a TYPO3 4.0.X version, you might consider to upgrade to at least 4.1 branch. Soon, the new TYPO3 minor version 4.3.0 will be published which means end of support for TYPO3 4.0.
The showUid parameter is generally used in third-party TYPO3 extensions - not in TYPO3 Core. Together with the tslib_pibase library, showUid is used to display single (database) record details. The library provides access to the parameter value; it's up to the extension developer to sanitize all user-supplied input before they are used in e.g. database queries. The TYPO3 Security Team section on the typo3.org website provides several tutorials on this topic.
The exploit request example does not and will not work as such - not on one single TYPO3 installation out there. It always needs a TYPO3 third-party extension to be involved.
Additionally, a blackhat has to be really lucky because he needs to find a vulnerable TYPO3 extension first. Good luck with that - the TYPO3 Security Team does its best to keep the official TYPO3 extension repository clean.
If I were the guy who has uploaded this useless piece of "exploit code", I'd be pretty embarrassed now.
Considering above mentioned facts, the "exploit code" is more like a general article on SQL injection. Nothing more.
Conclusion: TYPO3 users don't have to worry about it.