Heartbleed


This topic is so important that I will cover it in both, German and English. Please scroll down, for the English version. And there will be no tl;dr! If you are too lazy to read on something that important, but keep on using the Internet, you probably deserve to be hacked! Please pay special attention on what to do and what don’t to do, if you aren’t interested about my media critics part!

Es herrscht doch einige Verunsicherung bezogen auf die Schwachstelle, welche sich Heartbleed nennt. Was soll das überhaupt sein? Ich nutze diese Software – OpenSSL – garnicht! Ich muss jetzt SOFORT alle Passwörter ändern! etc.

Gerade die viel gelesene SPON zeigt mal wieder, was unsere Medien am besten können: Panik machen! Anstatt aufzuklären geht es um Verschwörungstheorien, Fingerzeigen und schwachsinnigen Aufforderungen. SPON sei hier nur exemplarisch zu nehmen – auch wenn die meiner Meinung nach den Vogel mal wieder vollends abschießen.

Das Problem

Warum Heartbleed potentiell jeden betrifft? OpenSSL ist ein sogenanntes Framework, d.h. es ist Software, die dafür gedacht ist, dass sie von anderer Software eingebunden wird. Dies wird gemacht, da es zum einen blödsinn ist, wenn jeder das Rad neu erfindet. Gerade bei Sicherheitssoftware ist das auch schwer möglich, denn mathematisch sichere Verfahren sind sehr kompliziert und die wenigsten Firmen haben das Know-How, dass für so etwas notwendig ist. Und so nutzen nach Schätzungen 2/3 der Webdienste OpenSSL für die sichere Übertragung von Daten. Deswegen ist tatsächlich so gut wie jeder betroffen.

Heartbeat ist teil des OpenSSL Frameworks. Dabei können Client und Server abfragen, ob die andere Seite über die verschlüsselte Verbindung noch da ist. Heartbleed nutzt hier einen Fehler aus, der es ermöglicht, dass ein absichtlich falsch geschriebener Client mehr Informationen vom Server übermittelt bekommt, als der Server zur Bestätigung der Verbindung (eben den Herzschlag) übermitteln sollte. Dieses xkcd-Comic beschreibt es perfekt:

xkcd 1354: How the Heartbleed Bug Works

xkcd 1354: How the Heartbleed Bug Works

Dazu ein paar wichtige Randnotizen: Dieser Angriff eignet sich nicht zum gezielten Angreifen! Der Server gibt aus, was er sonst noch im Speicher findet. Das kann ganz viel Kauderwelsch sein. Es können aber auch Login-Daten von Benutzern sein, die ebenfalls gerade auf dem Server verbunden sind. Diese Daten werden dann im Klartext übermittelt, die SSL-Verbindung verschlüsselt nur die Verbindung, das Passwort wird als Text an den Server übermittelt, dieser erzeugt dann einen Hash und gleicht den Hash mit dem im Speicher ab. So wird zwar verhindert, dass ein Hacker sich in das System hackt und alle Passwörter lesen kann – ein Hash ist nämlich etwas, dass sich leicht aus einem Klartext erzeugen lässt; man kann aber aus dem Hash nicht mehr das Passwort erzeugen.

Viel wichtiger ist aber auch das von den Medien noch so gut wie garnicht thematisierte “Reverse Heartbleed“. Genau so wie ein Client den Server austricksen kann, kann auch ein Server den Client austricksen. In dem Fall stellt sich also die Frage, ob der Client auch anfällig ist. Bei einem Angriff wird das Hauptziel dann natürlich nicht der heimisch Internet-Nutzer sein, nein, ein viel wahrscheinlicheres Szenario ist, dass damit auch Dienste wie Webcrawler die von Google, Facebook, GitHub und Co. benutzt werden, auf Server landen, welche dem Client über Heartbleed Informationen entlocken. Nichts desto trotz – es sind eben auch Clients betroffen und damit potentiell jeder Webbrowser, jedes E-Mail-Programm, jeder IM-Client, welche OpenSSL implementiert haben um ihre Verbindungen zu sichern.

Was die Medien draus machen

Was also tun? SPON macht das, was jeder gute Deutsche in einem solchen Fall erst einmal macht – statt Schadenseindämmung wird erstmal nach einem Schuldigen gesucht. Und dabei wird auf Felix von Leitner, besser bekannt als fefe, verwiesen. Der wiederum hat den vollständigen Namen der verantwortlichen Person genannt. So etwas macht man aber nicht – jedenfalls nicht als seriöses Medium – deswegen ist SPON so nett und verlinkt auch nicht auf fefe, sondern kopiert lediglich alle Zeilen, in denen der Name nicht vorkommt, und um dem ganzen die Krone auf zu setzten, wird der Name nicht Redaktionell geändert – nein! Er wird redaktionell gekürzt. Vorname und erster Buchstabe des Nachnamens. Punkt. Und ich meine, das reicht ja auch, immerhin funktioniert das ja auch bei den Panzerknackern – die haben eine Augenbinde und keiner weiß mehr, wer sie sind… fefe wird natürlich nicht verlinkt. Wohl aber die Quelle aus der fefe das hat, damit der heimische Hobby-Detektiv selbst mal ausprobieren kann, ob er das Zeug zum Ermittler hat, und herausfinden kann, was nach dem “S.” noch alles folgt…

Aber: Ein Deutscher war’s. Und sehr wahrscheinlich absichtlich. Schlagzeile. Yey! Auch wenn ich fefe gerne lese, ist und bleibt auch er ein privater Blogger und auch kein Sicherheitsexperte, sondern ein Bugfinder, wie er selbst schreibt:

Normalerweise ist es nur meine Aufgabe, Bugs zu finden. Ich bin nicht dafür zuständig, dass die auch gefixt werden.

Aber in den Medien ist ja heute jeder Sicherheitsexperte, der seinen eigenen Blog aufsetzten kann. Viel weniger als ein Sicherheitsexperte ist er allerdings Journalist und leider auch keine objektive Quelle, was man schnell in seinem Blog merken wird. So ist der Schluss von T-Systems auf den BND ein kurzer und gleich wird der Verantwortliche zum Auftragsspion. Dumm nur, dass besagte Person, als sie den Patch geschrieben hat, selbst noch Student war! Ich bin selbst Student und weiß daher auch, wie in der Uni das Programmieren gelehrt wird; als Mensch ohne mehrjährige Programmiererfahrung kann es also durchaus passieren, das man nicht darauf achtet, ob man ein malloc so absichert hat, dass solche Schwächen garnicht erst auftreten – zumal OpenBSD ein eigentlich sehr sicheres eigenes malloc hat, welches OpenSSL aus eventuell auftretenden Performance-Gründen jedoch nicht nutzt (Zitat von mir übersetzt):

Vor Jahren haben wir Exploit-Abschwächungsmaßnahmen in malloc und nmap aus libc implementiert, sodass eine große Anzahl an Bugs einfach aufgedeckt wird. Solche Speicherzugriffe würden sofortige Abstürze herbeirufen, bis hin zum Core Dump, sodass der Bug analysiert und von vornherein gefixt werden kann.

(…)

Aber zur selben Zeit hat OpenSSL einen Wrapper geschrieben, sodass malloc und free den Speicher selbstständig verwalten, und so das sichere malloc aushebelten.

(…)

OpenSSL wird nicht von einem verantwortungsvollem Team entwickelt.

(Theo de Raadt)

De Raadt ist extrem sauer deshalb, und gibt dem ursprünglichen Entwicklerteam (welches übrigens im Audit auch den Heartbleed-Bug nicht gefunden hat) die Schuld. Jetzt ist das Gegenargument, dass der mittlerweile dissertierte Entwickler sich auch ausgiebig mit Sicherheit auseinander gesetzt hat und immer noch auseinander setzt. Dem widerspricht dann aber auch, dass jemand, der sich regelmäßig selbst an Bugfixes beteiligt, absichtlich eigene streut. Zumal er als Student eben auch noch nicht für T-Systems gearbeitet hat. War er also so berechnend, dass er seinen Wunsch, beim BND zu arbeiten dadurch Nachdruck verleihen wollte, das er eine Schwachstelle in Sicherheitscode bringt, damit er dies 2 Jahre später der T-Systems demonstrieren kann um hier dann einen Job als Systemarchitekt zu bekommen?

Für eine seriöse Zeitschrift sollte das nun doch ein bisschen sehr weit hergeholt sein. Allerdings kopiert eine seriöse Zeitschrift auch nicht Meinungen von Verschwörungstheoretikern, wie fefe, sondern stellt (zumindest parallel davon) auch eigene Recherchen an. Was uns das über SPON sagt? Ich möchte aber nicht schon wieder in Medienkritik ausarten und zu technisch wollte ich es auch nicht werden lassen. Die wichtige Frage ist jetzt sicherlich: Was soll ich tun? Und was soll ich nicht tun?

Was man nicht tun sollte!

Auch hierzu liefern die deutschen Medien mal wieder nichts sinnvolles. Sofort alle Passwörter ändern lautet nur erschreckend häufig die Schlagzeile. Um einen Freund zu Zitieren:

Das ist ja eine klasse Idee.. Es geht bei der Lücke darum, dass die Daten abgefangen werden können und da logg ich mich jetzt ein und änder mein Passwort? Wie sinnvoll…

Aber die geballte Kompetenz von Medien wie SPON wissen es auch hier natürlich besser:

Für alle wichtigen Web-Dienste, die man nutzt, sollte man die Passwörter ändern.
Haben Sie das schon getan? Dann können Sie hier aufhören zu lesen.

Haben Sie das noch nicht getan? Dann könnten Sie jetzt, statt weiterzulesen, damit anfangen

Und weiter heißt es:

Sie [können] es wie der Chefredakteur des Fachmagazins “Heise Security” [machen] und bekennen sich dazu, “eher faul als ängstlich” zu sein

Das klingt nicht nur negativ, das ist auch so gemeint. Trotzdem – wenn ich heute nach bekanntwerden der Lücke, und nachdem jetzt jeder Hinz und Kunz, der zwar die nötige Kriminelle Energie, nicht aber das Know-How hat, solche Lücken selbstständig zu finden, jetzt weiß, wie er an Zich Passwörter kommt – mein Passwort ändere, und mich damit dann in Sicherheit wäge, bin ich wohl mit der dümmste Trottel, den es gibt. Solange nichts gefixt ist, ist auch jedes ändern des Passwortes quatsch – insbesondere wenn jetzt potentiell jeder darauf lauscht, und jedes Einloggen und Passwort-Ändern dafür sorgt, dass genau diese Informationen im Speicher stehen, der mithilfe von Heartbleed ausgelesen wird! Und dagegen hilft dann auch nicht, dass man ein möglichst sicheres Passwort nimmt, und dieses – nach SPON-Empfehlung – über einen Passwort-Manager verwalten lässt. Verdammt Clever!

Was man tun sollte!

Nein, das Beste was man jetzt tun kann, ist tatsächlich abwarten! Vor allem: Sich jetzt nicht überall einloggen, wo man einen Account hat, nur um das Passwort zu ändern. Idealer Weise hält man seine Logins jetzt erstmal auf aller niedrigstem Niveau, denn bin ich nicht eingeloggt ist auch mein Passwort nicht auslesbar! Das wird nicht bei allen Diensten gehen, aber das Risiko wird so sicherlich vermindert. Hinzu kommt: Nicht jeder Dienst ist betroffen. Die Dienste prüfen gerade alle, ob die Schwachstelle auch sie trifft – und mehr noch – viele andere tun das ebenfalls für ihre Dienste. Wer betroffen ist, und wer nicht, sollte also nach und nach für die großen Dienste lückenlos nachvollziehbar sein. Mashable führt eine Liste von Diensten mit Hinweis darauf, wann das Passwort geändert werden sollte. Wenn man den eigenen Dienst nicht findet, kann man auch dieses schnieke Werkzeug nutzen, welches testet, ob eine URL betroffen ist. Nun liegt es an diesen Diensten, den Patch einzuspielen, der das Leck schließt. Viele Dienste geben offen Auskunft darüber, ob sie betroffen sind, oder nicht. Wenn man zu seinen Diensten nichts findent, hilft es eventuell beim Support anzufragen. Bei mir flattern gerade täglich Mails ein, von Diensten, die darüber aufklären, dass sie Schritte eingeleitet haben, und was als nächstes zu tun ist.

We have taken steps to secure our infrastructure against this vulnerability by patching our servers and updating our SSL certificates. As an extra precaution we recommend each of our customers take a moment to reset their passwords.

Erst jetzt ist es an der Zeit, sich einzuloggen und sein Passwort sofort zu ändern. Denn hat es jemand erschnüffelt, kann er es auch nach dem Update natürlich weiterhin nutzen! Eine Passwort-Änderung kann allerdings nicht mehr abgefangen werden. Für alle Nicht-Betroffenen Dienste gilt übrigens: Gibt es eine Recover-Funktion? Kann diese per Mail abgerufen werden? War der Mailserver betroffen? –> Es sollte klar sein, was in dem Fall zu tun ist. Außerdem: Habe ich das Passwort auch wo anders benutzt? War dieser andere Dienst betroffen? –> Auch da muss ich euch hoffentlich nicht erklären, warum eine Passwortänderung notwendig ist.

Wie man sich auch in Zukunft besser absichert

Abschließen möchte ich damit, dass ihr doch, anstatt SPONs Aufforderung zu folgen und einen Passwort-Manager zu benutzen – der ebenfalls nichts gebracht hätte – doch lieber dazu über gehen solltet, 2FA zu benutzen. Ich hatte schon mal drüber berichtet, und immer mehr Dienste bieten dies an!

Neben Battle.net (eines der ersten Dienste, die ich kenne), sind nun auch Amazon, Apple, eBay, Microsoft, LinkedIn, PayPal, Tumblr, Twitter, WordPress, und Yahoo! Mail sind nur einige der neu dazu gekommenen. Alle Google-Services, App.net, Facebook, Dropbox und Evernote oder GitHub sind dagegen fast schon alte Hasen im 2FA-Implementieren.

Dabei wird eine App – und das kann auch eine einzige sein (etwa der Google Authenticator) auf dem Handy installiert. Für den Login wird jetzt neben dem Passwort auch eine 6-Stellige Zahl verlangt – genau so wie es TAN-Listen und Generatoren für Banken machen, oder aber Geldautomatien, die neben der Karte auch noch eine PIN abfragen. Diese Zahl wird alle 30 Sekunden von der App neu generiert – man kann sich nur einloggen wenn man sein Handy dabei hat; das Passwort alleine reicht nicht mehr aus, und ist damit auch für den Angreifer unbrauchbar. Zur Sicherheit kann man sich parallel auch eine TAN-Liste generieren lassen, für Fälle, wo man sein Handy nicht dabei hat, oder falls dieses mal kaputt geht, oder gar verloren geht oder gestohlen wird. Die Zukunft gehört sicherlich den 2FA oder gar den MFA-Verfahren die noch weitere Details abfragen.

Sicherlich nicht gehört die Biometrie dazu – auch hier sehen fehlgeleitete Menschen immer wieder die Lösung und Alternative zu komplizierten aber sicheren Passwörtern. Man stelle sich nur mal vor, die biometrisch relevanten Punkte des Dauemnabdrucks wären per SSL versendet worden – der Daumenabdruck ist für alle Zeit hinfällig, der Angreifer wird immer und ewig die Identität des Opfers annehmen können, und dieses wird wahrscheinlich immer wieder aufs neue vor Behörden darlegen müssen, warum sie es nicht gewesen sein kann…


There has been some uncertainty (at least in Germany) concerning the vulnerability called Heartbleed. What is Heartbleed? I can’t be affected, as I don’t us this OpenSSL software! OMG, I have to change all my passwords NOW!, etc.
One of Germanys most read online magazin, SPON, is a perfect example of what media can do best: to panic! Instead of elucidation SPON spreads conspiracy theories, does some finger pointing and calls for irrational behaviour.

The Problem

Hartbleed is potentially affecting everyone of us, because OpenSSL is a framework. This means it’s a piece of Software that is written so it can be used in other peoples Software. Frameworks are used because on the one hand it is crazy if everybody reinvents the wheel. And especially security software poses a special challenge as it is hard to invent mathematically correct and secure methods that meet the demands of such software. Most companies won’t even have the Know-How that is needed. This is why probably around 2/3 of all web services have implemented OpenSSL for secure internet connections. And that is why probably everyone is affected by it.

Heartbeat is part of the OpenSSL framework. It allows Clients and Servers to contact the other side and ask if the secure connection is still up and running. Heartbleed uses an error in this implementation, which makes it possible for deliberatly wrong written Clients to get additional information from the Server, than the information that is needed to approve the secure connection. This xkcd Comic is a prefect explanation of what is going on:

xkcd 1354: How the Heartbleed Bug Works

xkcd 1354: How the Heartbleed Bug Works

Nota bene: This attac is not a targeted attac szenario. The Server just replies with whatever else is in the memory at that moment. That of course is much gibberish. But also Login-Data from other users, that are connected to the server right now. The data is transfered in clear text, as SSL only crypts the connection, not the content. Passwords that are transmitted are transmitted clear-text to the server, the server then creates a Hash and compares this Hash to the one saved in its database. This will save the database from being hacked, as a Hash is easy to create from the clear text, but it is nearly impossible to create the cleartext when given a hash. But the password will have to be in the memory for this, and that is what Heartbleed uses.

But the mostly ignored “Reverse Heartbleed” is not less important. As the client is able to trick the server, also a server can trick a client. And for this scenario one would also have to check all Clients for the vulnerability. For an attack scenario one would probably not attack the home user, but rather automated services as e.g. web crawlers which are used by Google, Facebook, GitHub and Co. They could land on a server that will try to get the client to tell him more than they would want to. Nevertheless – also cleints are affected and thus potentially every web browser, every email client and every IM client, which uses OpenSSL to implement secure connections.

What media makes of this

What to do? SPON does, what every good German citizien would do – instead of fighting the problem, we’ll be looking for the one responsible! Referencing Felix von Leitner, better known as fefe, SPON reveals that fefe has revealed the name of the one responsible on his blog. But as serious media doesn’t simply print a clear name of someone, SPON just copies every line that doesn’t have his name, and to crown a tooth the name is not editorially changed. No, much better – it is editorially shortened. Given name, and the first letter of the family name. Dot. As you might recall this works as well for the Beagle Boys – no one recognizes them without their black eye masks. Of course fefe is not being linked. Instead SPON links to the source that fefe used to find out the name of the one responsible, so that every amateur detective at home can try for himself if he has what it takes to be a good investigator…

But: It was a German guy who possibly did it on purpose. Now that’s a catchline. Yeah! I have to confess I do read fefe a lot and like most of his articles. But he is a private blogger and no security expert. As he describes on his blog he’s merely more than a bug finder himself (quote translated by me):

Normally my task is just to find bugs. I’m not even responsible for fixing them.

But as for our media, today everybody is a security expert who just knows how to install his own blogging software. But fefe is even lesser an journalist than he is a security expert, and he is especially no objective source as everyone reading his blog will surely realize. So his conclusion from T-Systems to the BND is found fast and before you know it, the one responsible has become a a spy. The only problem is that said person didn’t work for T-Systems as he wrote the patch – he was a student. I myself am a student and I know how programming is thought at university; if you don’t have much experience it is extremely possible that you don’t secure your malloc so that said problem wouldn’t appear. And one also has to take into consideration that OpenBSD has a secure malloc which should have prevented this, but wasn’t implemented by OpenSSL because of possible performance issues (Source):

So years ago we added exploit mitigations counter measures to libc malloc and mmap, so that a variety of bugs can be exposed. Such memory accesses will cause and immediate crash, or even a core dump, then the bug can be analyed, and fixed forever.

(…)

But around that time OpenSSL adds a wrapper around malloc & free so that the library will cache memory on it’s own, and not free it to the protective malloc.
(…)
OpenSSL is not developed by a responsible team.

(Theo de Raadt)

De Raadt is extremely pissed because of this, and holds the original developer team responsible (which also didn’t find the Heartbleed bug when auditing the patch). The counter argument is that the today dissentient developer did a lot research on security issues and still does. But is it reasonable that someone who spends a lot of time to fix bugs on a regular basis does implement one on purpose? Especially taking into consideration that he wasn’t wokring for T-Systems, when he patched the system. Was he really planning to work with the BND and just to one day proof himself he added a security issue so that after two more years time he could convince T-Systems to make him a system architect?

For a serious news magazine this should be far fetched. But what does it say about the seriousness of a magazine if the only thing they do is to copy a person who is openly known keen on conspiracy theories without even checking any facts? Well, I don’t want to yet again critizise our media and I also didn’t want to become to technical. So the most impornant qestion now is what to do, and what not to do.

What not to do!

Again, nothing that would make any sense can be found on our (German) media. Change all your passwords NOW! is what most of them suggest. But to quote a friend of mine (translation by me):

That’s a cool idea… There’s a vulnerability that allows to capture data and now I should log in and change my password? That makes sense…

Still the accumulated knowledge of SPON will tell you

You should change all passwords for every important Web-Service.
Did you do that? Than you may stop reading.
Didn’t you do that? Then best you stop reading now and start changing your passwords.

And further:

Of course you could do it like the chief editor of “Heise Security” and rather commit to being lazy than scared, but…

That does not only sound negative, it’s meant that way. But – if I today, after the general public knows about this bug, and every petty thieve that has enough criminal energy but not the knowledge on how to find such bugs himself, now knows how to obtain massive login data, if on this given day I login and change my password, and think “Hey, now I’m save”, than I must be pretty stupid. As long as nothing is fixed, every change of a password is bullshit. Especially now that potentially everybody could sniff your data, and every log in will have the effect that your login information will be in the memory that can be read out by Heartbleed. It won’t even help if you choose a secure password or use a password manager, as SPON suggests. That’s not clever at all…

What should I do?

Best thing you can do is to wait. Don’t log in everywhere you have an account and change it! Ideally you don’t log in at all, into any service. If you’re not logged in, your password is not on memory and none can read it. It probably wouldn’t be possible to not log in into any service you work with, but keep it low. Also take into consideration that not every service is affected. In the next days every service will check for the vulnerability – and in addition to that also other people do such checks and document them. So it’ll become obvious to everyone who’s affected and who isn’t. Mashable is keeping track of some of the affected services, with information on when to change the password. If you don’t find your service there, you could also use this nifty tool, that tests, if your provided URL is affected. It’s then up to the services to fix the bug. Many services will provide you with information on their status. If you cannot find information to a service that is important to you, ask their support. As for me, I already got some mails that state what to do next. E.g.

We have taken steps to secure our infrastructure against this vulnerability by patching our servers and updating our SSL certificates. As an extra precaution we recommend each of our customers take a moment to reset their passwords.

Only now has the time come to log in and change your password, because if somebody sniffed your credentials he could also use it after the fix. But he cannot sniff any password changes anymore. If your service on the other hand informs you that it isn’t affected, think about the following: Does it provide you with a password recover function? Is this one sending your password via mail? Was your mail server affected? –> I hope it’s clear what you’ll have to do. Also think this way: Did I use my password somewhere else? Was that service affected? –> I hope that also for this scenario I do not have to tell you why you’ll have to change your password.

How to protect yourself from further bugs

I want to close my blog entry with a good tip. Don’t listen to SPON and install a password manager. It might make your life easier, but it will not safe you from such bugs. Instead use 2FA. I already blogged about it and more and more services offer 2FA!

Next to Battle.net (one of the oldest Services I know using 2FA) this now also includes Amazon, Apple, eBay, Microsoft, LinkedIn, PayPal, Tumblr, Twitter, WordPress and Yahoo! Mail. Of course all Google-Services offer it as well, and services such as App.net, Facebook, Dropbox, Evernote or GitHub are already 2FA-Veterans.

When you use 2FA, an App is installed on your smart phone – and you can use just one (e.g. the Google authenticator). Now if you log in, next to the password the service will require a 6-digit number, as you might have seen it with TAN lists or TAN generators for online banking, or at ATMs, which not only require a banking card but also a PIN. This number is updated every 30 seconds by the app, so you can only log in if you have your mobile phone with you. Of course there’s also the possibility to print out lists of numbers for emergency cases where you don’t have your mobile phone with you (or the battery died), as well as for cases when your phone breaks or is lost/stolen, etc. I consider 2FA or even MFA methods that use more than two factors for login to be the future of secure logins.

As for biometrics: Just imagine what would have happend if anybody used to send biometric information via SSL to a server and someone else got them. Now for instance your thumb is unusable anymore and other people can pretend to be you, while you would propably be accused over and over again and have to proof to the authorities that you couldn’t possibly have done what you are accused of.

Advertisements

Please comment. I really enjoy your thoughts!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s