Dariusz on Software

Methods and Tools

About This Site

Software development stuff

Archive

Entries from August 2014.

Mon, 25 Aug 2014 10:01:11 +0000

382

"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ą:

383

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):

Host: www.facebook.com User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: pl,en;q=0.7,en-us;q=0.3 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Referer: https://www.facebook.com/plugins/like.php?action=recommend&locale=fr_FR&href=https://m.facebook.com/groups/558804457581467/permalink/559754444153135/?8ff89024083642ad88c9c4b47ad5d692 Content-Length: 313 Cookie: datr=rWg(...)6KOiw; lu=ggdH(...)ZBgtg; fr=07Dk3tu(...)WXOZkPI; locale=pl_PL; c_user=10(...)399; xs=34%3AP(...)40%3A18561; csm=2; s=Aa7dVUZ1g44YUPU4.BT-wwE; p=-2; presence=EM40(...)F140896154(...)627825399F0CC; act=1408961956755%2F4 DNT: 1 Connection: keep-alive Pragma: no-cache Cache-Control: no-cache

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):

379Jak 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!!!!).

384

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.

Tags: security.
Thu, 07 Aug 2014 10:02:14 +0000

rtp1IPTV technology delivers video streams using fast, but not reliable protocols (UDP). Those connection-less protocols do not guarantee delivery nor retransmissions of missing packets. We have to accept low video quality for some networks or add another layer above basic protocol that allows to control completeness of delivery. For this purpose we use RTP (packet order, completeness) and RTCP (retransmission requests) protocols.

In this port I'm going to show how effectively use Linux command line tools to analyse client - server cooperation regarding retransmissions for complicated real-world example. Basic RTP metadata collected by tcpdump is used as an input.

A real case that came for analysis: one of content delivery servers cannot deliver retransmissions properly for HD streams (we see video decoding errors on a client) despite the fact that everything is configured properly and should work OK.

As an input I collected tcpdump output of RTP headers for streaming session with simulated data loss (some percentage of packets are dropped): $ tcpdump -qpnli eth0 -T rtp (...) 18:42:16.178074 IP 213.75.112.54.10000 > 10.215.38.151.3544: udp/rtp 1316 c96 17825 3991516661 18:42:16.179670 IP 213.75.112.54.10000 > 10.215.38.151.3544: udp/rtp 1316 c96 17826 3991516802 18:42:16.181178 IP 213.75.112.54.10000 > 10.215.38.151.3544: udp/rtp 1316 c96 17827 3991516934 18:42:16.182627 IP 213.75.112.54.10000 > 10.215.38.151.3544: udp/rtp 1316 c96 17828 3991517065 18:42:16.184174 IP 213.75.112.54.10000 > 10.215.38.151.3544: udp/rtp 1316 c96 17829 3991517207 18:42:16.185628 IP 213.75.112.54.10000 > 10.215.38.151.3544: udp/rtp 1316 c96 17830 3991517338 18:42:16.187169 IP 213.75.112.54.10000 > 10.215.38.151.3544: udp/rtp 1316 c96 17831 3991517480 18:42:16.188619 IP 213.75.112.54.10000 > 10.215.38.151.3544: udp/rtp 1316 c96 17832 3991517611 18:42:16.190225 IP 213.75.112.54.10000 > 10.215.38.151.3544: udp/rtp 1316 c96 17833 3991517753 18:42:16.191690 IP 213.75.112.54.10000 > 10.215.38.151.3544: udp/rtp 1316 c96 17834 3991517884 (...) You can observe there the following fields in tcpdump output:

  1. current time
  2. protocoltype (IP)
  3. source IP address with port
  4. destination IP address with port
  5. packet type (udp/rtp)
  6. packet length in bytes
  7. session ID (c96)
  8. RTP sequence number (17825 .. 17834)
  9. RTP timestamps value (3991516661 .. 3991517884)

Based on automated analysis of sequence and timestamp we could easily detect retransmission packets out of all packets and diagnose what might be wrong with the whole process. Let's analyse differences of sequence and timestamp fields: $ zcat tcpdump.txt.gz | sh lost-repair-analysis.sh | head 18:42:12.673207 packets loss start 18:42:12.788811 packets lost: 75 range: 15521 .. 15595 18:42:12.919069 repair burst started 18:42:13.030555 repair burst finished, packets: 32 range: 15532 .. 15594 18:42:14.836849 packets loss start 18:42:14.939092 packets lost: 66 range: 16944 .. 17009 18:42:15.104764 repair burst started 18:42:15.177257 repair burst finished, packets: 42 range: 16968 .. 17009 18:42:16.985232 packets loss start 18:42:17.087424 packets lost: 67 range: 18356 .. 18422 As you can see 75 packet loss has been detected by script but repair delivered only last 32 packets. The problem with repair was related to server that did retransmissions (too small buffer).

The script source code:

#!/bin/sh

sort | uniq | awk '
/> 10.215.38.151.3544/ {
    dp=$9-p
    dt=$10-t
    if(dp>3 && p){
        print last_regular_time, "packets loss start"
        print $1, "packets lost:", dp-1, "range:", p+1, "..", $9-1
        p=$9
        t=$10
        lost = dp - 1
    }
    else if (dp<0) {
        # One of repairs
        if (!repair) {
            print $1, "repair burst started"
            first_repair = $9
            first_repair_time = $1
        }
        repair ++
        last_repair = $9
        normal = 0
    }
    else {
        # Regular packet
        p=$9
        t=$10
        normal ++
        if (normal > 4 && repair) {
            print $1, "repair burst finished, packets:", repair, \
"range:", first_repair, "..", last_repair
            repair = 0
        }
        last_regular_time = $1
    }
}'

In order to analyse deployment problems carefully you don't have to use hardware protocol monitors. Simple packet dump + careful automated offline analysis are sufficient in most cases.

Tags: network.

Tags

Created by Chronicle v3.5