Omphalos

Three omphalos processes, 2011-12-01

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.9, released 2019-11-20.
• Arch's AUR contains omphalos

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.

Omphalos: Because one layer is never enough. Code is hosted on GitHub, as are modern issues. Old bugs are still available at bugzilla. There's a mailing list at Google Groups.

Similar Tools

• 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

Countertools

We want to defeat systems like:

• ArpON by Andrea Di Pasquale et al

Subsumed Tools

Omphalos implements all or portions of the functionality of the following tools:

• Avahi, the linux zeroconf daemon
• radvd, the linux IPv6 Router Advertisement daemon

Versions/Milestones/Releases

Version	Release date	Features
0.98 (initial alpha)	2011-10-07 (actual) 2011-09-23 (planned)	Detection of network entities at layers 2 and 3. Dynamic handling of devices, routes, neighbors and addresses Full netlink, ethtool, nl80211 and wireless extensions support TTY and ncurses-based UI's ARP- and DNS-based probing
0.99.0β (initial beta)	2011-12-01 (actual) 2011-11-11 (planned)	Routing/iptables configuration capabilities Hostapd and AP-spoofing support Spoofing support at layers 2 and 3 Zeroconf- and WINS-based probing
1.0	2011-12-25 (planned)	Automated selection and execution of previous capabilities GPS support Logging support LLTD and some NetBIOS support

General Features

Some planned, some implemented...

• Modes of operation governing automatic behavior, from "Silent" to "Hostile":

Mode	Summary	Operating characteristics
Silent	Take no actions, only watch.	TX ringbuffers/sockets are not automatically created No packets will be issued by omphalos unless requested No automatic modifications to host networking state
Stealthy	Take only the actions of a normally-configured host.	ARP queries will be automatically issued DNS and Zeroconf queries will be issued, but only as the host is configured No automatic modifications to host networking state
Active	Learn what we can, possibly standing out from the crowd.	Make free use of detected information for further recon No automatic modifications to host networking state
Aggressive	Learn things quickly, in ways that will be noticed.	"Active", plus... Periodic and triggered wide-spectrum active scanning Omphalos will freely manipulate host networking state
Forceful	Actively disrupt the network, rerouting traffic through us.	Continuous scanning of the network MitM automatically effected wherever possible DoS will be employed to make MitM more effective Omphalos will freely manipulate host networking state
Hostile	Attempt to make the network unusable.	Same as "Forceful", but don't pass traffic along once MitM'd. Actively employ null routing. DoS employed upon network infrastructure, carrier, and and egress.

• 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
  • Fine-grained MitM packet manipulation, filtering and generation via Parvenu and domain-specific languages
  • Fine-grained, one-click identity theft at any desired layer(s) (assumption of MAC, IP, cookies, etc)
    • Eat your heart out, Firesheep!
• 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

• Network analysis and debugging ought be spun out into Dr. Benway

Layer	Subdivisions	What's tracked	Notes
Layer 2	From both packets and netlink: VLANs ESSs	Nodes from packets: All source hardware addresses seen in packets All destination hardware multicast addresses Nodes from netlink: All hardware addresses in the kernel neighbor cache Our hardware addresses Hardware broadcast addresses	Node allocation is backed by a mainly-static VLHU At the point an attacker can overwhelm our VLHU, there's effectively nothing on the network but junk packets. If something's a source, it's being claimed as present here on the network. A destination means nothing, except in the case of multicast. Someone else sending with our MAC address ought be noted, unless we stole their MAC address We can't generally differentiate between two other physical hosts using the same MAC Multiple interfaces might actually be sharing a MAC intentionally for low-latency failover Upshot: we don't/can't care. We only care if someone else uses *our* MAC (unless told it's ok). We can't detect a spoofed MAC, but we can send our own ARP probes and at least determine whether the MAC's being serviced
Layer 3	From both packets and netlink: Networks	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 Hosts from netlink: All network addresses in the kernel neighbor cache Configured router addresses Our configured network addresses Configured broadcast addresses Hosts from packets: All source network addresses from the RFC1918 networks All source network addresses to which we have a configured route All source network addresses observed offering L2-restricted services All routers and nameservers named in a DHCP packet All destination network multicast addresses	Host allocation is backed by a dynamic VLHU. More dynamic and larger VLHU than that for layer 2, since we can have more hosts than nodes -- imagine a /0 route configuration sitting on an internet backbone. Small implementations of ARP tables and CAMs in nodes/switches means, say, 4k nodes ought almost always be sufficient for any interface. Multiple nodes can share a host address, but it can also indicate a problem Other nodes using *our* host addresses is a problem unless told otherwise Seeing an L3 address on a MAC means either: There's another network present locally (if we have no route to the L3, and the MAC responds to an ARP query for the L3), or That MAC is routing to that address (if the MAC is associated with a route to the L3), or That MAC serves that address (if we have a local route to the address) Perhaps only temporarily, and perhaps without service provision (eg DHCP requests), or There's any variety of misconfiguration/failure/adversary at work (le sigh) Upshot: we can discover the local network(s) without relying on any configuration, even those which don't advertise (ie with DHCP)
Layer 4		From packets: DNS and DHCP servers	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?
BSD Loopback	?	DLT_NULL	N/A	No
Linux Cooked Capture	packet(7)	DLT_LINUX_SLL	N/A	Yes
Ethernet Ethernet II/DIX Novell 802.3 IEEE 802.2 LLC SNAP 802.1Q VLAN/802.1p QoS (IEEE 802.3ac)	IEEE 802.3-2008	DLT_EN10MB	ARPHRD_ETHER	Yes
Token Ring	IEEE 802.5	DLT_IEEE802	ARPHRD_IEEE802_TR	No
ARCNET	ANSI 878.1	DLT_ARCNET DLT_ARCNET_LINUX	ARPHRD_ARCNET	No
SLIP (Serial Line Internet Protocol)	RFC 1055 (SLIP) RFC 1154 (CSLIP)	DLT_SLIP	ARPHRD_SLIP ARPHRD_SLIP6 ARPHRD_CSLIP ARPHRD_CSLIP6	No
PPP (Point-to-Point Protocol) BSD/OS PPP PPP over serial PPPoE (PPP over Ethernet) PPPoA (PPP over ATM) Cisco PPP/HDLC	RFC 1661 ? RFC 1662 RFC 2516 RFC 2364 RFC 1547	DLT_PPP DLT_PPP_BSDOS DLT_PPP_SERIAL DLT_PPP_ETHER ? DLT_C_HDLC	ARPHRD_PPP	Partial No No No No Yes
FDDI (Fiber Distributed Data Interface)	MAC: ANSI X3.139-1987 / ISO 9314-2 PHY: ANSI X3.148-1988 / ISO 9314-1	DLT_FDDI	ARPHRD_FDDI	No
Fibre Channel	RFC 2625	DLT_IP_OVER_FC	ARPHRD_FCPP ARPHRD_FCAL ARPHRD_FCPL ARPHRD_FCFABRIC	No
IrDA (Infrared Data Association)	IrDA PHY Spec v1.5 IrDA Link Access Protocol v1.1	DLT_LINUX_IRDA	ARPHRD_IRDA	Yes
Radiotap	De facto	DLT_IEEE802_11_RADIO	ARPHRD_IEEE80211_RADIOTAP	Yes
Firewire	IEEE 1394	N/A	ARPHRD_IEEE1394	Yes
Frame Relay	?	DLT_FRELAY	ARPHRD_FRAD	No
Apple LocalTalk	?	DLT_LTALK	ARPHRD_APPLETLK	No
LAPD (Link Access Protocol - D Channel)	ITU Q.921	DLT_LINUX_LAPD	ARPHRD_LAPB	No

Layer 2

Topology Discovery

For more information, see the Topology Discovery page.

Protocol	Standard	Support
LLTDP	Microsoft	Extraction of data from HELLO packets Enumeration via DISCOVERY requests
LLDP	IEEE 802.1AB-2005	None yet
CDP	Cisco	None yet
STP	IEEE 802.1D	Minimal analysis of BDPUs

802.3/Ethernet II

• 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

802.11

• 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)

Layer 3

• 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

Layer 4

• 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

Layer 5

• 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

Portability

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.

User Interfaces

• 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

Project documentation

Transcluded from top of my git repository at GitHub.

README

<include src="https://raw.github.com/dankamongmen/omphalos/master/README" />

Data Organization

<include src="https://raw.github.com/dankamongmen/omphalos/master/doc/dataorganization.txt" />

---

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

---

See Also

• Packet sockets