News-Feeds:
December 11, 2007
SQL injection in TYPO3
Category: Søren Andersen, TYPO3
Yesterday I received an email stating that indexed_search is voulnerable to SQL injection by backend users in version 4.1.3, which was the one running on my server. First of all I appreciate the security team very much, the work they do to handle security issues is of a very high value to the community. I have once tried to have a site taken over, because I did not understand the importance of reacting quickly on security issues for such a widely spread CMS like TYPO3. Therefore I think it's a must to recieve updates on security issues, if you manage installation/updating TYPO3.
All this talk about SQL injection made me think about what could be done to prevent these problems. Obviously better coding will make this impossible, but since there seems to be no magical upcoming solution to lack-of-knowledge and/or human stupidity, this would be hard to do.
Then it came to my mind: "How do you actually use a security flaw to harm a website?". It would be unnecessary to prove that if someone gains admin access to your site, that you would be in deep trouble. But what would someone need to inject to gain that kind of acces? Somehow you would need to create a backend user with admin privileges. As I have never done any SQL injection I can only speculate, but for some reason, I keep thinking that you must know which table and the structure of this, to be able to create the admin user.
This is really easy with TYPO3 since all pages have the same tablenames and structure. But what if TYPO3 required you to set a prefix to your database tables? Would this not make SQL injection a lot harder to accomplish? Again I really have no idea about the ways you can exploit an SQL injection, it just seems like a straight forward solution.
For another idea, how about enabling the person who install TYPO3 to split front-end tables and backend-tables into two databases. Then the extension should only be allowed to operate on the front-end database. I don't know if this would be bad for performance or other things, so please don't think of it as a fact.
Are these thought totally useless? Let me hear some comments.
comments
December 11, 2007
20:50
Reading the bulletin about the latest, you actually have to be logged in as a back-end user to be able to exploit the SQL-injection vulnerability.
In other words, it's not really that serious at all.
I very much appreciated the information about it though, and extend my thanks to the security team also.
In other words, it's not really that serious at all.
I very much appreciated the information about it though, and extend my thanks to the security team also.
December 12, 2007
12:31
It's not surprising to hear that my simple ideas are fairly useless :)
Georg, you say the suggestion 1 is useless if it's an aggressive attacker, but if it's possible to prevent attacks from less sophisticated attackers, I see some value despite it not being perfect. At the same time I woulnd't mind TYPO3 tables having a user-chosen prefix, for the purpose of making the database clear.
For the same reason I wouldn't mind, if the install tool provided a way to rename the system folder (/typo3/) to something else, as a way to prevent simple attacks like password guessing.
Another thing could be disabling the creation of a default admin account, I guess most people using TYPO3 have "admin" as the username for their main account, which in my mind makes it easier to attemp at the more simple forms of attacking a site. All you have to know is that the site uses TYPO3, that will enable you to append /typo3/ to the domain, write "admin" as the username and start brute-forcing.
I am aware that there are some countermeasures for brute forcing, but then again there are countermeasures for those countermeasures. In general I think open systems should be able to vary in many ways, without significant loss of performance or useability.
But all the obscurity aside I totally agree on the need for some security certification to the extensions in the repository.
Georg, you say the suggestion 1 is useless if it's an aggressive attacker, but if it's possible to prevent attacks from less sophisticated attackers, I see some value despite it not being perfect. At the same time I woulnd't mind TYPO3 tables having a user-chosen prefix, for the purpose of making the database clear.
For the same reason I wouldn't mind, if the install tool provided a way to rename the system folder (/typo3/) to something else, as a way to prevent simple attacks like password guessing.
Another thing could be disabling the creation of a default admin account, I guess most people using TYPO3 have "admin" as the username for their main account, which in my mind makes it easier to attemp at the more simple forms of attacking a site. All you have to know is that the site uses TYPO3, that will enable you to append /typo3/ to the domain, write "admin" as the username and start brute-forcing.
I am aware that there are some countermeasures for brute forcing, but then again there are countermeasures for those countermeasures. In general I think open systems should be able to vary in many ways, without significant loss of performance or useability.
But all the obscurity aside I totally agree on the need for some security certification to the extensions in the repository.
December 12, 2007
17:10
Søren,
ad. renaming tables: please check:
http://en.wikipedia.org/wiki/Security_through_obscurity
ad. admin-Account removal:
- please note the yellow/red warning ("remove the admin user") in c after logging in as admin user;
- and please check:
http://typo3.org/fileadmin/security-team/typo3_security_cookbook_v-0.5.pdf
ad. security certification:
I've not been talking about certifying the Extensions, but rather the core itself; this because the core (and fixes) ARE manageable for the team/association, in contrast to x.000 Extensions / Contributors.
ad. renaming tables: please check:
http://en.wikipedia.org/wiki/Security_through_obscurity
ad. admin-Account removal:
- please note the yellow/red warning ("remove the admin user") in c after logging in as admin user;
- and please check:
http://typo3.org/fileadmin/security-team/typo3_security_cookbook_v-0.5.pdf
ad. security certification:
I've not been talking about certifying the Extensions, but rather the core itself; this because the core (and fixes) ARE manageable for the team/association, in contrast to x.000 Extensions / Contributors.
December 12, 2007
20:00
Georg,
I read the wiki now, and I must say I find it a bit hard to relate it to this context, especially since I'm not talking about hiding security flaws, only making it less likely for others to actually use the flaws when they are discovered.
Again I must admit that I have never done SQL injection, but I would imagine it to be something like this:
Flawed query = "SELECT username FROM fe_users WHERE uid=".$_POST['uid']
By setting $_POST['uid'] to "0; INSERT INTO be_users SET username='eviladmin', password='buuuh(should be an md5 crypt)'"
We would end up with a new admin user, but I can only do this because I know the tablename and the fields to insert in. As I said, I have no idea if more aggresive attackers can do attacks without the knowledge of tablenames, but at least my suggestion would render me personally useless as an attacker :)
Unless the warning has changed in TYPO3 v. 4.2, it only requires you to change the password, and that's why I propose that the admin user shouldn't even be created automatically, but with an extension of the form in the install tool, where you fill out a username and a password.
I appreciate your link to the security cookbook, though I'm still in favor of shipping something that takes precaution by simply disallowing the user to be named "admin" instead of urging people to rename it.
Sorry for misinterpreting regarding certification, as the link to the wiki says somewhere, I just thought that the source was safe, because of the "many eyes" put forward by Linus Thorvald.
I read the wiki now, and I must say I find it a bit hard to relate it to this context, especially since I'm not talking about hiding security flaws, only making it less likely for others to actually use the flaws when they are discovered.
Again I must admit that I have never done SQL injection, but I would imagine it to be something like this:
Flawed query = "SELECT username FROM fe_users WHERE uid=".$_POST['uid']
By setting $_POST['uid'] to "0; INSERT INTO be_users SET username='eviladmin', password='buuuh(should be an md5 crypt)'"
We would end up with a new admin user, but I can only do this because I know the tablename and the fields to insert in. As I said, I have no idea if more aggresive attackers can do attacks without the knowledge of tablenames, but at least my suggestion would render me personally useless as an attacker :)
Unless the warning has changed in TYPO3 v. 4.2, it only requires you to change the password, and that's why I propose that the admin user shouldn't even be created automatically, but with an extension of the form in the install tool, where you fill out a username and a password.
I appreciate your link to the security cookbook, though I'm still in favor of shipping something that takes precaution by simply disallowing the user to be named "admin" instead of urging people to rename it.
Sorry for misinterpreting regarding certification, as the link to the wiki says somewhere, I just thought that the source was safe, because of the "many eyes" put forward by Linus Thorvald.
December 12, 2007
20:30
I'm not going to enter this argument :)
However I do second georg's suggestion that TYPO3 get security audited and certified. The one potential downside of that would be cost...
However I do second georg's suggestion that TYPO3 get security audited and certified. The one potential downside of that would be cost...
December 15, 2007
16:50
"I'm not talking about hiding security flaws, only making it less likely for others to actually use the flaws when they are discovered" -- I agree. Especially as upgrading TYPO3 is not as easy as just clicking a link and sit back and wait (and thus many installations in the world may be outdated) any way to obscure an installation is helpful and does not necesarily categorize as a bad programming habit. Even more: if a lot of old installations are compromised, then the brand TYPO3 will be damaged, or visitors private details might be exposed, even if the webmasters are to blame for not keeping up-to-date.
On the other hand: if SQL injection is possible then an attacker can still easily get a list of the obscured table names -- just like phpMyAdmin can list them for you. But next, of course, the attacker needs a way to display that list, or use the invisible result in the very same injected SQL statement.
If no page can be fooled into dumping the query results, then the attacker might be able to insert the results into some other table. For this, the attacker should somehow combine SHOW TABLES and INSERT. TYPO3 being open source, even though the actual prefix is not known to the attacker, the attacker will know what to search for in the list of table names returned by SHOW TABLES. But I don't know if it is easy to write a SQL statement to get and actually use that list. If doable, then simply inserting the result into table MYSECRETPREFIX_TT_CONTENT would do the trick.
Using MySQL's SELECT INTO FILE might make life very simple for the attacker. Or by using BENCHMARK one can get an idea about the existence of tables (non-existing tables will yield an immediate error and thus a quick response from the server; existing tables will make the BENCHMARK command run and delay the response), and hence use brute force to try to determine the prefix.
In other words: I would not mind obscuring the actual table names at all, though preferably combined with measures to avoid getting the true names once some SQL injection bug is found (such as error pages that do not reveal the SQL statement that failed, and disabling SELECT INTO FILE for the TYPO3 database user).
On the other hand: if SQL injection is possible then an attacker can still easily get a list of the obscured table names -- just like phpMyAdmin can list them for you. But next, of course, the attacker needs a way to display that list, or use the invisible result in the very same injected SQL statement.
If no page can be fooled into dumping the query results, then the attacker might be able to insert the results into some other table. For this, the attacker should somehow combine SHOW TABLES and INSERT. TYPO3 being open source, even though the actual prefix is not known to the attacker, the attacker will know what to search for in the list of table names returned by SHOW TABLES. But I don't know if it is easy to write a SQL statement to get and actually use that list. If doable, then simply inserting the result into table MYSECRETPREFIX_TT_CONTENT would do the trick.
Using MySQL's SELECT INTO FILE might make life very simple for the attacker. Or by using BENCHMARK one can get an idea about the existence of tables (non-existing tables will yield an immediate error and thus a quick response from the server; existing tables will make the BENCHMARK command run and delay the response), and hence use brute force to try to determine the prefix.
In other words: I would not mind obscuring the actual table names at all, though preferably combined with measures to avoid getting the true names once some SQL injection bug is found (such as error pages that do not reveal the SQL statement that failed, and disabling SELECT INTO FILE for the TYPO3 database user).
December 16, 2007
14:16
Arjan,
As you have written, it's probably hard to obscure the structure to the point where all voulnerability is removed. But even getting to the point where you have to apply very advanced injection techniques to have succes, is a major leap compared to today.
I have just read a document: http://www.nextgenss.com/papers/advanced_sql_injection.pdf
And from this I bring a quote:
"Let's say our attacker wants to insert a user account for himself. Without knowing the structure of the 'users' table, he is unlikely to be successful. Even if he gets lucky, the significance of the 'privs' field is unclear. The attacker might insert a '1', and give himself a low - privileged account in the application, when what he was after was administrative access."
In my opinion - as stated in the blogpost - when TYPO3 has a SQL injection flaw somewhere, it becomes VERY voulnerable to even the most simple injection techniques, because the tables names are the same for every website using TYPO3.
It shouldn't allow for more sloppy code, but it should offer as a simple protection for those who are unable to update right away, when a flaw is discovered.
As you have written, it's probably hard to obscure the structure to the point where all voulnerability is removed. But even getting to the point where you have to apply very advanced injection techniques to have succes, is a major leap compared to today.
I have just read a document: http://www.nextgenss.com/papers/advanced_sql_injection.pdf
And from this I bring a quote:
"Let's say our attacker wants to insert a user account for himself. Without knowing the structure of the 'users' table, he is unlikely to be successful. Even if he gets lucky, the significance of the 'privs' field is unclear. The attacker might insert a '1', and give himself a low - privileged account in the application, when what he was after was administrative access."
In my opinion - as stated in the blogpost - when TYPO3 has a SQL injection flaw somewhere, it becomes VERY voulnerable to even the most simple injection techniques, because the tables names are the same for every website using TYPO3.
It shouldn't allow for more sloppy code, but it should offer as a simple protection for those who are unable to update right away, when a flaw is discovered.
December 17, 2007
16:37
Hi folks,
I just stumbled into your blog entry today, Søren, and wanted to add my 2 cents:
I'm a member of the TYPO3 Security Team and I'm happen to be the guy who found the SQL Injection issue in indexes_search you are talking about. Out of curiosity I also have found several security issues in different TYPO3 extensions this year and helped to fix them (please see the security bulletins for further details). Together with Lars Houmark I had a talk on T3CON07 about TYPO3 security where we talked about the dangers of SQL Injections and XSS.
I'm personally always cheered up when I see a new public discussion about hardening TYPO3 regarding security aspects, because I'm quite interested in this topic too. I would regret, if this discussion here would end like other discussions on the mailing lists: Everybody agrees, that security is very important and that something has to be done about it, but after a few days everyday work get's more important again and security topics are forgotten about, until the next flaw is published.
I just would like to say, that there are different ways to help maintaining the security of TYPO3. Getting a security audit + certification is one good way. Other ways are also possible. So if you want to help keeping TYPO3 secure, help the TYPO3 security team, that most of the time has more tasks than manpower.
For example, putting out a single security bulletin means more than 20 hours of unpaid work for the security team. An example to illustrate the amount of time:
*Finding the security issue: 10 hours.
*Documenting it: 3 hours.
*Fixing it by writing a patch: 5 hours.
*Reviewing the patch: 2 hours.
*Writing a bulletin draft: 2 hours.
*Discussing and improving the bulletin draft: 2 hours.
*Publishing the bulletin on typo3.org and mailing lists: 2 hours.
*Providing updated software packages: x hours.
I just want to clarify that there are people working for quite a while on fixing a security issue. Those bulletins don't just fall out of clear sky. ;-)
So if you are interested in supporting the team, please think of how you could contribute. (I guess you have to convince the team somehow that you are skilled regarding writing secure code and that you understand what security vulnerabilities are. This sounds a bit strange and blurry, I know. But well... we are talking about security here.)
Cheers,
Henning
I just stumbled into your blog entry today, Søren, and wanted to add my 2 cents:
I'm a member of the TYPO3 Security Team and I'm happen to be the guy who found the SQL Injection issue in indexes_search you are talking about. Out of curiosity I also have found several security issues in different TYPO3 extensions this year and helped to fix them (please see the security bulletins for further details). Together with Lars Houmark I had a talk on T3CON07 about TYPO3 security where we talked about the dangers of SQL Injections and XSS.
I'm personally always cheered up when I see a new public discussion about hardening TYPO3 regarding security aspects, because I'm quite interested in this topic too. I would regret, if this discussion here would end like other discussions on the mailing lists: Everybody agrees, that security is very important and that something has to be done about it, but after a few days everyday work get's more important again and security topics are forgotten about, until the next flaw is published.
I just would like to say, that there are different ways to help maintaining the security of TYPO3. Getting a security audit + certification is one good way. Other ways are also possible. So if you want to help keeping TYPO3 secure, help the TYPO3 security team, that most of the time has more tasks than manpower.
For example, putting out a single security bulletin means more than 20 hours of unpaid work for the security team. An example to illustrate the amount of time:
*Finding the security issue: 10 hours.
*Documenting it: 3 hours.
*Fixing it by writing a patch: 5 hours.
*Reviewing the patch: 2 hours.
*Writing a bulletin draft: 2 hours.
*Discussing and improving the bulletin draft: 2 hours.
*Publishing the bulletin on typo3.org and mailing lists: 2 hours.
*Providing updated software packages: x hours.
I just want to clarify that there are people working for quite a while on fixing a security issue. Those bulletins don't just fall out of clear sky. ;-)
So if you are interested in supporting the team, please think of how you could contribute. (I guess you have to convince the team somehow that you are skilled regarding writing secure code and that you understand what security vulnerabilities are. This sounds a bit strange and blurry, I know. But well... we are talking about security here.)
Cheers,
Henning
Sorry, comments are closed for this post.
Buzz is the official blog resource of the TYPO3 project. You can be part of Buzz too. If you want to blog about the achievements of your team or your personal involvement please check out our HELP section.
Suggestion-1 is called "security through obscurity", which in general is pretty useless in case of a really aggressive offender.
Suggestion-2 can already be done via DBAL (AFIR). However this wont keep an offender from injecting some XSS into the Frontend (or deface your site) and get logged-in BE-Users to view the infected page and execute whatever scripted action he like. Thus this is no meaninful option eighter.
In general:
- The openness of GPL-Software in combination with a vivid developer- and user-community resulting in discoveries and fast fixes is probably the best assurance you could get. (Thanks and cheers to the security-, release- and core-team!)
- In addition I (again) advcoate for finally getting TYPO3 security-audited and officially security certified.
links:
------
ONR 17700
http://www.on-norm.at/publish/2104.html
ISO 27001 (previous BS 7799)
http://en.wikipedia.org/wiki/ISO_27001