A tool for network enumeration, protection, observation and domination. Omphalos makes use of passive and active portscanning, DNS/DHCP/Zeroconf server interrogation, portknock detection, covert channel detection and establishment, ARP scanning, automatic WEP cracking, man-in-the-middling, and a whole host of other tricks. GPS integration? Oh yes. Coordination across multiple interfaces? Of course. Use of Linux's MMAP_RX_SOCKET and MMAP_TX_SOCKET? Wouldn't have it any other way. Userspace networking is made visible to the host via a TUN/TAP device. While designed as an offensive tool, omphalos has proven useful for network debugging and troubleshooting, as well as experimentation.
- The latest release is 0.99.7-rc1, released 2013-01-30.
- Debian-compatible .deb files are available via the SprezzOS APT repository
Omphalos is not a "point-and-click" tool so much as "pull the pin" or perhaps "spray the area". Default behavior is to redirect and seize all traffic, attack weak cryptosystems, archive authentication materials, and learn everything that can be learned. Ideally, a tiny microprocessor would be paired with power and a network device, stealthily physically inserted into a network, and left there; omphalos and liburine would then combine to provide complete network dominance. I hope to combine network programming and the techniques of high-performance computing to create a tool capable of much havoc.
- SSLSNIFF from Thoughtcrime Labs
- ettercap by Alberto Ornaghi and Marco Valleri
- Netdiscover by Jaime Peñalba
- NetworkMiner from NETRESEC AB
- JDisc Discovery from JDisc UG
- LanTopolog by Yuriy Volokitin
- Miranda by Craig Heffner
We want to defeat systems like:
- ArpON by Andrea Di Pasquale et al
Omphalos implements all or portions of the functionality of the following tools:
|0.98 (initial alpha)||2011-10-07 (actual)
|0.99.0β (initial beta)||2011-12-01 (actual)
Some planned, some implemented...
- Modes of operation governing automatic behavior, from "Silent" to "Hostile":
|Silent||Take no actions, only watch.||
|Stealthy||Take only the actions of a normally-configured host.|
|Active||Learn what we can, possibly standing out from the crowd.||
|Aggressive||Learn things quickly, in ways that will be noticed.||
|Forceful||Actively disrupt the network, rerouting traffic through us.||
|Hostile||Attempt to make the network unusable.||
- GPS coordination and tagging
- Fully dynamic behavior viz the networking stack. Add and remove cards, routes, addresses...
- Audiovisual plugins (FIXME detail! lots of good ideas here)
- Event/scripting engine
- Full integration with POSIX capabilities for fine-grained security (nothing runs as the superuser)
- Covert channel detection at all layers via Zetetic
- Opportunistic, secure remote control via liburine
- Network analysis and debugging ought be spun out into Dr. Benway
|Layer 2|| From both packets and netlink:
|Layer 3|| From both packets and netlink:
We don't want to track network addresses beyond our broadcast domain. That's difficult to determine, however, without a working routing configuration (ie, an address). We'll thus assume that RFC1918 membership or service of an L2-restricted service (like DHCP or Zeroconf) indicates local presence (if it doesn't, it indicates misconfiguration). This means that
|Layer 4|| From packets:
||We don't use the local configuration because there's no unified API to access it, nor track changes to it. We'll detect DNS quickly enough if anything's actually using the network, and can partially detect host DNS servers simply by kicking off a query through the standard resolver library (even if we don't use the provided result).|
Analysis and Attack Capabilities
Physical Layer Support
|Protocol||Standard||libpcap linktype||Linux ARP type||Analyzed?|
|Linux Cooked Capture||packet(7)||DLT_LINUX_SLL||N/A||Yes|
|Token Ring||IEEE 802.5||DLT_IEEE802||ARPHRD_IEEE802_TR||No|
(Serial Line Internet Protocol)
| PPP (Point-to-Point Protocol)
||RFC 1661|| DLT_PPP
(Fiber Distributed Data Interface)
|Fibre Channel||RFC 2625||DLT_IP_OVER_FC||
(Infrared Data Association)
(Link Access Protocol - D Channel)
For more information, see the Topology Discovery page.
- Detect physical hosts on the network via MAC analysis
- Classify as locally-generated, multicast, etc
- Flood a network with spoofed MAC addresses, in the hope of forcing fail-open behavior to facilitate attacks (see macof from dsniff and Hacking Layer 2: Fun with Ethernet Switches from BlackHat 2002)
- Probe and autodetect CAM sizes and hash functions, allowing for minimal CAM overflows
- Autodetect host ARP timings and replacement policies, allowing for stealthy man-in-the-middling
- Reverse and direct man-in-the-middling (answer all queries for an address, from an address, or both)
- Gratuitous ARP ("enclosure")
- Controlled SNAT of outgoing traffic at layer 2, to create multiple realistic hosts ("Capgras delusions")
- Automated ARP jamming and man-in-the-middling
- Arpwatch-like layer 2 monitoring
- VLAN hopping
- Passively attack weak cryptosystems (especially WEP), or do so actively if configured
- Channel hopping or locked operation
- Spectrum and noise analysis plugin
- Respond as master to probed networks, on a to-order basis
- Ability to run omphalos in as an AP client via userspace networking atop radiotap (Monitor mode) and WPA/EAPOL support
- Or, more likely, some kind of hostapd control using Master mode
- "Hole 196" injection
- Viehbock's WPS EAP-NACK brute-force attack (US-CERT #723755)
- ICMP redirects
- We're closer than the remote server; jam ours in, and let the real one be tossed as duplicate
- A whole world of IPv6 mischief
- Rogue DHCP service
- SNAT for routing enbondaged neighbors
- ...much more
- TCP assassination (via RST) / arbitrary corruption
- Most TCP implementations will (usually) deliver the first bytes received for a given window
- UDP assassination (via ICMP) / insertion
- Cryptographic downgrade attacks on HTTPS etc
- FireSheep- and BEAST-like session hijacking
- Progressive user identity/demographic discovery aka "maximum creepy" (heuristics on machine name, web pages visited, accounts revealed, mails sent etc)
- Watch for and aggregate probed wireless networks, DHCP lease renewals, etc
- Rogue DNS service
- File-and-signature association for insecure checksums + csums updated-to-order
Omphalos currently only runs or indeed builds on fairly recent Linux systems, due to extensive use of advanced capabilities of the Linux networking stack (and the small fact that I don't run anything else). I doubt that I would accept patches to add Windows/MacOSX support, but you're certainly welcome to maintain them yourself. Once the main functionality set is complete (0.98 release), I'll add support for falling back to plain old PF_PACKET sockets without ringbuffers; that ought add support for any UNIX-based OS with a basic rtnetlink implementation.
- omphalos-tty: line-based console output with readline-based input
- omphalos-ncurses: screen-based terminal output with ncurses-based input
- GTK: I'd like to add a GTK UI, but it's not a major priority
- If you'd like to contribute freely-licensed, original artwork to this effort, please contact me!
- WxWidgets, QT: Dubious that I'll add one, but I'd take patches.
- Java: nope
Transcluded from top of my git repository at GitHub.
*omphalos* by nick black <email@example.com> ============================================== "Gaze into your omphalos." - James Joyce, Ulysses Omphalos is an integrated tool for network enumeration and domination. It is designed around Linux's rtnetlink(7) layer and PACKET_MMAP capabilities. Whereas other tools are geared towards either reconnaissance or directed attacks, omphalos is designed to "spray the area". I. Requirements II. Building and installation III. Usage IV. Hacking V. FAQs VI. Thanks =================================================================== I. Requirements =================================================================== GNU Autotools are used to build the configure script. They are not necessary when building from a release tarball. A C compiler is used at buildtime. libsysfs, libnl3, libpcap, libpciaccess, libz, libiw and libcap are used at both build and runtime. Omphalos currently only builds or runs on a Linux kernel with PACKET_MMAP sockets. Packet transmission requires at least a 2.6.29 kernel. The TTY UI requires GNU Readline. The ncurses UI requires libncursesw (ncurses with wide character support), and libpanelw (distributed with SVR4 curses and ncurses). The X UI requires libX11 and friends. arp-scan's 'get-oui' program is used to build the IANA OUI file. wget is used to download the USB ID file. GnuPG is used to verify signed tarballs. Manpages and XHTML documentation require xsltproc and docbook-xsl. Your TERM and LOCALE/LANG environment variables need be correctly set to make full use of omphalos-ncurses. Ensure that a UTF-8 locale is being used, and that your terminal definition supports 256 colors. =================================================================== II. Building and installation =================================================================== If compiling from checked-out source, run "autoreconf -fi -Wall,error" to build the initial configure script (a configure script will be present in release tarballs). "./configure && make && sudo make postinstall" ought be sufficient to build and install Omphalos. Run "./configure --help" to see supported build parameters. If filesystem-based capabilities are supported, it might be desirable to bestow CAP_SETUID privileges (this is *not* equivalent to a setuid binary). See "Usage" regarding switch to the "nobody" user when CAP_SETUID is possessed: this can help defend users from malicious files, even if they're not allowed to open packet sockets. If non-root users should be able to use network capabilities, add CAP_NET_ADMIN and CAP_NET_RAW to the binary. This can be accomplished by running "make sudobless" or running tools/addcaps. If MADV_HUGEPAGE is available at compilation time, madvise() will be used to advise hugepage backing for important, large data structures including the ringbuffers. This could improve performance. To restore an omphalos directory to its pristine form, ensure a Makefile has been generated via ./configure, and run "make maintainer-clean". =================================================================== III. Usage =================================================================== Several capabilities are required for omphalos's usage of packet and netlink sockets. Omphalos *does not* need to run as root, and generally should not be. See "Building and installation" for details on setting up the omphalos binary's privileges. If omphalos possesses the CAP_SETUID capability (as it always will if run as root), it will by default attempt to become the "nobody" user. This can be suppressed via an empty argument to the -u option (-u ""), but helps defend against malicious input. Some fonts do not support the full range of Unicode glyphs used by omphalos, or render them in an unexpected way. Fonts known to cause problems include: - Terminus (vertical lines don't match up with rounded corners) - Computer Modern (lmodern) (numerous problems) - Cortoba (numerous problems) - Courier (spacing issues) - Electron (numerous problems) - FreeMono (spacing issues) - Nimbus (spacing issues) Fonts known to work include: - Arial - Bitstream Vera Sans - Comfortaa - Consolas - DejaVu Sans Mono - Droid Sans Mono - Inconsolata - Junicode - Liberation - PragmataPro - Sansation =================================================================== IV. Hacking =================================================================== ======================================= IV.A Networking ======================================= We cannot assume that we will see all control traffic, due to switched networks, wireless topography, physical/network-layer encryption and drops. Packets can be dropped (possibly silently) at the card, in the networking stack (thus being neither copied nor processed), or due to a full ringbuffer (thus being processed but not copied). It thus cannot be assumed that all packets processed by the machine are able to be read, nor that all packets seen on the wire even generate a statistic. We cannot transmit with another station's hardware address; this will not be generally allowed in a switched network. We cannot assume that we have an IP address on a local network; this requires configuration, and will never be the case for eg a bridge. We cannot assume other hosts are not misconfigured, broken, or adversarial. ======================================= IV.B UIs/clients ======================================= Callback functions might be called by any number of different threads, possibly concurrently. No relationship can be assumed between threads and callbacks. Callbacks are like interrupt handlers. There is a finite ringbuffer for incoming packets. Packet handling must proceed at wire rate, or else the ringbuffer will eventually be filled up. GUI events cannot generally proceed at wire rate, so packet handlers must generally aggregate events and dispatch work. You can associate opaque state with an object passed to a callback by returning a pointer to that opaque state. Returning NULL will disassociate any attached opaque state. Don't keep a private store of things like interface data or network sessions; use the general accessors. It's fine to create threads in your UI, but do not do it until after calling omphalos_setup(), since this drops permissions and sets up signal masking necessary for cancellation to function properly. If there are signals your UI threads must handle, mask them prior to calling omphalos_setup(), unmask them in the handling thread, and remask them prior to calling omphalos_init(). Masking them prior to calling omphalos_setup() is not currently necessary, but will be should it ever spawn threads. A diagnostic callback must be defined. omphalos_setup() will provide a default fprintf(stderr,...) callback; you can change it prior to calling omphalos_init(), but omphalos_init() will error out if it is set to NULL. There is not yet any means to manage diagnostic output in omphalos_setup(). A packet callback will only reference an incoming interface for which the device event callback has been successfully invoked, without an intervening device removal callback invocation. A device removal callback can be invoked with no corresponding device event callback. Host callbacks follow the same rules as packet callbacks with regard to device callbacks. ======================================= IV.C Porting ======================================= Omphalos uses several advanced features of the Linux kernel directly, and many use cases require other functionality. Porting will involve, at minimum: - a means of reading packets from the wire (traditional packet(7) sockets, libpcap, etc) - a means of transmitting packets on the wire (traditional packet(7) sockets) - a means of acquiring link, address, route and neighbor information from the kernel (we use rtnetlink). this has traditionally been a messy set of ioctl()s on linux, which would have to be poll()ed. - a means of acquiring physical information from the kernel, especially for wireless devices (we use nl80211). - a means of dropping general privileges, but retaining those capabilities necessary for network activity (perhaps a client/server process pair' communicating over PF_UNIX sockets). ======================================= V. FAQs ======================================= 1. omphalos-ncurses exits immediately after printing "Entering ncurses mode..." 1A. initscr() is probably calling exit() because it couldn't set up your terminal. Ensure the TERM environment variable is exported, and correctly set for your terminal type. 2. I see hosts with 0 packets sent or transmitted. 2A. Most likely they were present in your system's ARP cache. 3. I see a lot of "protocol 0800 is buggy, dev XXX" messages in dmesg. 3A. This is a diagnostic issued by the kernel's packet socket mechanism. It will show up if you run tcpdump, wireshark, or any other user of PF_PACKET sockets on the interface. It has nothing to do with omphalos or the packets it generates. ======================================= VI. Thanks ======================================= * Jeremy Stretch of PacketLife.net, for supplying PCAP-format unit tests. * Peter Jensen <firstname.lastname@example.org>, patch [master f9fee3b] * Robert Edmonds <email@example.com>, for Autotools advice and assistance interpreting DNS packet captures.
Data Organization and Entry Points ================================== Our input sources include packet sockets, the operating system's netlink infrastructure, filesystem events, and UI events. Actions invoked by the UI and service interrogations performed automatically by omphalos will most often operate naturally at layer 3 or above: a port scan cannot be run against a MAC, nor can a DNS request be issued to one. Inputs from the packet socket, however, are most naturally keyed off of layer 2 (especially since a given layer 3 address can show up on multiple layer 2 networks, which MAC addresses' global uniqueness property makes less common). The netlink layer, meanwhile, refers almost exclusively to logical interfaces, and various device properties are associated with physical interfaces. It must be remembered that misconfigured and adversarial peers can violate the expected properties at any layer save the physical. Other cases to consider, with definite effects on network modeling, include: - multipath routing - line bonding - proxy ARP - disconnected IP networks (local overload of global IP space) - multiple cards on the same medium - multihoming - fail-over/load-balancing - unconfigured local networking - movement among physical networks without local networking changes - same mac address on different networks - overeager dhcp - etc. ... Furthermore, omphalos might run in an environment not meaningfully supported on a typical networking stack, for instance one where two interfaces are connected to two distinct media which happen to use the same RFC 1938 or RFC 4193 addresses (Linux would treat this as the same network, and freely route from either interface). Since we present an interface-centric UI to the user, and retain knowledge of routes as implied by observed traffic, we can meaningfully distinguish across destination network addresses seen on multiple media or from multiple hardware addresses (using this information, of course, represents a deviation from configured routing policy).This is an explicit objective: a fundamental goal of omphalos is to discover routes beyond the local network, even when no configuration exists. Otherwise, we could simply make use of the kernel routing and neighbor caches, and be done with it. Knowledge Forward ================= Upon receipt of a packet, we know ab initio: - the interface on which it was received, *if* we use sockaddr_ll (sll_ifindex field), or we're binding a SOCK_RAW socket to each interface. We're doing the latter. - whether it was ours or not, *if* we use sockaddr_ll (sll_pkttype field). we're using SOCK_RAW with our AF_PACKETs, though, since SOCK_DGRAM doesn't provide us with the destination address. - source hardware address (sll_addr, or look at the physical header) and address length *if* we use sockaddr_ll (sll_halen field) or we're binding a SOCK_RAW socket to each interface, after discovering its hardware address length. Note that this assumed all hardware on a given medium have the same hardware length. - destination hardware address *iff* we're using SOCK_RAW. - physical layer protocol (sll_protocol field, or look at the physical header). - length of the frame Of these, the addresses and protocol are set by the sender. Everything else can be trusted as objectively "accurate". There's a fine line between an adversarial deception and reality, however. If an adversary spoofs a MAC address and IP address, and provides service on it, treating this as another host is not a problem. If an adversary successfully takes over a router's IP via ARP hijack, but faithfully forwards all traffic, not knowing the router's true MAC is not a problem. Real issues we must concern ourselves with include: - traffic randomized across the address space in an attempt to starve us of resources. a meaningful attack must uniquely exploit our operation, or else the attacker is simply DoS'ing the network. - we defend against this with algorithms and bounded resource allocation - traffic designed to mislead our network analysis. this would include advertisement of false routes, hijacking of addresses without subsequent forwarding, simulation of dns service from whence it is not offered, etc. - we defend against this by supporting and testing contradictory information - traffic designed to be amplified by our automated actions. - we defend against this by ensuring only a finite number (preferably 1) of packets (including potential replies) are issued. this is most easily done by never automatically transmitting to non-unicast addresses, and never automatically triggering stateful reconnaissance. this is by no means a complete solution, but it seems the best we can do. It would be useful if logical interfaces could determine that they share a medium, but this seems impossible in the general case. Seeing the same hardware address on multiple interfaces could be the result of generated addresses, misconfigurations, adversaries, or use of well-known addresses (primarily multicast and broadcast). Seeing the other card's generated packets could be the result of misconfiguration, adversarial routing/bridging, adversarial packet generation (a node with connections to both distinct media could replicate packets from one to another), etc. Indexing ======== We need be able to index by logical interface, hardware address, and network address. Network addresses need be indexed by range, with the ranges organized by routes. Interfaces contain many hardware addresses; these hardware addresses may be shared between interfaces, and up to two entities ('ourselves' and 'others') may shared a hardware address on any given interface (this indicates a misconfiguration, our seizure of another address, or seizure by some other entity of our own. We cannot generally differentiate between two hosts sharing a MAC address). Hardware addresses may contain many local network addresses and many routes. Network addresses are associated with some number of hardware addresses, potentially on different interfaces. Routes are associated with a single network address and a single interface. Note that the network address is not necessary to actually route through the hardware address; routing only requires the router's network address if the corresponding hardware address is missing from the neighbor cache. An l2node is a hardware address. An l3host is an address which some local machine claims via ARP, an address in which we are interested, or the set of addresses seen from some local machine which it does *not* claim via ARP. Note that while routers are specified via network addresses (and discovered thusly using netlink), their *hardware* addresses are necessary and sufficient to use them. The union of all interfaces' l3hosts provide complete information regarding both routes and neighbors as known to omphalos. Packet Transmission =================== If targeting a layer 2 address (as in ARP), we can simply construct the packet and put it on the wire -- no indexing is necessary. Normally, we're targeting a layer 3 address. This requires a corresponding layer 2 hardware address. If the transmission is taken in immediate response to some received packet, we have all this info, and can proceed directly. Otherwise, we find the l3host via keying into the global l3host table on destination address. This provides us with a (possibly local) route. The route object knows its associated interface in O(1), and thus our proper source hardware address (also in O(1)). The route object also knows the next hop, if one exists; otherwise the destination is considered the next hop. Routes don't typically specify the destination hardware address, but we will usually know it. Since we need it to actually route, whether we know it or not, stash a reference in the route object as soon as it's learned (and actively try to learn it upon gatewayed route discovery). This provides us with all necessary destination information. Packet Receipt ============== What information can we glean from a packet on the wire? Ignore trust for the moment. Assume an IPv4 or IPv6 header. This header will have a source and destination address. We usually ought be able to route to these addresses on the receiving interface -- if we can't, it's probably due to one of: - any number of misconfigurations/failures in any number of places - spoofing of source address - one-way route - our lack of configuration (a special case of misconfiguration) None of these are particularly interesting, or even necessarily distinguishable, save the last; if we're lacking configuration, it ought usually be possible to infer it -- so far as is necessary to communicate with entities we've seen -- via active analysis. ARP can be used to determine whether a hardware address claims a given IP address; a router will not (Proxy ARP, as mentioned before, can complicate this). An ARP probe requires an IP address, which we might not have (or might not be in the same network as the address seen due to misconfiguration etc), but we can spoof someone else's and gather information that way (indeed, it might be possible to use the target's own IP address (which we must know) as our source, so long as we supply our hardware address as a source, and receive the reply). We run the risk in this case, however, of upsetting other nodes' own ARP caches, and thus ought be prepared to forward traffic in the case of an unintentional MitM. Since packet transmission must often be keyed off a layer 3 address, we'd like full knowledge of the route, interface, and hardware address relations directly accessible from the l3 objects. Since we're using packet reception to learn many of these details, that's a natural place to perform the binding. It further facilitates detection of addresses duplicated across interfaces and hardware addresses, should that ever prove useful. Finally, this allows automatic reconfiguration of the routing database based on what we really see in the network (and thus it can be abused by adversaries if we're not careful). So, on packet receipt: - Ensure a reference to the interface - Find the l2 address within the interface's neighbor LRU, or insert it - Find the l3 address within the global table - If it is found, compare the route info to this data, possibly updating it. - If it is not found, and it corresponds to a local route we know, add an l3host for the address, and store a reference in our neighbor table. - If it is not found, and it corresponds to a non-local route we know, exit. - If it is not found, and does not correspond to a route we know, hit the source MAC address with an ARP for the network address. A positive reply indicates a local address, Proxy ARP, or an adversary. A negative reply cannot indicate much, but suggests the possibility of a route at the source hardware address to at least the source network address.
One of her sisterhood lugged me squealing into life. Creation from nothing. What has she in the bag? A misbirth with a trailing navelcord, hushed in ruddy wool. The cords of all link back, strandentwining cable of all flesh. That is why mystic monks. Will you be as gods? Gaze in your omphalos. -- James Joyce, Ulysses