xenion HQ

hi all,

An official post from Google about the session hijacking issues of Gmail: Making security easier

But don’t worry, by default the cookietools still works

Yesterday someone from Googleplex looked at my rtpbreak pages. It was funny to track them once in my life, when they track me every damn day

The visit trace follows (image).

For a Data Mining course project I’m coding some stuff about blogs, clustering and correlation. Probably I’ll release something about it in a few months, it sounds interesting to play with it using as dataset security blogs and mailing lists. Anyway, still work in progress. In the Papers section I’ve added some slides about FastMap, an interesting algorithm for dimensionality reduction.

In a recent seminar at the University of Trento, Prof. Bernardo A. Huberman (Social Computing Lab, HP Laboratories) presented the results of studies of interactions underlying social media, and described mechanisms they have designed to access this collective intelligence while improving user’s interactions with digital information.

He said you can gain Attention from a group in two ways: broadcasting or virally. If you want to maximize Attention, you must consider two variables: Novelty and Popularity (Popularity, Novelty and Attention). Another interesting phenomenon is Group deliberation/polarization in Opinions.

Some interesting observations:

• The Attention evolves over time, decreasing
• Dissenting voices gain more attention
• People lived in villages (no privacy), then cities (too much privacy), now we’re going back to villages (loosing privacy)
• Those results model the web, not the real world!

More details: HP Social Computing Lab

hi all,
rtpbreak 1.3a is out!

CHANGELOG - Download and Documentation.

bye,
-x

Hi all,

I’m happy to announce a new release of The Cookie Tools (v0.4)! some bugs have been fixed and there are some new functionalities.

Download and Documentation.

Thanks to the cookietools, some libnids bugs have been discovered and reported. When a new version of libnids will be out, also the cookietools will work better.

Enjoy!

The most diffuse VoIP protocols, SIP and H.323, have a Web bug you can use to (try to) know if someone is tapping your conversations. It may also help to make their sniffing work harder but it’s less relevant and interesting, if you really want confidentiality and privacy you must use encryption and anonymized endpoints.

Scenario

You suspect someone is trying to sniff your VoIP conversations, you want to investigate.

Know your adversary

The VoIP tapping systems work sniffing network traffic from privileged network points where they can see everything of everybody, seeking for SIP/SDP messages, using them to detect and reconstruct the RTP streams. Any packet is recorded for later use/analysis. This simplification is ok in order to understand the technique.

Attack

I’ll describe what to do with SIP,something similar should work also with H.323. The SIP protocol uses the SDP protocol in order to send the RTP stream parameters. If what I’ve said sounds too strange, go RTFM and come back! (se sei italiano, leggi il mio paper sul VoIP che è un buon riassunto)

Consider the following SDP message:

v=0

o=Michele 123456 654321 IN IP4 192.168.2.8

s=A conversation

c=IN IP4 192.168.2.8

t=0 0

m=audio 7078 RTP/AVP 0 111 110 3 8 101

a=rtpmap:0 PCMU/8000/1

a=rtpmap:111 speex/16000/1

a=rtpmap:110 speex/8000/1

a=rtpmap:3 GSM/8000/1

a=rtpmap:8 PCMA/8000/1

m=video 9078 RTP/AVP 97 98 99

a=rtpmap:97 theora/90000

a=rtpmap:98 H263-1998/90000

a=rtpmap:99 MP4V-ES/90000

Description: Michele announces he is listening for an audio and a video stream respectively on UDP ports 7078 and 9078 at the same IPv4 address 192.168.2.8. The rtpmap records are used to map RTP payload type to encoding formats, something not relevant for our purposes. The interesting line is “c=IN IP4 192.168.2.8“, from RFC 2327 - SDP: Session Description Protocol:

If a unicast data stream is to pass through a network address translator, the use of a fully-qualified domain name rather than an unicast IP S is RECOMMENDED. In other cases, the use of an IP address to specify a particular interface on a multi-homed host might be required. Thus this specification leaves the decision as to which to use up to the individual application, but all applications MUST be able to cope with receiving both formats.

As stated in the specification, any valid Fully Qualified Domain Name (FQDN) may be used to specify the destination address, so you can set it to “myip.dnslogger.freeasbeerdns.org” if it resolves to the correct IPv4 address.If you have also the control over its authoritative DNS, you can log any resolution attempt… catching the observer too!

In fact, the hypothetic VoIP tapping system should consider the FQDN announced in the SDP messages in order to know the correct IPv4 addresses and UDP ports of the RTP streams. If it uses the IPv4 addresses of the SIP messages, it will fail to recognize correctly the RTP stream endpoints in particular SIP configurations (like with not transparent SIP proxies). If this happens, it will probably loose completely the RTP stream content, and bye bye voice!

In practice, if “freeasbeerdns.org” is a free DNS service that allows you to be the authoritative DNS for any subdomain and you have registered “dnslogger.freeasbeerdns.org”, any DNS query to “*.dnslogger.freeasbeerdns.org” will be forwarded to “dnslogger.freeasbeerdns.org”, where you have Bind running, logging everything and resolving myip.dnslogger.freeasbeerdns.org to your IPv4 address. This solution is costs-zero, apart your-time cost

Final note, you can change in the same way also the IPv4 address in the “o=Michele 123456 654321 IN IP4 192.168.2.8″ line. This shouldn’t be necessary, anyway who knows… an heuristic implemented in the VoIP tapping system may detect the incongruence!

Final considerations

If something like rtpbreak is used, nothing can be done… anyway this is not the case, if you are lucky and I’m not around :>

There are many different ways to implement a VoIP tapping system, the described technique may or may not work!

Scenario

you can intercept TCP connections and inject packets into the network.

Attack

Sniff network traffic and reconstruct the requested HTTP pages saving them to disk, like an HTTP proxy. When the same page is requested multiple times and the content doesn’t change, flag it as “fixed”.

Now, look at the “fixed” pages. If they contain login forms, the game continues!

Sniff network traffic and when a page in the “fixed” set is requested, say P, impersonate the remote server replying with a modified version of P, say M. You can construct such a TCP packet because you have all the details and your reply will arrive faster! (if the page is not cached locally and too near… anyway this is another problem :P)

In order to construct M, read P and insert in his HTML head section a JavaScript keylogger

The JavaScript keylogger should send an HTTP request with the typed characters encoded in the URL to a fake web server you have set up on your box.

Happy end of the story: any typed character in the login form will flow to your webserver logs, you decode, them, you have stolen the login user credentials!

Final considerations

Have you any idea about the tools needed to play this stuff? a networked version of sed would be interesting…

login forms in pages you can reach only via HTTPS are not vulnerable.

This is not an XSS attack!