Dariusz on Software

Recently I've registered an account on twitterfeed.com site that forwards blog RSS-es to Twitter and Facebook accounts. Headers of incoming mail attracted my attention:

Return-Path: root@mentiaa1.memset.net
(...)
Received: from mentiaa1.memset.net (mentiaa1.memset.net [89.200.137.108])                                                                                    
 by mx.google.com with ESMTP id 11si7984998ywh.80.2010.02.12.06.24.18;                                                                                
(...)
Received: (from root@localhost)                                                                                                                              
 by mentiaa1.memset.net (8.13.8/8.13.8/Submit) id o1CERcGq004355;                                                                                     
(...)
From: noreply@twitterfeed.com                                                                                                                                
(...)

Interesting parts are bolded out. As you can see registering e-mail was sent from root account. Probably the same user id is used for WWW application. That means if you break the WWW application you can gain control over whole server.

The preferred way to implement WWW services is to use account that has low privileges (www-data in Debian) because breaking the service will not threat whole server.

I assume you want to encrypt some files using your public GPG key. I'll focus on simplicity rather than completeness (minimal steps required to implement encryption).

First you have to generate key pair:

$ mkdir -p ~/.gnupg
$ gpg --gen-key

Then see your new key ID and export it to public key storage:

$ gpg --list-keys # get KEY_ID from output
$ gpg --keyserver "hkp://subkeys.pgp.net" --send-key <KEY_ID>

On remote machine import the key and make it trusted (to avoid warnings during encryption):

$ gpg --keyserver "hkp://subkeys.pgp.net" --recv-keys <KEY_ID>
$ gpg --edit-key <KEY_ID>
> trust

Then you can used this key to encrypt files and delete original (if needed):

$ gpg -r <KEY_ID> --output <FILE>.gpg --encrypt <FILE>
$ rm <FILE>

And the decryption (on host where private key is stored):

$ gpg -r <KEY_ID> --output <FILE> --decrypt <FILE>.gpg

"Wakacje przedłużone o dwa tygodnie" - tego typu komunikat ostatnio zaczął pojawiać się masowo na FB. Jest świadomie (a także nieświadomie) propagowany przez użytkowników FB.

"Nieświadoma" część przekazywania linka polega na wykorzystaniu "click hijaking" przez autorów strony. W poniższym artykule pokazuję jak się zabezpieczyć przez nieświadomym rozprzestrzenianiem tego typu "niechcianych lajków" przez FB.

W momencie klikania na krzyżyk zamykający okienko użytkownik klika w rzeczywistości na ukryty przycisk "Recommend" facebooka dodając tym samym nieświadomie komentarz na swoim profilu. Moment zamknięcia reklamy jest momentem rozprzestrzeniania "wirusa".

Podejrzane jest już to, że trzeba kliknąć dwukrotnie by zamknąć okienko z reklamą:

Przy kliknięciu na OK i podwójnym kliknięciu pojawia się odwołanie do API FaceBooka z addcomment (wyciągnięte poniżej). Jak widać referrer jest ustawiony tak, by pozwolić uruchomić się skryptom z pominięciem zabezpieczeń FB (i przeglądarki):

fb_dtsg=AQHWyAnE_eO7&href=https%3A%2F %2Fm.facebook.com%2Fgroups%2F558804457581467%2Fpermalink%2F559754444153135 %2F%3F8ff89024083642ad88c9c4b47ad5d692&ref=&nobootload=&action=recommend&comment=& user=100006627825399&a=1&dyn=7wfGbwKBWo2vw&req=1&locale=fr_FR& ttstamp=2658172871216511069951017955&__rev=1383064 Oto wyjaśnienie jak mechanizm działa wykonane przy użyciu narzędzia NoScript (które czuwa nad tego typu nadużyciami):

Jak się chronić?

Można wykorzystując narzędzie NoScript zainstalowane poprzez Narzędzia / Dodatki waszej przeglądarki (błagam nie klikajcie na losowe linki do "antywirusów" otrzymane od znajomych!!!!).

Aby narzędzie nie blokowało typowych skryptów ze strony WWW (w tym samego facebooka) można (jako minimum zabezpieczeń) wybrać operację "wyłącz blokowanie skryptów". Nadal będzie aktywna ochrona przed "Clear Click". W przypadku wystąpienia nadużycia dostaniemy ostrzeżenie a szkodliwy fragment strony pozostanie zdezaktywowany.

Recently new vulnerability ("poodle") has been discovered in SSLv3 protocol. "man in the middle" attack could be performed using protocol version negotiation feature built into SSL/TLS to force the use of SSL 3.0 then exploit the "poodle" vulnerability.

In order to remove the threat from our servers we have to drop SSLv3 from negotiation list. Secured server should respond as follows: $ echo | openssl s_client -connect 192.168.1.100:80 -ssl3 2>&1 | grep Secure Secure Renegotiation IS NOT supported $ echo | openssl s_client -connect 192.168.1.100:80 -tls1 2>&1 | grep Secure Secure Renegotiation IS supported We use openssl command to open HTTPS connection and check if requested protocol could be negotiated or not.

And the fix itself (for JBoss/Tomcat service): you have to locate Connector tag responsilble for HTTPS connection and:

• remove any SSL_* from ciphers attribute
• limit sslProtocols="TLSv1, TLSv1.1, TLSv1.2"

Example: <Connector port="80" protocol="HTTP/1.1" SSLEnabled="true" ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA" maxThreads="100" scheme="https" secure="true" minSpareThreads="25" maxSpareThreads="50" keystoreFile="${jboss.server.home.dir}/conf/tm.keystore" keystorePass="MyKeyStore1" clientAuth="false" sslProtocols="TLSv1, TLSv1.1, TLSv1.2" /> It will effectively block any SSLv3 connections as visible by "openssl s_client" test above.