Friday, October 2, 2015

Gentlemen prefer WEP

Question: Why a gentleman would use WEP on his WiFi router at home?

Answer: Sometimes even a decent man is tempted by weak (or lack of) security of the host somewhere on the Internet. His moves, that he is about to take, may cause some counter-actions in the form of police, trial and jail. He may use TOR and avoid all this misunderstanding, but what if he is careless. He uses WEP, remember?

Here comes plausible deniability. Here is the quote from wiki, 'cause I can't say it better:

Plausible deniability is the ability for persons (typically senior officials in a formal or informal chain of command) to deny knowledge of or responsibility for any damnable actions committed by others (usually subordinates in an organizational hierarchy) because of a lack of evidence that can confirm their participation, even if they were personally involved in or at least willfully ignorant of the actions. In the case that illegal or otherwise disreputable and unpopular activities become public, high-ranking officials may deny any awareness of such act in order to insulate themselves and shift blame onto the agents who carried out the acts, confident that their doubters will be unable to prove otherwise.

So WEP might not give a gentleman an anonymity like TOR, but a "portion" of immunity.

Can we call this gentleman careless now?
Posted by at No comments:
Labels: , , ,

Tuesday, August 11, 2015

Detect management protocols in your network

There are lots of IDS/IPS solutions across the network. Many of them a capable to detect SSH or other management protocols. Today I'm gonna tell you how they usually do this and what techniques are used.

And again, we'll use our favourite scheme:


You have configured the access lists or firewall on router R1, but still, you suspect that someone is using SSH to access their home server/VPS/etc. Of course they don't use TCP/22, but TCP/443. How could you determine, that it is SSH?

Of course you could telnet to remote host and see if the banner comes up:

Escape character is '^]'.
SSH-2.0-OpenSSH_6.0p1 Debian-4

Not our method, right?

The thing


During SSH session each keystroke causes four TCP segments to appear on the network. So, you want to execute ls command on the remote server, it looks like this for letter l:




In tcpdump you usually see just three segments, 'cause the reply from the server is concatenated into one PSH, ACK. But I guess you get the idea.
Also, these packets are very small.

Why is that so? Why not to send the whole command?


The thing is, that there might be the commands on the server that are only one character long. SSH chooses not to try to understand what sequence of characters constitute a command and simply sends across characters as they are typed.

Action

So how can I detect it?

  • As I've already said - IPS/IDS solutions. Almost all of them are signature-based and are pretty flexible in configuration. Suricata and Snort, the most famous open-source solutions, are capable of detecting almost anything.
  • Analyse traffic dumps. You may do it manually or just use Scapy :)
  • Use flows - netflows, sflows, etc.. Connecting you flow sources to some SIEM system will give you the better knowledge of your network.   



Posted by at No comments:
Labels: , , , ,

Monday, July 20, 2015

Top websites and IPv6

Hi all!

Recently I was wondering how top websites by Alexa are doing with security. Actually I was thinking to have a look from IPv6 perspective. Usually, security engineers forget about the firewalls, when it comes to IPv6.

Frankly speaking, I was surprised. Not by the security issues, but with the "readiness" of these websites to IPv6 world. ISPs usually say, that they are not interested in IPv6, because there is no content for users. Now I understand them.

10 000 top Alexa websites was researched. Here are some numbers.

9.6%

of websites support IPv6. Not bad, you may think. No, that is bad. IPv6 is out for almost 20 years by now, so 9.6 of top websites is not so good.

39%

of IPv6-ready websites are hosted by Cloudflare. Awesome! These guys are doing really great things. 17.2% belong to Google :) Well done!

39

websites have IPv6 address, but no open ports. This means, that they are not working for users with active IPv6.

These are the stats on opened TCP ports on hosts, that have both IPv4 and IPv6 running:

IPv4 "wins" because of the following factors:

  1. Not all services automatically bind to IPv6 address. I can see, that there are bunch of services running on IPv4 address, but only web is up on IPv6.
  2. Cloudflare hosted websites (39% of all scanned) have 80, 443, 8080 and 8443 ports opened on IPv4 addresses, whereas 8443 is closed on IPv6.
Anyhow, there are some hosts with undesired opened ports on IPv6 address. SSH opened there, SMTP here, and so on. 

Of course, if to dig deeper and have a look at not just a website, but to research whole IPv6 infrastructure of these companies, we might find some serious security threats, but that would take a lot of time and effort. Scanning an IPv6 range is an impossible task in a foreseeable future (/64 block that is usually assigned to any logical entity has 2^64 = 18446744073709551616 addresses, so good luck with scanning). So conducting an audit of IPv6 network is extremely interesting field for a security engineers.
Posted by at No comments:
Labels: , , , , ,

Wednesday, July 15, 2015

Traceroute and scapy

Recently I was conducting few interviews for a NOC position. One of the questions asked to candidates was quite simple: how traceroute works?

We know that each router decrements TTL of the packet by 1. When TTL=0 ICMP message with type 11 should be sent by router. Type 11 is Time Exceeded.

Traceroute works on this basic principle. For instance we would like see the path from HostA to HostB:

1) HostA sends the packet with TTL=1
2) See who sends back ICMP message with Time Exceeded
3) If it is HostB - finish
4) Otherwise - we found our first hop. Increase TTL by one and go to step #1

That's it.

It is also good to remember, that Windows uses ICMP by default for tracert, whereas Linux and Cisco use UDP for their traceroute command. Anyhow, even TCP could be used.

Here is a simple python script with scapy that shows how traceroute works:
#!/usr/bin/env python

from scapy.all import *
import sys
import socket

def usage():

    print("""
    ./traceroute.py host

    example: ./traceroute.py 8.8.8.8
    """)

    return

def print_hop(number = 0, host = ''):

    print("%s %s" % (number, host))
    return


if len(sys.argv) < 2:

    usage()
    sys.exit(0)

HOST = sys.argv[1]

DSTHOST = socket.gethostbyname(HOST)
MAXTTL = 30

print("trace to %s (%s)" % (HOST, DSTHOST))

for i in range(1, MAXTTL, 1):
    packet = IP(dst=DSTHOST, ttl=i)/ICMP()
    resp = sr(packet, timeout=2, verbose=False)

    try:
        srcip = resp[0][0][1].src
        print_hop(i, srcip)

        if srcip == DSTHOST:
            break
    except:
        print_hop(i, "***")

Try replacing ICMP() with TCP(dport=12345) or UDP(dport=12345) at line #36 an see what happens.
Posted by at No comments:
Labels: , , , , ,

Sunday, June 14, 2015

Tinker Tailor Soldier Spy - How to detect a router in your network

Imagine you are an administrator of the network shown on the diagram. All you have is an access to router R1. You suspect that user U1 is not just a computer, but the router with configured NAT. This means unauthorized devices in your network. How would you prove and fight it?

In this post I will describe you the technique based on TCP timestamps and how with the help of those you could detect NAT in your network.

About TCP timestamps

TCP timestamps option consist of two 4-bytes fields:
  • The timestamp Value field (TSval) contains the current value of the timestamp clock of the TCP sending the option.
  • Timestamp Echo Reply (TSecr) - this field is only valid if the ACK bit is set in the TCP header. If it is valid, it echos a timestamp value that was sent by the remote TCP in the TSval field of a Timestamps option.
TSval is the one we will work with. Each OS implementation increment this value at a specific rate. So it is possible to infer the system uptime from the timestamp option if the targeted OS is known.

For Linux timer rate is defined during kernel compilation and usually equals 250. So if you see smth like this in tcpdump:

09:29:18.663124 IP 192.168.0.12.54793 > 8.8.8.8.53: Flags [S], seq 3386060712, win 29200, options [mss 1460,sackOK,TS val 3659526 ecr 0,nop,wscale 7], length 0

I know that 192.168.0.12 is a linux machine, so its uptime would be approximately: 3659526/250/60/60 ~ 4 hours

Another good and important thing about TSval - it is usually not changed by Network Address Translation.

Theory

By monitoring the traffic on R1 you should:
  • Create a list of timestamps received from U1
  • Based on the idea that two hosts behind a NAT have a distinctive timestamp because they can’t have the same uptime, unless they have been booted within the same millisecond, distinguish two or more hosts.

First steps and visual contact

I ran tcpdump with the following flags to collect the timestamps (192.168.0.12 is my router):

tcpdump -c 100000 -w nat.timestamp.dump -i eth0 src host 192.168.0.12 and tcp

Then with a simple python script and scapy I've created the list which looks like this:

1434112464.25 9135849
1434112464.44 101360108
1434112464.44 101360108
1434112464.44 101360111
...

The value on the left is a timestamp of the capture, the value of the right is TSval of the captured packet. Here is how graph looks (date on X-axis, TSval on Y-axis):


You can see that there are two distinctive TSvals, which means that there are at least two different hosts behind this router. Cool, right?

Catch the spy

Automatic detection is quite tricky in our situation. And that is why:
  • As we already know various operating systems calculate TSval differently.
  • User might modify TSvals on the router.
We can't fight with the second option, but with the first we still have some chances. Timestamps can be represented as a linear function:

TSval = IncBySec * sec + In

IncBySec differs in different operating systems. In - is an initial timestamp value. In all OSes it equals zero, whereas in Windows it is random (that is why it is not possible to calculate an uptime of a Windows host based on TSval). 

We need a technique to overcome operating systems limitations. For instance, we could do the following:

A = TSval_1 - TSval_2 / S1 - S2

Where TSval_1 and TSval_2 are the timestamps gathered at time S1 and S2. 

Now, all we need is to find how many increments do we have. The amount of increments will give us the amount of hosts.
Posted by at No comments:
Labels: , , , ,

Saturday, June 6, 2015

SSL/TLS security overview of forex web cabinets

Recently, I saw few reports on how banks doing with SSL/TLS security. Reports included internet-banking portals from various countries. For instance: UK, The Netherlands, even Russia.

As I work in forex industry, I decided to have a look how they are doing. Qualys SSL Test tool was used.

First of all, I'd like to say, that sometimes it was really hard to find a user portal/cabinet/etc. on some broker pages. Really guys, do something about it. Hiding it won't make it more secure.

Report date: 06 May 2015
Forex brokers are sorted in alphabetical order.

BrokerURLScoreSSL3SSL2SHA1TLS1.2DHRC4FSPOODLEHeartbleedFreakLogjamCCSHSTSOSCP
Admiral Marketshttps://tr.admiralmarkets.comС-++-----++++--
Alfa-Forexhttps://my.alfa-forex.ruB++++-++++++++-
Alparihttps://my.alpari.comA+++++++++++++++
AMarketshttps://office.aforextrading.comA-++-+++-+++++--
Ayondohttps://social.ayondo.comB-++++--+++++-+
BCS Forexhttps://login.forex-bcs.ruB++++-++++++++-
CitiFXhttps://web.citifxpro.comС++--+--++++++-
DeltaTradehttps://delta.tradeB++++-+++++++--
Dukascopyhttps://live-login.dukascopy.comB++++---+++++--
EasyForexhttps://secure.easy-forex.comB+++++--+++++--
Etorohttps://openbook.etoro.comB+++++-++++++--
Exnesshttps://www.exness.comA+++++++++++++++
FBShttps://my.fbs.ruС-+++-+--++++--
Fibohttps://mtclient.fibo.ruB++++-+++++++--
Finamhttps://cabinet1.whotrades.comС-+-+--+-++++-+
FinFXhttps://www.finfx.fiA++++++++++++-+
Forex4Youhttps://account.forex4you.orgA++++++++++++--
ForexClubhttps://secure.fxclub.orgA++++++++++++--
ForexTimehttps://my.forextime.comA++++++++++++--
FX-Trendhttps://fx-trend.comB++-++-++++++--
FXCMhttps://www.myfxcm.comA++++++++++++--
FXDDhttps://secure.fxdd.comB++++-+++++++--
FxOpenhttps://my.fxopen.ruA++-+++++++++-+
FxProhttps://direct.fxpro.comA-++-+++-+++++--
GFThttps://dealbookweb.live.gftforex.comF--------+-++--
GKFXhttps://my.gkfx.ruС-+++-+++++++--
Grand Capitalhttps://grandcapital.ruA+++++++++++++++
IGhttps://www.ig.comB++-++--+++++--
InstaForexhttps://cabinet.instaforex.comС+++----+++++--
Iron FXhttps://www.ironfx.comB+++++--+++++--
LionStonehttps://account.lionstone.co.ukB++++-+-++++++-
Lite Forexhttps://secure.liteforex.comB++-+-+++++++--
Masterforexhttps://mfxbroker.comС-++-+--+++++--
Mayzus.comhttps://secure.mayzus.comF-+-+-+--+++---
NasBrokerhttps://my.nas-broker.comA++++++++++++-+
NordFxhttps://account.nordfx.comA++-+++++++++--
Oandahttps://fxtrade.oanda.comB++++--++++++--
RoboForexhttps://my.roboforex.ruA++-+++++++++--
SaxoBankhttps://ru.saxobank.com/loginB+++++--+++++--
Swissquotehttps://wt.swissquote.comB++++-+-+++++--
Teletradehttps://my.teletrade-dj.comF--+-----+-++--
ThinkForexhttps://portal.thinkforex.comA-++++++-+++++--
VTB24https://lk.olb.ruF-+--++--++++--
WelTradehttps://secured.weltrade.ru/signinB++++---+++++--
Youtradehttps://www.youtradefx.com/loginС-++-+--+++++--
BrokerURLScoreSSL3SSL2SHA1TLS1.2DHRC4FSPOODLEHeartbleedFreakLogjamCCSHSTSOSCP

The full table could be found here.

Frankly speaking, I'm quite surprised. The things are not so bad with these forex guys. Maybe it is because their industry is moving pretty fast and they must be as flexible as possible.

I've added OSCP just for fun, to have a look if somebody is using it and again was surprised :)

What conclusions can we draw from this report:

  • There are still some brokers who use SSLv3 and even SSLv2. And that is bad. This means they do not care about security at all. With SSLv3 POODLE is almost always there. Bad again.
  • Many brokers still use weak DH keys (512 and 786 bits). That is not a serious security flaw, but still.
  • Perfect Forward Secrecy is a must nowdays. Does not matter that your key is safe now. Some day it might leak to the web.
  • We all love Ronald Rivers, but RC4 must not be used. Have a look at RFC 7465.
  • As for SHA1 certificates - that is just the matter of time. Almost all CAs are issuing SHA256 now. The certs will expire eventually.
  • We may see, that recently discovered Logjam and Freak vulnerabilities are pretty rear in our report. IT security became very popular after Heartbleed was announced. Give a security issue a name and it will be closed in a second.
  • As for HSTS (HTTP Strict Transport Security) - that is remarkable, how few brokers are using this feature.
In my humble opinion SSL/TLS is a basis of web security and it is configured pretty easily (even when you don't know what you're doing). There are lots of examples all over the Internet. What other security issues might broker have if one of the most significant things is not configured properly. Forex brokers should give it a thought.
Posted by at No comments:
Labels: , , ,
Subscribe to: Posts (Atom)