[SGVLUG] if it possible to sniff packets if you can't get on the wi-fi network?

[Claude Felizardo]

Review the protocol stack. I don't want to go into the full 7-layer
OSI model but perhaps the Internet Protocol suite is sufficient.  At
the lowest "level" you have the Physical/Link layer which consists of
bits organized into frames which are addressed using MAC addresses.
This would be Ethernet or WiFi.  Next up is the Internet layer which
uses IP addresses to route messages between computers.  The Transport
layer sits on top of IP, hence Transport Control Protocol (TCP) over
IP.  At the very top you have the application layer which would be
something like web traffic using HTTP.

Whitelisting MAC addresses is not sufficient because MAC addresses can
be obtained by listening to wireless traffic and then spoofed but it
can help deter casual users.

Promiscuous mode means the network controller (wireless or wired) will
pass traffic to the CPU, not just packets with the destination MAC
address.  At that point you can capture and analyze packets for
weaknesses.

You can encrypt at any level.  Wired Equivalency Protocol (WEP) was
intended to make WiFi as secure as wired cable but was quickly proven
vulnerable.  WPA, WPA2, etc, are more secure but all wireless
encryption can be broken given time and resources.

Once someone has physical access to your network, they can look at
your ethernet packets and examine the IP end points as well as look at
the contents of your traffic unless you are using encryption at the
application level.  An example would be HTTPS which is HTTP over a
secure transport layer (TLS/SSL) which prevents man-in-the-middle
attacks if implemented correctly.   Same for using TLS to access your
email at a hotspot otherwise you are sending your username and
passwords in the clear.

As long as you are using TLS/SSL, the contents of your connection is
encrypted but anyone looking at your packets can determine where they
came from and where they are going unless you are using say VPN to
access another network then your internet point of presence would be
at that remote network.  The only way anyone would be able to look at
your traffic then is if either your computer or the remote computer
was compromised.

Not being able to connect to the router just means they aren't getting
an IP to do normal Internet access.  They can still sniff the traffic
and even inject traffic!

As for the question regarding a custom point of sale program, where is
the webserver?  In house or at a remote server on the internet?  If
all internal and the POS terminals are hardwired and as long as the
WiFi can't see that traffic then no major problem.  If the store
located such that people can't drive up close enough to access the
WiFi, then maybe.  Hopefully there is only traffic briefly while the
sale is being processed.  Otherwise I would think they would be
vulnerable.  If you want your friend to offer free WiFi, then get
another router and set up two access points: one for the POS but
please use HTTPS, and another for freeloaders with limited speeds.
Let them check their email but not stream video.

Now I have done websites for organizing conferences that could be
accessed using either HTTP or HTTPS so users could start the
registration process and select options but we used a 3rd party
payment gateway service.  I never saw credit card info or billing info
except during development and test.  I used their API to bundle up a
message that was encrypted and protected using multiple factors
including a unique number I created, a number provided by the gateway
service provider when the account was created, a user ID I created
each time and the amount.  When the user submitted, the user's web
browser was redirected to a special URL using HTTPS, the request was
checked for tampering, and if accepted, my application was notified
immediately.  I would also get a confirmation when payment was
actually received.  Again, HTTPS was not required to access my
website, only the processor's gateway.  Anyone sniffing the traffic
could see the user's contact info, options selected and the amounts -
no billing info.

Claude


On Sun, Jan 12, 2014 at 6:01 PM, Jess Bermudes <jbermudes at gmail.com> wrote:
> Promiscuous mode simply means that the NIC will keep packets that are not
> addressed to it. However, in order to know if a packet is addressed to it,
> it has to be authenticated on the network. The packets will otherwise be
> encrypted. The network key is what is used to make sense of the traffic.
> However, as the stackexchange link pointed out, some methods of encryption
> such as WEP offer little protection as known flaws in the protocol allow for
> enough information leak for a passerby to gain enough clues to reconstruct
> the key.
>
> I'm curious as to why he doesn't use https? If his stuff is just local then
> using a locally generated certificate (read: free) would be good enough I
> would think, as the only downside is you'd get Firefox complaining that it's
> an untrusted cert.
>
> Even then with HTTPS, I think the usual solution is that you want to
> partition your network so that your privileged public users can't
> accidentally DoS your POS, even if it's not malicious in intent, e.g.
> someone left their torrenting on or starts a game, etc. I'm not a network
> engineer so perhaps others can elaborate on what it'd take to do that. There
> are software solutions and more expensive hardware solutions depending on
> the need.
>
> If I were him, I wouldn't trust just the MAC whitelisting. Just because a
> machine you whitelisted belongs to somebody you trust doesn't mean the
> machine isn't compromised, nor does that prevent a malicious user from
> attempting to spoof his MAC. I know your friend probably isn't trying to
> protect Fort Knox, but if somebody knows enough to set up MAC whitelists,
> they should look into HTTPS anyway, the prices aren't too bad in many cases
> and if a business can't afford the ~$10/yr for one, that business probably
> has bigger problems than unsecure wifi ;-)
>
>
> On Sun, Jan 12, 2014 at 5:32 PM, Dan Kegel <dank at kegel.com> wrote:
>>
>>
>> http://security.stackexchange.com/questions/12596/can-a-hacker-sniff-others-network-data-over-a-wireless-connection
>> might explain a bit about the raw wifi part.
>>
>>
>> On Sun, Jan 12, 2014 at 5:29 PM, Jeffrey Kutz <jdkutz_682004 at yahoo.com>
>> wrote:
>> > Interesting question. I am trying to remember back to my Network Design
>> > 101,
>> > where we used wireshark on a wired network. It was my impression that
>> > all
>> > that you needed was to see the traffic and wireshark was happy. It is
>> > really
>> > good security to keep people off of your Wi-Fi by whitelisting the
>> > allowed
>> > MAC addresses but I don't see where this would stop someone from seeing
>> > any
>> > open and unencrypted traffic. I would be concerned that someone would
>> > get
>> > enough information to log onto their private website via a route other
>> > than
>> > the local Wi-Fi. I would even question just where the security of https
>> > comes into play. Is there some open traffic before the http turns into
>> > https
>> > that would allow some evil-doer to cause trouble?
>> >
>> > I will be following this thread with interest. Next year I will get
>> > taking a
>> > security class at my local tech school. You can be sure I will bring
>> > this
>> > whole story up for classroom discussion.
>> >
>> >
>> >
>> >
>> >
>> > On Sunday, January 12, 2014 1:32 PM, Homan Chou <homanchou at gmail.com>
>> > wrote:
>> > A lot of businesses offer free wi-fi access within their walls as a perk
>> > of
>> > being there.
>> >
>> > I have a friend that is a business owner that does NOT offer it because
>> > of
>> > "security" reasons.  In fact, in order to get on his wifi, he can't just
>> > give you the password, he actually has to whitelist your MAC address
>> > into
>> > his router or something like that.
>> >
>> > His web developer set it up this way because their custom point of sale
>> > program is just a website. And they don't use https.  So my question is,
>> > if
>> > that website login form was accessed over non-secure http is the login
>> > just
>> > send in plain text in packets?  Could someone theoretically observe that
>> > with wire-shark without even being logged in to the wi-fi network?  Or
>> > do
>> > you need to be connected to the wi-fi router in order to be able to do
>> > that?
>> >
>> > I think it's the former but I'm not a wire-shark expert, can someone
>> > confirm?  (Either way I will tell him he needs https).  And I want to
>> > encourage him to provide free wi-fi, and if his POS is secured over
>> > https it
>> > shouldn't make his business anymore vulnerable than he is now, is that
>> > correct?
>> >
>> > Homan
>> >
>> >
>> >
>> >
>> >
>>
>