donderdag 2 juni 2016

Catch the fish - How to check for unwanted network traffic on solaris


During a calm and rainy day at work, I suddenly get a security request to explain why a certain server is making http calls to the outside. As the environment is pretty complex and many teams are hosting their applications, it is somehow fustrating to not find back the answer within 5 minutes.
All documentation available in regards the developed apps, were not mentioning the networkflow which was questioned. Nor did the command "netstat -an" show any result.

So I did a simple check of each PID to see if the command "pfiles PID" would reveil the wanted traffic. But again nothing to find. The process must have triggered very fast and died very fast before I could catch this fish.

Time to start fishing. A small script, using the command "lsof -i4" would run in a loop, constantly checking if my traffic is present. And if it does, then ptree will capture the process info.


IFS="
"
rm /var/tmp/lsof.tmp 2>/dev/null; touch /var/tmp/lsof.tmp
while [ "`cat /var/tmp/lsof.tmp | grep "$1"`" = "" ]; do
  lsof -i4 > /var/tmp/lsof.tmp 2>/dev/null
done
echo "TARGET SPOTTED ON: "`date "+%Y%m%d %H:%M:%S"`
echo "-------------------------------------------------------------------"
for line in `cat /var/tmp/lsof.tmp | grep "$1"`; do
  echo $line
  ptree `echo $line | awk '{print $2}'`
  echo "-------------------------------------------------------------------"
done
echo "FINISHED"
rm /var/tmp/lsof.tmp

And guess what happened, I caught the fish:

Hercules-root# ./valid_network_check.ksh 134.20
TARGET SPOTTED ON: 20160601 22:09:47
-------------------------------------------------------------------
java       1144   tomcat   12u  IPv4 0x3026601ea40         0t0  TCP server1:62153->134.20.87.65:80 (SYN_SENT)
1144  /var/as/java/jre1.7.0_67/bin/java -Dsdc.tc.id=as01_ti01 -Djava.util.l
-------------------------------------------------------------------
java       1144   tomcat   14u  IPv4 0x30175cfa7c0         0t0  TCP server1:62227->134.20.87.65:80 (SYN_SENT)
1144  /var/as/java/jre1.7.0_67/bin/java -Dsdc.tc.id=as01_ti01 -Djava.util.l
-------------------------------------------------------------------
java      25741   tomcat  147u  IPv4 0x304b1cc4340         0t0  TCP server2:62172->134.20.88.65:80 (SYN_SENT)
25741 /var/as/java/jre1.8.0_60/bin/java -Dsdc.tc.id=as01_ti01 -Djava.util.l
-------------------------------------------------------------------
java      25741   tomcat  148u  IPv4 0x301a31fd580         0t0  TCP server2:62223->134.20.88.65:80 (SYN_SENT)
25741 /var/as/java/jre1.8.0_60/bin/java -Dsdc.tc.id=as01_ti01 -Djava.util.l
-------------------------------------------------------------------
FINISHED

 This info was for me enough to escalate to the development team, so that they could take the action needed.

Time again to fetch some coffee and to start a new quest. :-)

zondag 21 juni 2015

Politicians in Belgium promote open WiFi culture?



Alexander Decroo must be a fan of next moto: "Let's be open to the public".

Even when it's about WiFi networks used at the Belgium government. ;-)

The image taken comes from a newsflash on the Belgian newschannel. So it's been distributed worldwide already. I hope the IT manager is already changing those passwords as we speak.

vrijdag 25 oktober 2013

Ex-NSA baas geeft woord en uitleg op de trein.

Most probably it was not meant to be. But it did happen. When talking on the phone on a train, always remember that others are listening to what you say.
I guess that this slipped the mind of former NSA director, Michael Hayden, when he was giving off-record interviews and bashing the NSA admins.

http://twitchy.com/2013/10/24/former-nsa-director-michael-hayden-overheard-giving-off-record-interviews-on-an-acela/

donderdag 24 oktober 2013

Belgium Defense leak to be questioned and answered at full speed thanks to Snowden and the NSA incidents?


Do we all remember the dataleak on the Belgian Defense website early this year?

Seems that 6 months after this incident, some politician, Bert Anciaux, started to think about it. And it took more than 1 month before he got an answer from Pieter Decrem. It surprises me that an incident that was handled 6 months ago, could not be answered in a shorter timeframe.

The investigation and conclusions should have been documented and more easy to be consulted by the government. Or did our politicians get their answer from NSA?


SÉNAT DE BELGIQUEBELGISCHE SENAAT
________________
Session 2012-2013Zitting 2012-2013
________________
19 juillet 201319 juli 2013
________________
Question écrite n° 5-9608Schriftelijke vraag nr. 5-9608

de Bert Anciaux (sp.a)

van Bert Anciaux (sp.a)

au vice-premier ministre et ministre de la Défense

aan de vice-eersteminister en minister van Landsverdediging
________________
les conséquences d'une fuite de données à la Défensede gevolgen van een datalek bij Defensie 
________________
armée
informatique
protection des données 
krijgsmacht
informatica
gegevensbescherming 
________________
19/7/2013Verzending vraag
23/8/2013Antwoord
19/7/2013Verzending vraag
23/8/2013Antwoord
________________
Requalification de : demande d'explications 5-2884Requalification de : demande d'explications 5-2884
________________
Question n° 5-9608 du 19 juillet 2013 : (Question posée en néerlandais)Vraag nr. 5-9608 d.d. 19 juli 2013 : (Vraag gesteld in het Nederlands)
La presse a récemment mentionné un problème dans les banques de données de la SNCB. Les données personnelles de quasi un million et demi de clients se sont retrouvées sur internet sans protection. Le même article renvoie à un problème similaire à la Défense où un annuaire téléphonique du département des Ressources humaines aurait fait l'objet d'une fuite.
Les problèmes informatiques ne datent pas d'hier et sont manifestement une constante, malgré l'expérience accumulée en la matière en un peu plus de deux décennies. En outre, la fourniture et l'entretien des systèmes informatiques de la Défense, tant du point de vue des logiciels que du matériel, sont confiés en sous-traitance à des entreprises et des experts sélectionnés avec circonspection, très onéreux et par conséquent, n'en doutons pas, hautement compétents. A fortiori à la Défense, on peut espérer que ces données informatiques sont protégées de manière particulièrement adéquate.
Une bévue comme cette fuite de données de clients du département Ressources humaines de la Défense n'en est que plus grave, mais aussi inquiétante, et suscite inévitablement des questions sur la qualité des systèmes informatiques de la Défense.
Le ministre confirme-t-il que l'annuaire téléphonique du département des Ressources humaines de la Défense a fait l'objet d'une fuite et que de nombreuses données personnelles de la Défense se sont retrouvées sur internet sans protection ?
Comment cette fuite s'est-elle produite, quelle faute concrète a-t-elle été commise ? S'agit-il d'une erreur humaine, d'un mauvais fonctionnement du système, de circonstances imprévisibles ...
Le ministre estime-t-il acceptable qu'une organisation hautement professionnelle et, nous l'espérons, bien sécurisée telle que la Défense soit confrontée à cette grave bévue ? Qui le ministre tiendra-t-il pour responsable à cet égard ? S'agit-il d'une faute commise par un fournisseur externe ou par le personnel de la Défense ? Où le contrôle de qualité a-t-il échoué ?
Cette fuite de données a-t-elle engendré ou engendre-t-elle des coûts supplémentaires pour la Défense ? Dans l'affirmative, lesquels, à combien s'élèvent-ils et qui les paiera ? Dans la négative, pourquoi ?
Cette fuite a-t-elle engendré ou engendre-t-elle des coûts supplémentaires pour les personnes dont les données personnelles ont été révélées ? Dans l'affirmative, lesquels, à combien s'élèvent-ils et qui les paiera ? Dans la négative, pourquoi ?
Comment évitera-t-on à l'avenir ce genre de problème et de bévue ? Quelles mesures concrètes ont-elles entre-temps été prises à cet effet ?
 
De pers meldde recent een probleem in de NMBS-databank, waardoor de persoonsgegevens van bijna anderhalf miljoen klanten onbeschermd op het internet kwamen. Hetzelfde persbericht verwijst naar een vergelijkbaar probleem bij Defensie, waar een telefoonboek van het HR-departement zou gelekt zijn.
Problemen met informatica zijn niet nieuw en blijkbaar van alle tijden, hoewel er ondertussen toch al ruim twee decennia ervaring werd opgebouwd. Daarnaast wordt de levering en het onderhoud van de informatica van Defensie, zowel hard- als software, uitbesteed aan behoedzaam geselecteerde, erg dure en dus ongetwijfeld hoogst bekwame leveranciers en experts. Zeker bij Defensie mag men hopen dat deze informatica bijzonder adequaat wordt beschermd.
Dit maakt een euvel zoals deze datalek van HR-departement van Defensie niet alleen erg ernstig maar ook beangstigend en noopt tot vragen over de kwaliteit van de informaticasystemen bij Defensie.
Bevestigt de minister een lek van het telefoonboek van het HR-departement van Defensie, waardoor heel wat persoonsgegevens van Defensie vrij op het internet kwamen?
Hoe ontstond dit datalek, wat ging er heel concreet fout? Is er sprake van een menselijke fout, een systeem fout, een onvoorziene omstandigheid…
Vindt de minister het aanvaardbaar dat een hoogst geprofessionaliseerde en hopelijk ook goed beveiligde organisatie zoals Defensie met dit ernstige euvel wordt geconfronteerd? Bij wie zal de minister de aansprakelijkheid hiervoor leggen? Gaat het hier over een fout van een externe leverancier of een fout bij het Defensiepersoneel? Waar ging de kwaliteitscontrole de mist in?
Veroorzaakte of veroorzaakt deze datalek extra kosten of ongemakken aan Defensie? Zo ja, welke, hoe omvangrijk en wie draait hiervoor op? Zo niet, waarom niet?
Veroorzaakte of veroorzaakt deze datalek extra kosten of ongemakken aan de personen wiens persoonsgegevens gelekt zijn? Zo ja, welke, hoe omvangrijk en wie draait hiervoor op? Zo niet, waarom niet?
Hoe zal dit soort problemen en euvels in de toekomst worden vermeden? Welke concrete maatregelen zijn er ondertussen daartoe genomen?
 
Réponse reçue le 23 aôut 2013 :Antwoord ontvangen op 23 augustus 2013 :
L’honorable membre est prié de trouver ci-après la réponse à ses questions.
Une liste téléphonique interne de la Direction générale des ressources humaines (DGHR) a effectivement été publiée sur l’internet.
Cette fuite de données provenait d’une faute technique. Le site qui contenait ces données, a été bloqué le 3 janvier et le 4 janvier des mesures ont été prises pour enlever l’information répandue involontairement. Il convient de noter qu'aucune information privée n’a été rendue publique. Le 8 janvier, le personnel de la Défense concerné a été informé des mesures prises via un e-mail interne.
Le problème était dû à la technologie utilisée pour sécuriser l'accès au site distinct de la DGHR. Ce site - qui se trouve sur un serveur distinct et complètement isolé du réseau interne de la Défense - est utilisé pour la diffusion efficiente aux militaires et personnes relatées (notamment les retraités, les réservistes, ...) d’informations non classifiées relatives au personnel. Ceci signifie que les personnes qui disposent de droits d'accès à ce site ne possèdent pas automatiquement un accès au réseau interne de la Défense.
Les autres sites de la Défense utilisent des technologies différentes et ne sont donc pas sensibles aux mêmes problèmes. La fuite n'a provoqué pour la Défense ni pour les personnes dont les données ont été divulguées des frais supplémentaires. Un nombre limité d’utilisateurs a subi un léger inconfort car ils ne pouvaient plus accéder à l'information de ce serveur. Cette restriction a été communiquée et l'information nécessaire a été rendue disponible par des canaux alternatifs. Entre-temps, le nouveau site internet sécurisé de la DGHR est accessible après identification.
La Défense dispose d’un service spécialisé en sécurité informatique. Le domaine de la sécurité de l'information est un domaine qui évolue constamment. L'amélioration et l’actualisation de la protection des données et des informations aussi bien internes, que celles qui sont accessibles à travers un site public comme « dghr.mil.be », constitue une préoccupation constante qui nécessite un effort continu du Département.
Het geachte lid gelieve hierna het antwoord te willen vinden op de door hem gestelde vragen.
Er werd inderdaad een interne telefoonlijst van de Algemene Directie Human Resources (DGHR) gepubliceerd op het internet.
Dit data lek betrof een technische fout. De bewuste site werd op 3 januari afgesloten en op 4 januari werden maatregelen genomen om de ongewild verspreide informatie weg te halen. Er dient wel gemeld te worden dat er geen privé-gegevens publiek werden gemaakt. Op 8 januari werd het betrokken personeel van Defensie via een interne e-mail op de hoogte gesteld van de ondernomen acties.
Het probleem was te wijten aan de gebruikte technologie voor de beveiliging van de toegang tot deze aparte site van de DGHR. Deze site – die trouwens op een alleenstaande server staat die volledig is geïsoleerd van het interne netwerk van Defensie – wordt gebruikt voor de efficiënte verspreiding van niet geclassificeerd personeel gerelateerde informatie naar militairen en aanverwanten (o.a. gepensioneerden, reservisten,…). Dit betekent dat personen die toegangsrechten krijgen tot deze site niet automatisch over een toegang beschikken tot het interne netwerk van Defensie.
De andere sites van Defensie gebruiken andere technologieën en zijn aldus niet onderhevig aan dezelfde problemen. Het lek veroorzaakte noch voor Defensie noch voor de personen waarvan de data gelekt zijn extra kosten. Een beperkt aantal gebruikers heeft een licht ongemak ondervonden omdat zij niet meer aan de informatie van deze server konden. Deze beperking werd medegedeeld en de nodige informatie werd via alternatieve kanalen beschikbaar gesteld. Intussen is de nieuwe beveiligde internetsite van de DGHR toegankelijk na identificatie.
Defensie beschikt over een dienst die gespecialiseerd is in informatieveiligheid. Het domein van de informatieveiligheid is een domein dat continu evolueert. De verbetering en het actualiseren van de bescherming van zowel interne gegevens als gegevens die via een publieke site zoals “dghr.mil.be” toegankelijk zijn, is dus een constante zorg en vraagt een continue inspanning van het Departement.

dinsdag 18 juni 2013

Usability vs. Security: The Everlasting Trade-Off in the Context of Apple iOS Mobile Hotspots

 
source: https://www1.cs.fau.de/filepool/projects/hotspot/hotspot.pdf

Average cracking time (ACT) of an arbitrary iOS hotspot default password using different GPU clusters.

# GPUs
Hardware
Cycles per Second
ACT
2x
Nvidia Tesla C2075
46.600
3m 18s
1x
AMD Radeon HD6990
180.000
52s
4x
AMD Radeon HD7970
390.000
24s

To automate the process of word list generation, we built the iOS app Hotspot Cracker. This app assists in generating an iOS hotspot cracking word list, which might be used in subsequent attacks on other hotspot users. The app also gives explanations and hints on how to crack a captured WPA handshake using well-known password crackers. Future releases might also automate the process of capturing and cracking hotspot passwords. As computing power on smart devices is limited, one solution is to involve online password cracking services like CloudCracker, to crack hotspot passwords on-the-fly.

As the mobile hotspot feature is probably most often used while being on travel, on conferences, or hotel stays, an attacker will only have a limited amount of time to succeed in breaking into a mobile hotspot. Therefore, a very limited cracking time frame is the main requirement for such an attack to be practically relevant. Taking our optimizations into consideration, we are now able to show that it is possible for an attacker to reveal a default password of an arbitrary iOS hotspot user within seconds. For that to happen, an attacker only needs to capture a WPA2 authentication handshake and to crack the pre-shared key using our optimized dictionary.

As it is always a good advice to replace initial default passwords by user-defined strong and secure passwords, this becomes particular relevant on mobile hotspots passwords. Therefore, users of mobile hotspots, especially of iOS-based mobile hotspots, are advised to change their passwords. In addition, some mobile platforms (like Apple iOS) display the number of connected clients on the lock screen. Therefore, it is a good advice to periodically check that screen for any conspicuous activity. Finally, hotspot capabilities of smart devices should be switched off every time when they are no longer needed, to keep the overall attack surface as minimal as possible.

Vendors of mobile hotspot solutions should improve their way of generating initial default passwords. System-generated passwords should be reasonably long and should use a reasonably large character set. Consequently, hotspot passwords should be composed of completely random sequences of letters, numbers and special characters. It can be neglected that increased randomness could have a negative impact on the memorability of the passwords. Particularly, in the context of mobile hotspots there is no need to create easily memorizable passwords. After a device has been paired once by typing out the displayed hotspot password, the entered credentials are usually cached within the associating device and are re-used within subsequent connections.

Summing up, the results of our analysis have shown that the mobile hotspot feature of smart devices increases the attack surface in several ways. As the default password of an arbitrary iOS hotspot user can be revealed within seconds, attacks on mobile hotspots might have been underestimated in the past and might be an attractive target in the future.

maandag 17 juni 2013

België wil geheime dienst directe toegang geven tot politiedatabank

 
De Belgische Minister van Binnenlandse Zaken Joëlle Milquet wil later dit jaar een wetsvoorstel indienen zodat de Staatsveiligheid, de Belgische burgerlijke geheime dienst, rechtstreeks toegang krijgt tot de databank van de politie.
 
Ministerie van Binnenlandse Zaken BelgiëDe politie in België kan al informatie uit zijn grote databank delen met inlichtingendiensten, maar Staatsveiligheid zou rechtstreekse toegang tot de Algemene Nationale Gegevensbank moeten krijgen, vindt de minister. De precieze details over de toegang moeten nog in de regering besproken worden. In de databank staan gegevens van personen en bedrijven die ooit in een proces-verbaal gelinkt zijn aan een mogelijk misdrijf. Het voornemen is onderdeel van een groter plan om de ANG anders te gaan gebruiken, aldus De Tijd.

Zo zegt de minister ook dat gegevens in de databank na een bepaalde periode gewist moeten worden, omdat het nu moeilijk is om gegevens weer uit de databank te laten schrappen. Dat gebeurt alleen als iemand overlijdt, of zelf naar de zogenoemde privacycommissie stapt. Volgens de voorzitter van de Vaste Commissie van de Lokale Politie, Jean-Marie Brabant, is het in strijd met Europese regels dat het niet automatisch gebeurt.

Een ander plan van de minister is om de kwaliteit van de databank te verbeteren door meer nauwkeurige criteria op te stellen om gegevens in te voeren. De ANG blijkt namelijk niet altijd even betrouwbaar. Volgens Gert Cockx van politievakbond NSPV zijn de meeste politieagenten huiverig wat betreft de juistheid van de informatie.

Volgens een anonieme politiedirecteur heeft de database zijn limiet bereikt doordat deze in de loop der jaren telkens is uitgebreid met nieuwe gegevens als bijvoorbeeld kentekens en mobiele telefoonnummers. Het is ook niet mogelijk om links aan te leggen tussen verdachte bedrijven.
Tot slot moet ook de structuur van de databank verbeterd worden. Zo moet het mogelijk worden om binnen de ANG specifieke databases aan te maken voor specifieke doeleinden, zoals een database voor gestolen kunstwerken. Eerdere initiatieven om een specifieke database op te richten, vaak door politieagenten zelf, liepen op niets uit.

Door Christophe van Bokhoven, vrijdag 14 juni 2013 12:20

vrijdag 24 mei 2013

Read a Mac CD in Ubuntu

Nothing special, but always handy if a i-dude comes over with his music but which was formated for his MAC.

How to mount?
First you need to make sure that you umount the disc in case it got automounted.

umount /media/<username>/<volumename>

Problem is that we not always know which format was used, so let's start to guess:

sudo mkdir /media/test
sudo mount -t iso9660 /dev/cdrom /media/test
ls /media/test
sudo mount -t udf /dev/cdrom /media/test
ls /media/test
sudo mount -t hfs /dev/cdrom /media/test
ls /media/test
sudo mount -t hfsplus /dev/cdrom /media/test
ls /media/test

 
Most probably you will be lucky to find the right format and you can start abusing the disk :-) LET's PARTY...