Today I would like to write something about the handling of TYPO3 Security Issues from a perspective of a TYPO3 agency.

Nowadays, due to the great work of the TYPO3 Security Team, some security holes have been found in the TYPO3 Core and a lot of them in third party extensions. You may have the impression that this happens more often than ever before.

But this does not make TYPO3 less secure than other Systems! Why?

Software has errors because Software is written by humans.

Simple as it is, this applies to every system (WordPress, Drupal, Microsoft Windows 7, <insert a software product here>).

It is not a Security problem if holes are found, it is a problem if they are present but not found. Keep this in mind while reading the next lines.

It feels natural to me, that if a security hole is found and a fix is ready, a Security Bulletin is published to inform all of us. This gives us as an agency – and even more important our customers – the assurance and faith in the Software we love.

I sometimes hear the argument that it might not be good for the TYPO3 brand if the security bulletins are published so often because this could make customers think that TYPO3 is insecure.

To be honest, I do not understand that argument. It is the other way around! Isn’t it a major advantage that we have people dedicated to take care for security, dig into code to find problems and report the findings to the community? Isn’t this one of TYPO3′s unique selling proposition?

I think the answer here must be: Yes!

To avoid customers from being afraid that TYPO3 is insecure, one “solution” that is often proposed: Release Security Bulletins only once in a certain period – for example once a month. Remember the sentence from above? “It is not a Security problem if holes are found, it is a problem if they are present but not found.” – In my eyes a bulletin must be published directly after a fix is ready.

I also think that in all the above we find the answer to the question how we should communicate TYPO3 Security Bulletins to our customers:

1. Inform your customers
   Inform them on the security policy the TYPO3 project has. Explain that this is a USP, not a threat!
2. Help your customers
   Keep them informed if a security hole is found and the installation of the customer is affected. Also inform the customers if their installations are not affected. Explain your customers their options. Install extension updates and TYPO3 Core updates if needed. Make sure you have a contract in place that covers theses tasks before you start a project.
3. Walk away
   If you have customers who think TYPO3 is less secure than other systems only because of the amount of Security Bulletins: Walk away. They’re not the kind customers you would like to have. Sounds sad and this is a hard decision, but you will not regret that you made that decision – believe me.

What do you think? What do you do in your daily work when it comes to security? I’d love to hear from you, please leave a comment.

A lot of hacking stuff  went on this year and of course some of the hacked websites run TYPO3. I’m not worried to much about that, it’s somehow part of the “game” in the internet.

What annoys me are how some free-riders report about such incidents just to get some clicks for their “sensational” fairy tales. But there are also blog posts which are written with a good intention, but seem to lead to the wrong conclusions. What stays in peoples mind are the headlines, the catchy cant like “Google Conditional Hack”.

What’s wrong about this? It can be easily be assumed that all hacked websites redirecting to viagra selling sites have been compromised exploiting the always the same vulnerabilities. “Google Conditional Hack” does sound like ILOVEYOU. But while the the famous Windows worm exploited exactly one vulnerability in the operating system, “Google Conditional Hack” is just a rough observation of not intended website behavior and tells absolutely nothing about what vulnerability has been exploited on the respective website.

While there were some XSS vulnerabilities on famous platforms like twitter which were exploited to spread autonomously like a worm, when it comes to “normal” websites it is different. Because the websites differ enormously. Even TYPO3 sites. There are websites running unpatched versions of TYPO3 3.6 but also (hopefully) many running the latest version. And there are over 5000 extensions in TER and a lot more specifically developed for a certain purpose. No TYPO3 website is like the other, also the hosting environments differ.

So people with the goal to search optimize their cialis shop by putting some links on “external” websites, search for different problems on different websites. If they find something, they put the links there and search for another vulnerable site. Respectively every entry door (we know about) for a TYPO3 website affected by the ”Google Conditional Hack” was different.

Conclusion

When it comes to websites (or TYPO3) it makes sense to give names to certain vulnerabilities (e.g. jumpurl issue). It also makes sense to report found vulnerabilities to the security team. But it makes no sense to report viagra links (or base64 encoded php code which creates such links) to us.

We get such links regularly directly from the vendors

My impression is that it is not widely known, that you can introduce major security problems in your TYPO3 installation if you do not properly take care of user input which is accessible through TypoScript.

In this post I will explain what user input is and how you have to deal with it within TypoScript.

User Input

So what kind of user input is accessible through TypoScript? Let’s look at the getText data type which you can access through “stdWrap.data”. You can do something like this:

1
2

lib.user = TEXT
lib.user.data = GP : stuff

“GP” is short for GET/POST. You can access URL parameter values with it.

E.g.: http://your.site/?stuff=user-input
“user-input” will be the value for “lib.user”

In this example user input is something every website visitor can enter and/or modify.

This is also possible:

1
2

lib.user = TEXT
lib.user.data = page : title

In this example “lib.user” holds the value of the title of the current page. In this case the user input is provided by your website editors.

Another example for user input by website editors is this:

1
2
3

lib.menu = HMENU
lib.menu.1 = TMENU
lib.menu.1.NO = 1

I guess something like this is found in pretty much every TYPO3 installation, because it creates a menu out of the pages in the pagetree

Why is User Input dangerous? Bad Examples:

User Input is dangerous, because you (as a website integrator) have no control over what exactly a user decide to provide as input.

Let’s revisit our “lib.user” example from above and extend it a little bit, so that the URL parameter value is shown on our website:

1
2
3
4
5
6
7
8
9
10
11

lib.user = TEXT
lib.user.data = GP : stuff
lib.user.wrap (
  Search:
  <form type="get">
    <input name="stuff" value="ǀ" />
    <input type="submit" value="GO" />
  </form>
)
page = PAGE
page.10 < lib.user

And now access your page with the following URL:
http://your.site/?no_cache=1&stuff=”><script>alert(“XSS”)></script>

You have introduced a Cross Site Scripting vulnerability (XSS) in your TYPO3 installation by only using TypoScript.
(If you want to test this use Firefox, because at least Safari and Internet Explorer have a XSS protection which prevents the JavaScript from being executed)

Now look at this example:

1
2
3
4
5
6
7
8
9
10
11
12
13

lib.breadcrumb = CONTENT
lib.breadcrumb {
  table = tt_news
  renderObj = TEXT
  renderObj.field = title
  select {
    pidInList = 5
    andWhere {
      data = GP:tx_ttnews|tt_news
      wrap = uid=|
    }
  }
}

This TypoScript snippet is used to show the title of the currently shown tt_news article in the breadcrumb. DON’T DO THAT LIKE THIS!

It introduces a SQL Injection vulnerability, which is one of the most severe security issues you can have on your website. Website visitors can now forge SQL and provide it as a URL parameter to get everything out of your TYPO3 installation.

How to avoid such mistakes?

Let’s fix the XSS vulnerabilities first by adding the following line:

1

lib.user.htmlSpecialChars = 1

This line is crucial here. It escapes encodes the user input for HTML output.
If you do not want your editors to enter arbitrary HTML and JavaScript code on your TYPO3 installations (which is recommended) fix your TypoScript code for menus:

1

lib.menu.1.NO.stdWrap.htmlSpecialChars = 1

And of course do not allow SQL Injections by transforming the user input to an integer, before passing it to the SQL query by TypoScript:

1

lib.breadcrumb.select.andWhere.intval = 1

Jigal van Hemert wrote an excellent article on how to escape user input for TypoScript SQL queries, if the values are not supposed to be integer but strings.

Conclusion

It might tricky sometimes, especially when it comes to more complex TypoScript. But if you respect the following two rules, you should be on the safe side.

1. Every time you use the stdWrap property “data”, “dataWrap” , “insertData” etc. think about where the data comes from and where it goes.
2. Escape the data properly depending on where the data goes (htmlSpecialChars for HTML output, intval or marker usage for SQL)

Happy and safe TypoScripting!

But this will not be the end. As Ekki mentioned in his last post: “never say never”; I decided to revive it.

Working on web application security and especially on TYPO3 security topics for several years, I learned a lot. I learned about the different types of vulnerabilities and attack vectors, how Black hats exploit these and how developers, administrators and users care more or less about creating or running secure web applications. As a member of the TYPO3 Security Team but especially as it’s leader, I’m frequently being asked questions like these: “Is TYPO3 secure?”, “Is this really a vulnerability?”, “How can I avoid such vulnerabilities?”, “What do I need to do to run a TYPO3 website securely?” To be honest, sometimes I’m annoyed giving the same answers again and again, but on the other hand it shows me, that the work of the TYPO3 Security Teame, has created a broad attention to this topic. When people start asking questions, they start to care and this is good. This is why I and my fellows in the Security Team always try to passionately answer every question we’re asked with the goal to educate and rise awareness continuously.

I want to stress that I do not want to blame anyone for not knowing something; this would be silly anyway. Nobody (including myself of course) knows everything. But everyone can learn. And I can tell you, security is not only an important but an exciting matter. If you engage in it, you will definitely benefit in many ways. OK, there is one downside: The more you know, the more you can fear. But this is how life is in general. But the more people know, the more they care. And this is a good start for a change to the better. So be encouraged to learn more on security, I will try to help you in that. Then not only you but all of us will benefit from it.

So instead of being annoyed, I would like to share the knowledge I gained and spread it using a platform that targets more people than only the one who is asking. At least I hope this is working out like that and many people are willing to educate themselves or find some helpful information in what I write.

In this blog I will write posts in English but also in German, depending on my mood but also depending on the subject. I already have many ideas what I can write about; (of course) TYPO3 related topics but also more general ones. I’m really looking forward in doing so.

I’m of course curious about your opinions. What are you interested in? What do you expect from reading this blog?

Als Mitglied des Security Teams habe ich Zugang zu vielen interessanten Informationen, die aber nicht veröffentlicht werden können. Und dabei rede ich nicht von neuen, noch nicht behobenen Lücken, sondern vielmehr von Dingen wie aufkommenden neuen Feature-Ideen (bzw. Diskussionen darüber), umgekehrt aber auch über meiner Meinung nach wünschenswerte Security-Zusatzeigenschaften in Frontend wie Backend, und vieles mehr.

Ein Außenstehender könnte all das viel problemloser kommentieren, ich kann es eben nicht. Was bleibt? In letzter Zeit vor allem das nachträgliche Erläutern veröffentlichter Bulletins, auch dies naturgemäß nur “an der Oberfläche”. Spannender: Sonstige Hintergründe, z.B. in Interviews mit Leuten auch außerhalb des Security Teams. Wobei dies natürlich prümär von den Interviewpartnern abhängt, und trotz viel bekundeten Interesses haben die meisten dann doch nie Zeit für sowas. Auch dies liegt sicherlich – zumindest unter anderem – an der etwas sperrigen Thematik.

Der langen Rede kurzer Sinn: Ich habe mich entschieden, diesen Blog zunächst “auf Eis zu legen”, also nicht weiter zu füttern.

“Zunächst”? Man soll ja bekanntlich nie “nie” sagen… Vielleicht ändert sich die Situation ja irgendwann dahingehend, dass das Ganze besser funkioniert.

Bis dahin: Danke für’s Vorbeischauen, und “take care”!

P.S. Direkt zu Erreichen bin ich weiterhin auch über die naw.info Website bzw. die dort angegebene Email-Adresse.
Oder natürlich per Kommentar auf dieser Seite =)

Gleichartige Probleme (und damit ebenfalls in der Kategorie “schwerwiegend”) wurden in einem weiteren Security Bulletin (TYPO3-20080515-2) auch für die “air_filemanager” Extension gemeldet.

Da Remote Code Execution bei Hackern sehr beliebt (weil leicht auszunutzen) ist, scheint mir das verstärkte Auftreten solcher Fehler Grund zur Sorge zu sein… Vielleicht macht es Sinn, Entwickler hier zu unterstützen und dieses Thema gezielt in den Coding Guidelines zu erläutern. (Oder an dieser Stelle anhand eines Beipiels wenigstens mal zu erklären.)

Hier die gesamte Übersicht:

• TYPO3-20080513-1 wt_gallery: XSS, Path Traversal, Information Disclosure (kritisch)
• TYPO3-20080513-2 pbsurvey: XSS (medium)
• TYPO3-20080513-3 rlmp_eventdb: XSS (medium)
• TYPO3-20080513-4 ke_stats: SQL Injection und XSS (kritisch)

Ist dies nun der Beginn von regelmäßigen “Patch Days”? Nein, allerdings wurde die Veröffentlichung bewusst gebündelt, um den betroffenen Admins das Leben wenigstens etwas zu erleichtern.

Henning Pingel, Co-Leader des Security Teams und Koordinator der Bulletins, wies zudem darauf hin, dass es sich in allen Fällen nicht um offiziellen TYPO3-Code, sondern um Dritt-Extensions handelt – und dass angesichts der weiterhin stark ansteigenden Zahl solcher Extensions auch künftig mit dem Auftreten solcher Fehler zu rechnen sein wird.

Im gleichen Zuge scheint sich momentan die Tendenz zu verstärken, dass wichtige Extensions in die offizielle Pflege durch das TYPO3-Projekt übernommen werden sollten – sicherlich eine gute Idee!

Auch hier wurden Cross Site Scripting-Möglichkeiten identifiziert, Hauptproblem aber ist: In Formularen mit Datei-Upload können beliebige Dateitypen hochgeladen werden. Also z.B. auch auch ausführbare PHP-Dateien! Dies führte zu der Einstufung des Problems als “kritisch”.

Im offiziellen Bulletin wird allen Anwendern dringend empfohlen, umgehend auf die korrigierte Version (4.0.4 und höher) zu wechseln, die von Hersteller (Typoheads GmbH) bereitgestellt wurde.

Die Autoren Alexander Kellner und Mischa Heissmann reagierten prompt und stellten – abgestimmt mit dem offiziellen Security Bulletin – eine korrigierte Version (1.1.10) zur Verfügung. Für Verwirrung sorgte dabei, das praktisch zeitgleich auch ein Feature Upgrade (1.2.x) veröffentlicht wurde (welches aber ebenfalls den besagten Fehler nicht mehr enthält.)

Beide sind mit SQL Injection Problemen behaftet, das Problem daher als schwerwiegend eingestuft.Und: Beide Extensions sind heute überflüssig, da die Funktionalität bereits in tt_news enthalten ist. Wer also noch pmk_rssnewsexport oder cm_rdfexport verwende, sollte unverzüglich auf tt_news umstellen.

Weitere Informationen gibt das offzielle Bulletin.