Il futuro, la persona e la tecnologia

Qualche tempo fa un amico mi ha chiesto di scrivere un breve articolo sul futuro. “Vorrei sapere cosa ne pensi del futuro, dal punto di vista tecnologico e non solo”. Una cosa così, almeno per quello che io ricordo.

La cosa è tornata a galla di tanto in tanto nei miei pensieri ma, ogni volta, veniva ricacciata sotto il pelo dell’acqua da un dubbio:

Ha senso parlare del futuro se tanto poi si sbaglia?

Quest’ultima domanda contiene una grande verità: quanto si parla del futuro si sbaglia praticamente sempre. Può però capitare, a volte, che parte di quello che viene detto o scritto effettivamente si materializzi. Succede. Ma quando succede, molto spesso quel futuro è diverso in qualche dettaglio che, a posteriori, diventa assolutamente chiaro.

Allora come i giganti ci hanno insegnato, guardiamo al passato per capire il presente ed immaginare il futuro. Lo faccio prendendo spunto da una cosa capitata giusto di questa mattina: riordinando alcuni scaffali mi è capitato per le mani un libro del 2002 che parla di innovazione. Sfogliandolo mi è caduto lo sguardo su due parole, “tablet PC”, che mi hanno incuriosito. Mentre leggevo domanda ha iniziato a ronzarmi nella testa: ma l’iPad non è del 2007?

Sbagliato, l’iPad è stato presentato nel 2010, più o meno la metà del tempo che ci separa dal 2002.

Sto divagando, torniamo al testo. L’autore evidenziava come ciò che mancava ai tablet di allora era il riconoscimento della scrittura “naturale”, insomma quella con la penna. E che una volta risolto questo problema – ovvero quando il riconoscimento della scrittura con la penna sarebbe diventato affidabile – il “tablet PC” sarebbe diventato onnipresente.

Passati 16 anni cosa possiamo dire di quella previsione? Fra le tante cose ne evidenzio una: la presunta barriera – il riconoscimento della scrittura con la penna – non è stata affatto determinante per il successo (passato?) dei tablet. Le dita sono state più che sufficienti.

O meglio, il semplice fatto – a posteriori – che non è affatto necessario dover scimmiottare uno strumento – la penna – per interagire con un tablet. E’ invece stato sufficiente sviluppare un modo diverso per l’interazione persona-macchina o persona-tecnologia, (ri)mettendo la persona al centro. Questa, per me, è la porta verso il nostro futuro prossimo venturo.

tcpdump on android (quick and dirty how-to)

This is a quick and dirty how-to based on an excellent android tcpdump tutorial written last year. Things are changed since then, so we have to arrange something in order to get tcpdump up and running on our android phone.

Intro

So, let’s start to say that there is a really good set of articles, written a year ago by Vincent Kornacky, that explains in details what you need(ed) to do in order to get tcpdump on your android phone:

Unfortunately, things are changed since then (updates to the Emdebian distributions ceasedDebian Jessie evolved), so when I tried to follow the path outlined in the articles, I run into some problems, ending up that I had to do the same things (what) in a different way (how).

I strongly suggest you to read Vincent’s blog before continuing, because here you will find only a quick and dirty how-to, largely taken from the history of the commands that I had to issue on my brand new DebianJessie64 VM. And remember: if you follow these instructions, you are using them at your own risk:

use-at-own-risk-sign-s-9967

Part I: Installing the toolchain

Since embedian distributuons ceased, I suggest you to follow these instructions, from Debian website, starting from:

[…] Create /etc/apt/sources.list.d/crosstools.list containing:
deb http://emdebian.org/tools/debian/ jessie main […]

If you just downloaded and installed Debian Jessie like me, you may need to:

  • su (instead of setup sudo)
  • use wget (instead of install curl)

wget http://emdebian.org/tools/debian/emdebian-toolchain-archive.key
apt-key add emdebian-toolchain-archive.key
dpkg --add-architecture armhf
apt-get update
apt-get install crossbuild-essential-armhf

Please note that we specify armhf here. I did not investigate further, but since there are also armle and arm64 cross-compilers (and devices?) be aware of this detail (ie: your device will work? uname -m may help). And, of course, you need to issue this command at the end to check if everything is ok:

arm-linux-gnueabihf-gcc -v

Part II: Cross compiling libpcap and tcpdump

You can do it quite easely if you follow Vincent Kornacky steps, with this caveats:

  • use libpcap-1.6.2 and tcpdump-4.6.2 (I’ll try again, but I didn’t get the latest tcpdump cross-compiled with the latest libpcap)
  • use arm-linux-gnueabihf-gcc instead of arm-linux-gnueabi-gcc

here you are the commands:

export CC=arm-linux-gnueabihf-gcc
wget http://www.tcpdump.org/release/libpcap-1.6.2.tar.gz
tar zxvf libpcap-1.6.2.tar.gz
cd libpcap-1.6.2
./configure --host=arm-linux --with-pcap=linux
make
cd ..
wget http://www.tcpdump.org/release/tcpdump-4.6.2.tar.gz
tar zxvf tcpdump-4.6.2.tar.gz
cd tcpdump-4.6.2
export CFLAGS=-static
export CPPFLAGS=-static
export LDFLAGS=-static
./configure --host=arm-linux --disable-ipv6
make

Please note that if you have to go back and recompile libpcap (like me) you must unset CFLAGS, CPPFLAGS, LDFLAGS (and then, of course, set them again).

Part III: Installing & Executing TCPDUMP

Just follow Vincent’s steps.

Part IV: Forwarding To Wireshark

Uh, we have to cross-compile netcat… Remember to use hf, set the flags (or unset if you are doing everything in a hurry) and everything should work fine:

wget http://downloads.sourceforge.net/project/netcat/netcat/0.7.1/netcat-0.7.1.tar.gz
tar zxvf netcat-0.7.1.tar.gz
cd netcat-0.7.1
export CC=arm-linux-gnueabihf-gcc
export LDFLAGS=-static
./configure --host=arm-linux
make

again, for any further detail please read Vincent’s article.

Conclusions

Just a few more words at the end of this quick and dirty how-to:

PMD promiscuous mode detector

This program analyzes the LAN, trying to find PC with the network interface card in promiscuous mode. Using this tool you may detect, for example, whether on not a “sniff” attack is in progress on the net.

Questo programma analizza la rete locale alla ricerca di PC con la scheda di rete settata in modo promiscuo. E’ quindi possibile, ad esempio, cercare di individuare se al momento è in atto un attacco di tipo “sniff”.

http://webteca.altervista.org/download/pmd-promiscuous-mode-detector/

PMD, dieci (undici? tredici?) anni dopo

Sto cercando di riportare in vita i programmi che ho fatto… dieci ? tredici anni fa? Il motivo è semplice: ho acquistato un nuovo modem-router-switch-wireless perché quello che ho sempre creduto essere in comodato (e che pagavo come se fosse in comodato) in realtà non lo è da… molto tempo. Bugie Magie dei commerciali che… hanno perso, presumo definitivamente, un cliente.

Ma torniamo a noi. Dicevo che ho comperato un nuovo modem-router-switch-wireless. Costo: 21 euro e spiccioli su Amazon, consegna compresa. Ok, ok, non ridete. Non è che non funziona. Funziona e funziona anche bene, ma. Ed è per colpa di questo “ma” che ho ripreso per mano, appunto, cose scritte ormai tredici anni fa.

Il punto è questo: il mio Smart TV si rifiuta(va) di andare in internet. E prima di gettare il modem in pasto a Ebay per comperarmene un altro  ho voluto capire cosa non funziona(va). Tornerò (forse) in un secondo momento su questa cosa, perché ora voglio parlare di PMD di come, inaspettatamente, questo programma compilato 11 anni fa ha funzionato, quasi perfettamente, al primo colpo, nonostante la ricompilazione recentissima di una libreria fondamentale per il suo funzionamento, la libreria Libnet.

Per i curiosi, PMD è un programma che permette, sotto determinate condizioni, di riconosce se un nodo di rete è in modalità “promiscua”. Per i dettagli di cosa sia la modalità “promiscua” potete leggere questo post, scaricare questo paper oppure queste slide.

In poche parole PMD “sollecita” una risposta da parte di uno o più nodi di rete in modo che solo quelli settati in tale modalità diano una risposta. Il “sollecito” è ovviamente “scritto” e questo significa che PMD, per funzionare necessita di “scrivere” dei pacchetti in rete. Cosa che, a suo tempo, era stata fatta tramite Libnet.

Prima ho usato un avverbio: “inaspettatamente”. E anche se, a ben pensare, dovrebbe essere normale che una libreria mantenga una retro compatibilità con le versioni passate, devo dire che tutt’ora sono in parte stupito e in parte compiaciuto del fatto che è bastato ricompilare Libnet, copiarla nella directory dell’eseguibile PMD e fare doppioclick su quest’ultimo per ottenere:

20150303 - PMD 001

E ancor più stupido del fatto che, dopo aver impostato i parametri di rito, tutto (beh, quasi tutto) abbia funzionato a dovere:

20150303 - PMD 002

Devo essere sincero: non ero affatto convinto. Non tanto dell’indirizzo IP visualizzato sbagliato (credo di sapere dove è l’inghippo, ma ora controllerò) ma del fatto che in rete fosse stato scritto il pacchetto in modo corretto. Ed invece WireShark ha confermato che è proprio così:

20150303 - PMD 003

Quindi: PMD fa il suo lavoro anche a 11 anni dalla sua ultima compilazione. Cosa non da poco se consideriamo che né PMD né Libnet fanno cose “normali” e interagiscono con sistema operativo, driver di rete, libreria Winpcap ecc.

Tempo di mettere a posto la visualizzazione dell’IP della risposta e PMD tornerà online.

E’ tempo di (r)innovare

Sono passati 13 anni da quando, nel 2002, ho iniziato a scrivere sul web. Il mondo è cambiato, molto. Ne parleremo. Ma, per prima cosa, è il caso di riassumere qui cosa ho “portato con me” dopo la mia decisione di chiudere il sito “fatto a mano” e passare ad un blog.

Torno (spero) quando avrò finito. Certo fa un po’ impressione rileggere ora quello che ho scritto tanti anni or sono…

Predictability of Windows DNS resolver


Abstract
The main DNS security issues have very often focused on server side problems and vulnerabilities. This paper focuses on Windows client DNS service, also called DNS resolver. This paper explains how it is often possible to predict the “Transaction ID” and the “UDP port number” used by Windows’ DNS Resolver. With this information it will be shown how it is possible, under certain conditions, to win the race against the regular DNS server and hijack, for example, a TCP/IP session. Even if this problem has been reported to Microsoft’s security experts and we both agreed that there is no immediate threat or security vulnerability, it may be used to attack Windows LAN and WAN clients for example at startup. In WLAN too, which shares the medium and then is subjected to the well-known DNS attacks based on sniffing, this predictability increases the chances of being effectively attacked.
Microsoft informed me that the concerns mentioned in this paper will be addressed in future versions of its products
.

Predictability of Windows DNS resolver

Individuazione dei nodi promiscui su reti Token ring con l’ausilio di pacchetti ARP

La possibilità di individuare i nodi di una rete locale che effettuano intercettazione, analisi e monitoraggio dei dati (sniffing) è stata oggetto di numerosi studi. Sebbene questi studi non abbiano permesso di sviluppare tecniche universalmente efficaci , nondimeno hanno fornito alcuni strumenti comunemente usati per le reti basate sulla tecnologia Ethernet.
Daiji Sanai nel suo white paper [1] “Detection of promiscuous nodes using ARP Protocol” illustra una di queste tecniche che si basa, appunto, sul protocollo ARP.
In questo documento viene presentato un metodo per utilizzare tale tecnica per cercare di individuare i nodi promiscui presenti nelle reti di tipo Token ring.

Il documento si compone di due parti: la prima richiama alcuni concetti di base dei protocolli di rete e delle tecniche di sniffing; la seconda illustra in dettaglio come sia spesso possibile rilevare i nodi settati in modo promiscuo su rete Token ring

Individuazione dei nodi promiscui su reti Token ring con lÆausilio di pacchetti ARP

The easiest way to get around SSL

Abstract
This paper explains how it is often possible, with the simple substitution of a string, to get around a “secure” implementation based on an incorrect use of SSL.
Please note that this document does not contain any information about weaknesses of the SSL protocol; it simply shows the easiest way to get around the correct functioning of the SSL protocol.
In this document typical “weakly secure” implementation based on the SSL protocol are illustrated.
A simple test application is also proposed to check if existing implementations are indeed “weakly secure”.
This document has an informative purpose.
The easiest way to get around SSL