Arp table showing incorrect mac id's



  • 2.2.4 AMD64

    Setup various vlans, but add a spoofed mac id for each vlan interface,

    The MAC ID's in the arp cache/table (Diagnostics, Arp Table) show the spoofed mac ID's, but Interfaces (Status, Interfaces) show the wrong mac ID's, and switches also show the same mac id information seen in Interfaces.

    EM nic used.

    Going to check this out in OPNSense & hardened OPNSense as a thread on their forum https://forum.opnsense.org/index.php?topic=1336.0 also suggests a similar problem, to see if this is at the FreeBSD OS level.

    @Dok, iirc you suggested usb nics dont work, I've got a copy of the malware that was embedded in the usb nics I was using so thanks for the heads up.

    This 64MB bit of code (small enough to sit in the typical disk cache in hard disks having rewritten the firmware I guess), interestingly it migrates using USB, appears to have its own file system not recognised by all the FS listed in (G)parted, zeroing with DD does nothing as it copies itself back into place after a DD wipe, which you can only see by doing a sector by sector lookup in a hex editor for any non zero's, and also appears to deliver a suite of windows viruses which can be used for things like GEO IP look up, is using BootP perhaps to exploit virtualisation facilities in cpu's and/or redirect network traffic through another virtual interface, and using techniques like a JPG to store data in amongst other things.

    All in all a nifty bit of coding, which has impressed me and proved some of the things I have theorised would be possible.

    Whats also interesting is that all Linux CD's are generally not hardened sufficiently when run Live, so the USB bus (I'm guessing here) is being used to propagate this code around unsuspecting IT experts to their clients, plus I also suspect the UEFI bios is also being used as a sizeable storage container (32M) and its possible to access the UEFI bios across the network, upload a new bios amongst other things.

    Anyway thanks for the heads up, its been an educational 4 weeks examining this, learning things on the fly, watching how the sock puppets react, now I just need to find a way to over come the "BT phorm" style network injections.  :)





  • Thats a pity and explains what I'm seeing with this setup, so for now I cant use switches which tag packets with a vlan id based on the originating  mac id.

    Why would the ARP table show me the correct info though, but the Interfaces dont, shouldnt both pages in the gui be at least consistent with the data it presents?

    Put another way, I've less confidence with the data seen in the ARP table and I now also wonder what other info elsewhere like system logs or syslogs is not accurate.

    Anyway thanks for the link.



  • Same problem in HardenedBSD as well, fortunately the backups/restore's for both seem to work in the main although HardenedBSD threw up an error so not too much time testing.

    Whats also interesting to note about this is that all of the Vlans have the same MAC ID assigned in the 2nd from last vlan in the GUI description order, and the last Vlan is the only one to have the correct MAC ID if that is significant in getting this to work, so some where in the code (havent looked) it would seem to be looking up the MAC ID's at the time of setting up the interface properties but getting stuck or a counter/pointer is getting stuck on the 2nd from last MAC ID for all the Vlans in GUI description order, which could (dont know havent looked) have ramifications for other parts of the system set up.

    For a possible workaround, I also changed the spoofed MAC ID in an individual interface/Vlan, clicked apply and the switch detects the newly changed spoofed MAC ID in other interfaces/Vlans, so although it would appear from the gui that an individual change to an interface/Vlan is only taking place it is affecting interfaces/Vlans, indicating some or all the interfaces/Vlans are being reloaded. Dont know if this would be different with active states on the various interfaces/Vlans as all these interfaces/Vlans have no traffic going over them yet.

    Edit. One other thing I failed to mention having been through the Redmine link in more detail, the LAN interface is just em0, wan and everything else is a Vlan and the em0 interface has no spoofed MAC ID but it does have its own MAC ID specified in the GUI, but the switches still detect the em0 LAN interface with the 2nd from last MAC ID in GUI interface description order, so I would err more towards it being a bug and not simply a case of needing the nic to be in promiscuous mode.

    Edit 2. Whilst this remains unresolved, its not going to take much effort to update the prompt text to hilight the fact spoofed mac's dont work on vlans, just so users stay informed.

    fwiw.



  • It will almost certainly take more than promiscuous mode to make this work. The chances are that some or all of the NIC's hardware offloading features will need to be switched off for it to work, especially the offloading features relating to VLANs. Exactly what needs switching off will likely change between different families of NIC and maybe between different NICs in the same family.



  • The irony of what you suggest is, that the current setup where it shows hot plugging messages on the console is the only indicator I have when I plug an infected machine into a pfsense managed network and pfsense becomes compromised.

    Theres obviously a zero day lurking in freebsd and its quite likely to be the same one in Linux as so much code is similar across the open sources OS's, with TinyOS being an example of how bloated software has become to present the Bling to users.

    Other indicators which admittedly I only noticed a moment ago but have suspected for a while now, is the pattern is the same across windows and debian OS's (not tried other OS's yet), is that after downloading something in the browser, the infected machine then also runs the default program associated to run or process the file extension, eg in windows, if I download the pfsense backup, the infected machine then loads the xml in windows explorer, in debian if I down load a zip file it loads the default associated archive extractor program which is the change of behaviour.

    People not familiar with this change of behaviour will accept it as an improvement in automation even though a machine installed from a CD and not connected to the net can't update itself!  ::)

    Its good though as Windows didnt bat an eyelid when it got infected, FreeBSD shows a nic hotplug event on the console (possibly in the system logs as well although I havent seen them if they appear there), and the source of the hack might be the RaspberryPi downloads of all places, but need to test this theory that the Rpi downloads are the source, once I have cleaned and reinstalled the machines here again which takes time due to having to wipe all disks, mem stick and SD cards properly and then check them in a hex editor. DD seems to work quite well with a 64K block size incidentally.  ;D

    Thank F*$% for Windows XP installation CD's which does a full format of the hard drive during the installation process, everything else just leaves the infection in place as it just writes the partition table but nothing else, even though this thing modifies the partition table, so you cant see it in Gparted or the Windows Disk manager where you can mess with the partitions. I suspect what its doing is using sectors marked damaged in some way to hide itself smack bang in the middle of the memstick or SD card, or hard drive.

    Edit. On the point of breaking encryption at the firewall, people/businesses should block all encrypted data across their lan as they have no way to account for it. A zero day in your webbrowser transmitted from an encrypted website is bad for your security as you simply cant account for the encrypted data travelling across your network. Ideally people/businesses would have all their network traffic running unencrypted so that IDS systems like Snort and others can inspect everything going across it. In additional packet capturing everything passed over the network makes it easier for retrospective analysis after a hack has taken place, whether this is down by the switch with port mirroring or using a (win)pcap driver like wireshark on individual machines is down to your hardware & network capabilities. Besides all the encryption/decryption taking place is an additional capacity overhead which over time is not environmentally friendly either. So things like SSH used internally is a waste of time as you cant see whats going on. Internet side, yes use encryption if you want to protect corporate secrets, but also consider things like MS Exchange pushes all your emails to you phones so things like MS Echange with a zero day on your phone is another attack vector for harvesting email contacts which might be lucrative.



  • @firewalluser:

    The irony of what you suggest is, that the current setup where it shows hot plugging messages on the console is the only indicator I have when I plug an infected machine into a pfsense managed network and pfsense becomes compromised.

    Well sod's law I cant replicate the hotplug event again.

    Having read this thread https://forum.pfsense.org/index.php?topic=66908.0 as well as this thread https://forums.freebsd.org/threads/powerd-and-usb-nic.39207/ and a few others including some man pages, even though I'm using the built in intel motherboard nic (em0) with bios updates up to date I simply cant replicate the hotplug events.

    This was a default mem stick install with just vlans configured with 2 devices (a pc and rpi) connected to their own individual vlan. PowerD is off by default so shouldnt have been a factor, but seeing the hotplug event when I plugged a running rpi into the switch made me believe this caused the hotplug event to pop up on the console (didnt check system logs but since found out they do appear there).

    Whilst I was thinking this through, it did occur to me that monitoring the usb bus in much the same way a nic is monitored with IDS/IPS just doesnt exist.

    AV has it flaws, namely they have to find the virus first before they can search for it.

    Even then AV mainly just scans storage devices beit disks, cd's, floppies, network shares & mem sticks, for root kits and their like, some will also scan memory, but not very efficiently.

    DuQu2.0 I noticed when reading up the Kaspersky pdf's have only found traces of it on windows systems. Linux CD's are not hardened out of the box and having been hacked via linux which destroyed windows and backups, all my backups will be on read only DVD's from now on. But this got me wondered just how insecure systems are.

    It turns out you can remote access UEFI bios, some motherboards also come with 32MB of space for the UEFI bios when the bios code itself may only be 4MB in size, and theres some very detailed presentations around which show how easy it is to hack the UEFI bios as well as the old style and compromise them, one is only limited by their imagination as to the possibilities.

    It's possible to rewrite the firmware of some disk's so you could also use the cache to hide during runtime, and store to disk at switch off, in effect being able to hide from AV mem scans. Again skilled programmers needed, but not impossible https://www.reddit.com/r/netsec/comments/1jkuts/flashing_hard_drive_controller_firmware_to_enable plus it also crossed my mind, could the network cable in a rpi be used as a wifi antenna. I dont know as havent taken one apart, but when trying to isolate and eradicate whatever hit my system, its only by having some old software from the 1990's which gave me the break to see hidden 64mb partitions on memsticks as nothing showed up in gparted, but I could clearly see it when I did using wxhexeditor. Even now those memsticks are still isolated until I take them apart.

    So all in all, OS's and many industry standard practices still leave systems wide open for some serious hacking and I dont think most people have a clue just how easy it is for hackers with suitable funding.


Log in to reply