I`m working on a project about Man In The Middle Attack by ARP poisoning method.
In this project I need to work like as a router. For example suppose In My Lan there is two other device (a modem & a laptop). I says to laptop that I`m the modem to fraud it. whenever the laptop wants to send a packet to outside of the LAN, sends the packet to me!
All thing I need is I want to send the received packet to the modem & sends the response to victim laptop.
How can I do it programmatically?
Thanks a lot.
Ya Ali.
Well the first thing you need to do is perform the ARP poisoning attack. You can review how to do this in detail here.
One thing of note is that your middle-man PC must how be able to perform like a switch and forward out packets it receives in - It will be passing packets between the modem and the laptop in both directions.
Related
I have an application that is very simple. It sends out UDP packets to a client somewhere else on the network.
The host computer is 192.168.11.66 (Windows 10), the client device is 192.168.11.65 (proprietary device).
The host pc cannot see the client device, however I know that it is on and listening to traffic. When I send UDP packets from the host, I use Wireshark and I do not see the packets being sent out. Instead I see messages from ARP trying to locate the client. I assume because ARP is unsuccessful, the host cancels the sending of the packets.
If I change the destination address of the packets to a broadcast address, all of the packets get sent and I see everything on Wireshark. I need to be able to specify the IP address of the client and have Windows send the packets regardless of whether or not it thinks the client device is on the network or not. The client device looks for UDP traffic specifically addressed to itself and the client device has no way of making itself visible on the network.
Does anyone know how to work around this?
Thank you #Remy: instead to create your own ARP record manually. – Remy Lebeau
I did not realize that I could create manual entries in the ARP. I need to read more about ARP. Adding a manual entry solved my issue. I found that you could do it using ASP -s, or add neighbor using NETSH .
Thanks!
I can't wrap my head around how packet-sniffers can be used by anyone on the network.
I know very little about how networks work, but let me put it this way: suppose the mailman comes around delivering a package to my doorstep. Why is is that I'm able to rifle though all his other packages and look around? Shouldn't the mailman only hand me packages that are mine?
To quote William Pursell's comment, which he should have made an answer and should have expanded:
The mailman does not deliver the letter your doorstep. Instead, he opens your mail and shouts out: "this letter is for <name>. No-one else should listen" and then proceeds to read the letter out loud. –
In the original Ethernet network, there was a shared cable to which all hosts were attached; if a host wanted to send a message to another host, it would transmit the packet on the shared cable, with an Ethernet header with the destination Ethernet address of the other host. All hosts on the cable could, in theory, see the packet. (This was in an era where security was less of a concern; for cases where security was a concern, the packets were encrypted in a fashion that the other host could fairly easily decrypt but that other hosts would have to decrypt in some other more difficult fashion.)
In addition, a packet can be sent to the "broadcast" Ethernet address (all 1's) or a "multicast" Ethernet address (which several hosts are configured to handle); broadcast packets are intended for all hosts on the Ethernet to see, and multicast packets are intended for all hosts in the address's "multicast group" to see.
Normally, an Ethernet adapter would ignore packets that aren't sent to its Ethernet address, to the broadcast Ethernet address, or to a multicast address for which it's configured to receive packets. Most can, however, be put into "promiscuous" mode, where they pass all packets to the host; that mode is used for packet sniffers.
Most current Ethernets are "switched"; instead of a shared cable, there's an Ethernet switch, and hosts plug into the switch with a cable. Packets sent to a particular host's Ethernet address will only be sent out the switch port for that host (unless somebody's configured the hosts to have a "mirror port" on which all traffic is sent, or unless the switch hasn't yet determined which port is the port for that Ethernet address). Broadcast packets are sent to all ports, and multicast packets may be sent to all ports or, if the switch can determine that, to those ports that have adapters configured for the multicast address in question.
Wi-Fi networks are similar, but they're usually protected with encryption, as it's easier for somebody to bring in a laptop and put it into "monitor mode" to sniff on a given channel than it is for somebody to bring in a laptop, configure a switch to have a mirror port (or use some other mechanism to get access to the traffic), and plug the laptop into the appropriate port on the switch.
Generally speaking, with switches you are correct. However the person who owns the switch can intercept your traffic at will (in your example that would be the mail service). Also, sometimes the switch can be fooled into rerouting traffic (someone accepts the package on your behalf and then goes through it).
Furthermore, certain kinds of packets need to be broadcast. For instance ARP packets (where one computer is asking for the ethernet address of another computer specified by IP) get broadcast to all ethernet addresses and therefore can get sniffed.
Generally speaking man-in-the-middle requires someone in the connection chain to be compromised. For instance, your ISP or the company they buy transit from could create a man in the middle attack. (This is also why security in countries oppressive regimes is so difficult, they control the internet and therefore can sniff/man-in-the-middle attack whatever they please). This can also be done by compromising the DNS server you use to point you to a different site that can grab your data and forward your data (or a modified version thereof) on to the true site.
In the good 'ol days hubs were quite common (or even older, everyone shared a piece of coax). In this case it's more like the package gets dropped on the first door, the occupant looks to see if it's theirs, if not, passes it on, if so, copies what's inside and passes the package along. In other words, packet sniffing is actually quite easy.
Yes or more simple way packet sniffing not is good, while you login on the web page you normal use a secret password for verify this is you.
But in case we has a packet sniffer she/he can also see and read what you password is.
And laiter login in the web page as you.
Or in she/he can also modify you data on the road to do something other.
And in the case of internet, the normal way is more the one computer is use to
send a message from in this case Alice to Alice bank.
And in each of this computer ( right side of image ) is this possible
for the use to edit the message if the use want as in this image.
Eva is use for deliver the message to Alice Bank, but she can
can read the message/order and in some case edit this to get the bank
to think Alice want to transfer money to Eva instead of Bob.
In short for protect us against eva to modify the message we can use
hash-algorithm or cryptographer algorithm.
I have had this irritating issue for some time now. Basically, I like to leave my iMac sleeping but leave it listening for WOL packets for remote access. I know that Macs will wake every 2 hours or so to register with their base station (if you have one) but they immediately return to sleep.
My problem is that due to whatever reason (presumably something like bots sending out magic packets to random IP addresses and trying passwords to gain access) whenever the Mac receives a magic packet, it wakes (display still off) but doesn't go back to sleep if it receives no further network activity.
I downloaded sleepwatcher but I'm not really sure how to use it properly. I think I basically need a very small piece of code that waits maybe 30 seconds and if no network connectivity is detected, goes back to sleep. I know that requesting code is usually frowned upon here and I usually don't but in this instance, I'm struggling with where to even begin.
As a side question, is it possible to log the IP address that sent the magic packet? That could be helpful too, if it is coming from the same IP, I can simply block it.
I'd really appreciate any help on this.
Thanks,
Scott
My application communicates with several GSM electric controllers, that means that I have to send anywhere between one to twenty messages every few hours. right now I'm working with HUAWEI Mobile Connect - 3G. it is a USB device that uses a comm port for the pc communication and I'm using GSMComm to send messages and read/delete messages from the device.
Every two seconds I'm checking the device's storage, and if there is any message, I will then read it and store it locally and then clear the device's storage. I'm not sure if I'm working correctly, but it seems to me as if it is a very unreliable device:
Every time I boot my machine, I must remove the device from the USB or my machine will get stuck at the BIOS start up screen (or whatever the name is).
Very frequently the comm port can become unavailable for some reason. I have to close and re open the port, and at times that may not even help.
In the production machine of my client, when he uses one of his software's that utilize the first comm port, he will get a warning message from the software about problems in the port if the device is plugged in (the device port is around 28 or something).
If you've been using a device which you consider reliable, or have been working with the same device as I work with, or you just think that I'm doing it wrong, I'd like to get an advice from you.
Thanks.
This sounds like an issue with your modem. Have you tried any other models? Consumer USB models tend to be unreliable. The preferred method, though slightly more expensive, is using a commercial grade modem in situations where you need the reliability.
Some modems to look at:
Wavecom Fastrack
Sierra Wireless Airlink
These use a serial port or ethernet to communicate with the host which is far more reliable. Serial ports may not be available in your particular situation but even a USB to RS232 adapter will be more reliable.
One further option is to use a smartphone, there are several applications that you can act as a gateway through HTTP.
SMS Gateway for Android:
https://market.android.com/details?id=eu.apksoft.android.smsgateway&hl=en
i have not used this method, but it seems like some people are having luck with it. it may not be any more reliable then your USB modem though.
Hope that answers your question.
I have used WaveCom's modem for sending messages in bulks and found it to be reliable. One difference though, in my implementation was i used Kannel as an SMSC, so my queues were automatically handled by Kannel. But sending multiple requests like 40+ per minute didnt pose any problems for me.
Hope this helps.
I am working on a project that involves a usb device, through which we will receive ip packets from a remote pc. We assign the remote pc its IP Address. I have been experimenting with sending raw ip packets via several methods:
1 - raw sockets: ping works fine, problems sending tcp
2 - tun/tap W32: I managed to get this working enough to send pings out and get pings back to the phy ethernet device, but could not read them using ReadFile(...) on the driver guid.
3 - winpcap: ping works, out going tcp shows up on wireshark(so I assume it is leaving the pc), but i never get an ack to my syn. Im also worried that if I did get an ack the windows TCP stack would send a rst.
Our goal is to be a transparent pass through from the client pc to the network.
Client <-wrapped ip packet-> [device] <-wrapped ip packet-> WinPC <- IP -> IpNetwork
Its possible that im going about this wrong, seems like this should be easier.
I realize that windows is prob not the ideal OS for this, however I have no control over the OS.
thanks in advance
Fixed my issue with TCP Syn packets not getting acked, turns out I forgot to include the pseudo-header when calculating the TCP header checksum. Now it looks like the tcp handshake completes, so im calling this problem solved. If anyone feels like recomending a better way to accomplish this, feel free to reply. For now looks like we will use the winpcap method.
Update:
For this to work without windows constantly RST'ing tcp connections, you have to enable internet connection sharing(ICS) on the adapter you are sending packets out of. Other than that this ended up working for us.