I have trouble decrypting WPA2 WLAN traffic in Wireshark.
I've done research and followed all advises I could possibly find and still cannot decrypt it. There are of course plenty of variables, but I strongly believe I covered all of them, and yet I'm still missing out something.
Basically, all I can view is Probs, Beacons, Null function (No data) and QoS Null function (No data). I connect to the network with my phone and start randomly browsing and can clearly see my traffic is going in Wireshark, but it only Null function (No data) packets.
I've made sure I added [password]:[ssid] to 802.11 and enabled decryption. Always have long streams and full EAPOLs when capturing the traffic and tried on three different wifi cards (Alfa, TP-link & Intel). I have most up to Kali distribution and latest Wireshark version, and tried on someone else pcaps and Wireshark decrypted it successfully.
The only thing I can think of causing this is the driver.
Related
I'm struggling to get an embedded platform with fairly standard IPV4 networking running. I have a working prototype which obtains an IP via DHCP without problem on a point to point connection (single cat5 cable) attached to a test laptop.
On my new hardware I get the link up but no DHCP request gets to the server (monitoring with wireshark). However what I do see, 100% repeatable, when those packets should be received, is a couple of ICMPv6 packets from the test laptop. This happens every time, there is no other activity on that link at any other time.
It seems to me that those packets are trying to tell me something, but what? Perhaps the DHCP request is going out but malformed for some reason?
(I can't post the actual packet from my phone, will make a copy and do so later.)
Seems to be something generated by the laptop when it sees the link comes up. Turned out to be unrelated to the issue I had (which was hardware related).
I have been reading answers on stackoverflow for a while now and this is the first time I actually am required to ask a question:
I have a small sensing device (literally a black box) which is used during sporting activities and is tracking acceleration and GPS data (not necessarily with the same frequency, according to a patent from the vendor). After a session, one can connect the device to a smartphone and import the session data to view statistics.
Now I am trying to acquire the raw data to apply some own statistics onto it.
I know that the device connects to my phone via Bluetooth. So I activated the Bluetooth HCI snoop log following this tutorial:
http://www.fte.com/WebHelp/BPA600/Content/Documentation/WhitePapers/BPA600/Encryption/GettingAndroidLinkKey/RetrievingHCIlog.htm
I can then transfer the files by renaming them into .cap files on the PC and load them into wireshark. This is where it gets tricky:
I have found out, that the first connection is established via Bluetooth low energy. When the connection is established and the user has selected to download a session from the device via the app, the connection switches to a normal Bluetooth connection.
I know that the device contains a GPS and a 9-axis accelerometer including a Gyro.
Apparently the Bluetooth protocol to transfer data is the SPP protocol (https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles#Serial_Port_Profile_.28SPP.29), used to simulate a RS-232 connection.
I have attached a screenshot from wireshark showing a reassembled data packet. I do not know what it contains and the rendering from Wireshark does not make any sense to me. The frame content is displayed in the bottom most tab. The left is the raw HEX transmission, the right shows the rendered version. It neither looks like any GPS sentence (http://www.gpsinformation.org/dale/nmea.htm), nor like any accelerometer data:
The general setting is an encryption-less connection, but at some stage the host and controller try to switch to an encryption, but this never gets transmitted to the peripheral slave (as far as I can see). I am wondering how to make sense of this data, whether there is a way for me to find out whether an encryption is activated and if it is, is it logged and can I retrieve the key from this log?
Can anyone help me to figure out the data here or tell me where I can find some hints about whether it is encrypted or not?
Edit:
I have added a screenshot from the first SPP transmission packet. The packet in question and the payload are marked in black. It seems to contain some information about device and other configuration settings or initial values for the sensors at the beginning. I suspect the app and the device to have settled on a proprietary scrambling or encrypting, since there are readable values at the beginning, but not after that black box marked in the image. My suspicion is, that bluetooth encryption is not being used at all and I therefore stand no chance of decrypting the information at all? Can someone confirm or deny this suspicion?
where I can find some hints about whether it is encrypted or not?
What you see in Wireshark is the HCI interface (commands and events) between Host and Controller. Since encryption is done in the controller (see Bluetooth Core spec. Vol. 1 Part A Section 5.4.3), what you see is unencrypted data.
Can anyone help me to figure out the data here
It's hard to understand from your single screenshot. I suggest you take a look at the RFCOMM specification, Figure 6.1 in paricular:
In the Information field you should find your data.
My work has a login system which doesn't use HTTPS. Login details are transmitted in plain text using HTTP Post.
I isolated the post request which sends the login details using wireshark, and found the username and password in the packets, in plain text.
Could an attacker listen the HTTP POST request wirelessly by being close to client's router or laptop somehow?
Is it even possible to sniff ambient WIFI transmissions by simply being in close range (If so, how)?
Level 1
Network utilities, like wireshark can monitor the TCP/ip network data when they are connected to the network. WIFIs without passwords can be attacked by a closer Wifi router using the same SSID or wifi name. Thus becoming part of your network and monitor tcp/ip network data.
If the WIFI has a password then only those who know the password can be part of your network and monitor the TCP/IP data using this method.
Level 2
Some USB Wifi adapter supports monitor and promiscuous modes (ALFA AWUS036H) or similar and on Kali linux but you can use other versions of linux they can monitor data sent over the WIFI radio signals without being logged in.
tcpdump, pyrit are wifi tools that allow people to capture and anaylze wifi radio traffic normally to pick up all SSID signals, Google may have used these with the vehicles that created google maps street view.
Since the data sent over WIFI may include a http posted data these can be read using these modes.
If the WIFI signal is encrypted then even if the posted data was to an http not https server the data is still encrypted.
Level 3
The government among others have software that can monitor the encrypted WIFI signal wait for an arp request which has a specific length in bytes so it can be identified as an arp request. Then using brute force go through millions of potential encryption keys until one key appears to resolve the captured arp request into a valid arp request. This takes a rather powerful computer running linux with a wifi antenna on the roof sitting next to your home for several hours. Some of the encryption keys are 128 bits, that would be 3 with 38 zeros. So they almost need a supercomputer.
Once they crack the wifi encryption then the only thing standing in their way is the HTTPS encryption, which have 4,294,967,296 possibilities but don't provide an easy method for the computer to determine if the key it has is correct since it does not know what it is suppose to be looking at. None the less it is still crackable by brute force but it will take a long time.
If a strange van with a generator and antenna is outside your home, send random data through the wifi. Something like ay9wwahwh8948yr9sfsahfkh It will never find the encryption key since ay9wwahwh8948yr9sfsahfkh looks like garbage when it gets ay9wwahwh8948yr9sfsahfkh it will think the encryption key is wrong.
LEVEL 4
Government, they go to the ISP and request what sites you visit then ask those sites for your information.
YES THEY CAN, Its call session hijacking.. There are sheer number of these Wifi hacker apps available on the internet. Most notably Wireshark and Interceptor-ng
YES.That the main goal of creating Https protocol
Read this "HTTPS helps prevent intruders from tampering with the communications between your websites and your users' browsers. Intruders include intentionally malicious attackers, and legitimate but intrusive companies, such as ISPs or hotels that inject ads into pages."
To prevent it use https and in our case use Vpn it will help encrpt you credentials.
I'm quite a beginner to Wireshark and I got problem using it, I searched the wireshark wiki but seems no promising results. Hopefully I can get some help here.
I am trying to analyze the network traffic between LG smart watch and Android phone, which all go through bluetooth channel. Now I have got the network traffic log file and I can view it by running wireshark <log_file_name>. Problem is how can I extract and retrieve data, or even just remove the bluetooth header and get the original network layer packet, because I can parse the IP layer packet but bluetooth packet is not what I want and what I understand.
How can I connect a system to a network and sniff for virus/spyware related traffic? I'd like to plug in a network cable, fire up an appropriate tool sand have it scan the data for any signs of problems. I don't expect this to find everything, and this is not to prevent initial infection but to help determine if there is anything trying to actively infect other system/causing network problems.
Running a regular network sniffer and manually looking through the results is no good unless the traffic is really obvious,but I havn't been able to find any tool to scan a network data stream automatically.
I highly recommend running Snort on a machine somewhere near the core of your network, and span (mirror) one (or more) ports from somewhere along your core network path to the machine in question.
Snort has the ability to scan network traffic it sees, and automatically notify you via various methods if it sees something suspicious. This could even be taken further, if desired, to automatically disconnect devices, et cetera, if it finds something.
Use snort: An open source network intrusion prevention and detection system.
Wireshark, formerly ethereal is a great tool, but will not notify you or scan for viruses. Wireshark is a free packet sniffer and protocol analyzer.
Use the netstat -b command to see which processes have which ports open.
Use CPorts to see a list of ports and the associated programs, and have the ability to close those ports.
Download a free anti-virus program such as free AVG.
Setup your firewall more tightly.
Setup a gateway computer to let all network traffic go through. Take the above recommendataions to the gateway computer instead. You will be checking your whole network instead of just your one computer.
You can make Snort scan traffic for viruses. I think this will be the best solution for you.
For watching local network traffic your best bet (with a decent switch) is to set your switch to route all packets out a specific interface (as well as whatever interface it would normally send). This lets you monitor the entire network by dumping traffic down a specific port.
On a 100 megabit network, however, you'll want a gigabit port on your switch to plug it into, or to filter on protocol (e.g. trim out HTTP, FTP, printing, traffic from the fileserver, etc.), or your switch's buffers are going to fill up pretty much instantly and it'll start dropping whatever packets it needs to (and your network performance will die).
The problem with that approach is that most networks today are on switches, not hubs. So, if you plug a machine with a packet sniffer into the switch, it will only be able to see traffic to and from the sniffing machine; and network broadcasts.
As a followup to Ferruccio's comment you will need to find some method of getting around your switches.
A number of network switches have the option of setting up port mirrors, so that all traffic (regardless of the destination) will be copied, or "mirrored", to a nominated port. If you could configure your switch to do this then you would be able to attach your network sniffer here.
Network Magic, if you don't mind something that's not open source.
You can use an IDS, hardware or software
http://en.wikipedia.org/wiki/Intrusion-detection_system