While experimenting with connecting control system's serial interfaces to wireless routers, I came across KEYNICE HLK-WR02 Wireless Serial-Interface Router. The interface/coding was atrocious, unsupported, and in Mandarin. It's documentation was also outdated as it pointed to the original manufacturer (Fulling Way Technologies); however, software and firmware links ceased to be available. In effort to retain some functionality, I decided to open the device in hopes of finding standardized hardware. Fortunately, I found a Hi-Link UART WiFi module sitting on top of a $4 HLK-RM04 test board (kit-V2.2). The latter having an available and somewhat, recent OpenWRT image.
Although flashing OpenWRT on a device is fairly trivial, I did see some inconsistencies with the site's instructions. As a result, the below steps will walk you through the process I followed for flashing the HLK-RM04 test board (kit-V2.2) with a minimal OpenWRT image.
1. Download the OpenWRT's RT305X-HLK-RM04 Generic Factory image: https://github.com/bogdanr/HLK-RM04/raw/master/images/rt305x-hlk-rm04-generic-factory.bin
2. Navigate to the HLK-RM04's Administration > Upload Firmware tab and 'Browse' to the above image. Press 'Upload'.
3. The file will upload and the device will reboot. Set a continuous ping to its default IPv4 address (192.168.16.254).
4. Once the above IP address is no longer reachable, set a continuous ping to OpenWRT's default IPv4 address (192.168.1.1). Note that this will require a reconfiguration of the workstation's IP address and default gateway.
5. Connect your workstation to the HLK-RM04 device using a RS-232 cable and a USB-to-Serial adapter (e.g., Keyspan Tripp-Lite). Unlike connecting to a Cisco networking device, you will need to change your serial settings to reflect the below:
- Speed (baud): 57600
- Data bits: 8
- Stop bits: 1
- Parity: None
- Flow Control: XON/XOFF
6. At the root prompt, change your default password: root@OpenWrt:/# passwd
7. Now you are able to SSH into the device over Ethernet using PuTTY. SSH to 192.168.1.1 and authenticate as the 'root' using the newly created password.
I will update this post after I have had sufficient time with testing this OpenWRT image in hopes of addressing resource limitations and package functionality on this platform. Note: The above test board's Hi-Link WiFi module also compatible with Arduino, so more fun can be had by all!
References
https://github.com/JiapengLi/OpenWrt-HiLink-HLK-RM04
https://wiki.openwrt.org/toh/hilink/hlk-rm04
http://www.hlktech.net/product_detail.php?ProId=39
http://www.hlktech.com/Article/Read/135.aspx
http://www.hlktech.com/upfile/2016/07/10/20160710161758_575.pdf
http://www.instructables.com/id/Arduino-WiFi-Temperature-Meter-with-web-page/?ALLSTEPS
Sunday, August 14, 2016
Thursday, June 2, 2016
Cyber Team Development 101: Train to Win as a Team
Proper conditioning is of importance prior to any competition. Athletes, whether in individual competition or team events, understand the importance of training prior to competition. Competitive marksmen and trained sharpshooters continually fire their weapon system in hopes of improving target acquisition skills, breathing, and trigger squeeze. Special operations provide demanding and realistic training to test readiness, build their personnel’s confidence and improve overall team camaraderie while continually refining battle skills. Even the least competitive of folks understand that ‘practice makes perfect’ whether its on the golf course or jamming out on Rock Guitar! Cyber security and incident response activities can be likened to the competition between malicious actors (whether internal or external) and the defending home team. Given the consequences of a breach, I must ask “Why do some security practices refrain from participating in realistic training?”
Unfortunately for those in the information security community, a lack of rigor is not uncommon within 'team' development vice 'individual' certification. An outlined training program is often absent from thought unless its an annual HR-specific topic or individualized on an employee’s performance review. This is common within enterprises of all sizes as dedicated training resources can be austere unless purchased from and provided by a third-party. Two well publicized events that come to mind are the SANS Institute's NetWars and CyberCity interactive scenarios. Sadly, conference held events can become costly at scale due to ancillary travel expenses and entrance fees; whereas, an on-premise offering may be too expensive if the team has a small headcount. Plus, there is an impact (sometimes more so fear-driven than practical) of taking your personnel ‘out of action’ for an extended period of time. A less expensive option is to perform the ‘live’ training in-house. For brevity's sake, I have broken down the options into two simplistic options:
- Dedicated: A one-day plus training scenario that not only fits your practice's maturity model, but is team-oriented while allowing for individual achievement. I recommend adding the ‘plus’ to the dedicated training ’s duration in order to accommodate a more thorough lessons-learned debrief session following a period of reflection after tempers dissipate or following a good night’s rest. This type of activity is best suited when the moderator and his/her support team leads the scenario, yet retains the means and authority to allow for unscripted modifications in response to participants’ actions.
- Ad hoc: Reacting to an otherwise non-impact or routine event (i.e., a commodity malware infection or an intrusion detection alert) as you would to a significant breach. The goal is to gauge efficacy in the organization’s ticketing processes, notification plans, interdepartmental communication, policies and procedures. Success is defined by cross-organization participation, ticketing process times, and mean-time from detection to remediation including more labor intensive tasks (e.g., memory forensics, disk imaging, etc.).
The latter, impromptu method requires less overhead and is useful for either establishing a baseline of performance or identify procedural hurdles. A side benefit to ad hoc testing is this model can easily be reiterated whether quarterly or bi-annually. A dedicated scenario often requires additional support for role playing, scenario inject development, and mediation. This task could be managed by an outside consultant or as a result of an internal red and blue team mind-meld, which is often referred to as a "purple team" test. The only gotcha for either approach is that these activities are best executed when other, non-IT personnel are involved. For example, what are HR's, marketing and the legal department's roles during breach recovery? Monitoring social media for unexpected disclosures? What are the notification plans for law enforcement or cyber insurance? Press announcements? How do we get enough information to the CEO to brief share holders, etc.? These types of activities need to be outlined, assigned, and rehearsed before an incident occurs and subsequently, tested to identify modifications to your overall breach response plan. In conclusion, internal testing can serve as a low-cost alternative or a conditioning program to get your team ready for the main event!
Wednesday, March 23, 2016
Xenserver Setup
Perform below steps on system dedicated for virtualization:
1. Download Xenserver v6.5.0 ISO and burn to a CD or USB.
2. Access BIOS settings and ensure "Intel Virtualization Technology" is used.
3. Within BIOS settings, change storage boot-up to "Legacy Only". This step was needed to boot from my M.2 drive.
3. Boot to disk/USB and press the 'Enter' key to install.
4. Select keymap "[qwery] us" and press "Ok"
5. Select "Ok" and "Accept EULA"
6. Select drive for XenServer OS (e.g., M.2)
7. Select drives for virtual machine storage and enable thin provisioning. Press "Ok".
8. Select "local media" as installation source and press "Ok".
9. Select "No" to forego supplemental packs installation (optional)
10. Press "Ok" to verify installation source (optional). If verification is successful, a "no problems were found" message appears. Press "Ok" to continue with installation.
11. Enter and verify password.
12. Specify network addressing and press "Ok"
13. Provide hostname and DNS servers, then press "Ok".
14. Select "US" as geographical area and press "Ok".
15. Select timezone.
16. Select "Using NTP" and enter NTP servers followed by clicking "Ok".
17. Select "Install XenServer" to start installation.
18. Press "Skip" you are finished installing supplemental packs. If you are using a DVD-ROM for installation, the disk will eject.
19. Press "Ok" to reboot.
20. If BIOS settings are correct, the "Citrix XenServer" splash screen with progress bar appears followed by the Configuration screen.
Perform these steps on a Linux system in order to manage Xenserver:
1. Install Python-based "OpenXenManager": $ sudo apt-get -y install openxenmanager
2. Launch from CLI: $ openxenmanager &
1. Download Xenserver v6.5.0 ISO and burn to a CD or USB.
2. Access BIOS settings and ensure "Intel Virtualization Technology" is used.
3. Within BIOS settings, change storage boot-up to "Legacy Only". This step was needed to boot from my M.2 drive.
3. Boot to disk/USB and press the 'Enter' key to install.
4. Select keymap "[qwery] us" and press "Ok"
5. Select "Ok" and "Accept EULA"
6. Select drive for XenServer OS (e.g., M.2)
7. Select drives for virtual machine storage and enable thin provisioning. Press "Ok".
8. Select "local media" as installation source and press "Ok".
9. Select "No" to forego supplemental packs installation (optional)
10. Press "Ok" to verify installation source (optional). If verification is successful, a "no problems were found" message appears. Press "Ok" to continue with installation.
11. Enter and verify password.
12. Specify network addressing and press "Ok"
13. Provide hostname and DNS servers, then press "Ok".
14. Select "US" as geographical area and press "Ok".
15. Select timezone.
16. Select "Using NTP" and enter NTP servers followed by clicking "Ok".
17. Select "Install XenServer" to start installation.
18. Press "Skip" you are finished installing supplemental packs. If you are using a DVD-ROM for installation, the disk will eject.
19. Press "Ok" to reboot.
20. If BIOS settings are correct, the "Citrix XenServer" splash screen with progress bar appears followed by the Configuration screen.
Perform these steps on a Linux system in order to manage Xenserver:
1. Install Python-based "OpenXenManager": $ sudo apt-get -y install openxenmanager
2. Launch from CLI: $ openxenmanager &
Sunday, March 20, 2016
Docker Setup Guide
This post examines how to quickly setup Docker and incorporate its images from the Docker Hub. Prior to installing, its in your best interest to harden the hosting platform. The Center for Internet Security has a Docker Benchmark guide that is quite useful.
1. Install Docker.
$ apt-get update
$ sudo apt-get install apt-transport-https ca-certificates
$ sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
$ vim /etc/apt/sources.list.d
----paste-----
deb https://apt.dockerproject.org/repo ubuntu-trusty main
----
$ apt-get update
$ apt-get purge lxc-docker
$ apt-cache policy docker-engine
$ sudo apt-get install linux-image-extra-$(uname -r)
$ sudo apt-get install apparmor
$ sudo apt-get install docker-engine
$ sudo service docker start
$ docker ps
2. Verify successful installation: $ sudo docker run hello-world+
3. Allow Specified username to utilize Docker: $ sudo usermod -aG docker <username>
4. Configure Docker Images DNS Settings.
$ sudo vim /etc/default/docker
----paste-----
DOCKER_OPTS="--dns 208.67.220.220 --dns 208.67.222.222"
-----
$ sudo restart docker
5. Upgrade Docker (periodically): $ sudo apt-get upgrade docker-engine
6. Deploy Docker images.
a. Create an Docker Hub account at https://hub.docker.com
b. Once account verification completes, login and select "Explore Respositories" under the "Respositories" tab.
c. Locate a desired docker image and note its "Pull Command", e.g. "docker pull busybox". I also recommend annotating the command used to access its shell, "docker run -it --rm busybox"
d. Deploy Docker image and verify installation: $ sudo docker images
$ docker pull ubuntu
$ docker images
$ docker run -it --rm ubuntu
e. Note: Do NOT forget to change the 'root' account's password and update the Docker host! I also recommend reviewing the output of "# cat /etc/shadow" to ensure there aren't any rogue accounts.
7. Docker addressing.
a. Docker creates its own interface "docker0": $ ifconfig |grep docker
b. You can query the docker image's IP address by name: $ docker inspect <docker_name> |grep IPAddress
c. Docker has its own 172.17.0.0 route: $ netstat -rn
d. Add a route to the Docker IP on any remote host that needs connectivity with the Docker image: $ sudo route add -net 172.17.0.0 netmask 255.255.255.0 <docker_host_IP>
e. Verify a path from the remote host to the Docker image: $ traceroute 172.17.0.2
8. Other images of interest...
a. CentOS
$ docker pull centos
# passwd root
# yum -y update && yum -y upgrade
# exit
b. Python: $ docker pull python
c. BusyBox: $ docker pull busybox
d. SecurityOnion: $ docker pull danielguerra/security-onion
e. Kali Linux:
$ docker pull kalilinux/kali-linux-docker
$ docker run -it --rm kalilinux/kali-linux-docker
# passwd root
# apt-get -y update && apt-get -y install kali-linux-all
f. Snort:
$ docker pull opennsm/snort
$ ./containnsm run -I snort:2.9.8.0 -- snort --version
g. Docker Bench for Security
$ docker pull docker/docker-bench-security
$ docker run -it --net host --pid host --cap-add audit_control -v /var/lib:/var/lib -v /var/run/docker.sock:/var/run/docker.sock -v /usr/lib/systemd:/usr/lib/systemd -v /etc:/etc --label docker_bench_security --rm docker/docker-bench-security
h. PEScanner
$ docker pull remnux/pescanner
$ sudo docker run --rm -it -v ~/workdir:/home/nonroot/workdir remnux/pescanner bash
i. Squid Web Proxy
$ docker pull sameersbn/squid:3.3.8-10
$ docker run -it --rm sameersbn/squid:3.3.8-10
# vim /etc/squid3/squid.conf
j. Also, check out https://hub.docker.com/u/honeynet/
1. Install Docker.
$ apt-get update
$ sudo apt-get install apt-transport-https ca-certificates
$ sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
$ vim /etc/apt/sources.list.d
----paste-----
deb https://apt.dockerproject.org/repo ubuntu-trusty main
----
$ apt-get update
$ apt-get purge lxc-docker
$ apt-cache policy docker-engine
$ sudo apt-get install linux-image-extra-$(uname -r)
$ sudo apt-get install apparmor
$ sudo apt-get install docker-engine
$ sudo service docker start
$ docker ps
2. Verify successful installation: $ sudo docker run hello-world+
3. Allow Specified username to utilize Docker: $ sudo usermod -aG docker <username>
4. Configure Docker Images DNS Settings.
$ sudo vim /etc/default/docker
----paste-----
DOCKER_OPTS="--dns 208.67.220.220 --dns 208.67.222.222"
-----
$ sudo restart docker
5. Upgrade Docker (periodically): $ sudo apt-get upgrade docker-engine
6. Deploy Docker images.
a. Create an Docker Hub account at https://hub.docker.com
b. Once account verification completes, login and select "Explore Respositories" under the "Respositories" tab.
c. Locate a desired docker image and note its "Pull Command", e.g. "docker pull busybox". I also recommend annotating the command used to access its shell, "docker run -it --rm busybox"
d. Deploy Docker image and verify installation: $ sudo docker images
$ docker pull ubuntu
$ docker images
$ docker run -it --rm ubuntu
e. Note: Do NOT forget to change the 'root' account's password and update the Docker host! I also recommend reviewing the output of "# cat /etc/shadow" to ensure there aren't any rogue accounts.
7. Docker addressing.
a. Docker creates its own interface "docker0": $ ifconfig |grep docker
b. You can query the docker image's IP address by name: $ docker inspect <docker_name> |grep IPAddress
c. Docker has its own 172.17.0.0 route: $ netstat -rn
d. Add a route to the Docker IP on any remote host that needs connectivity with the Docker image: $ sudo route add -net 172.17.0.0 netmask 255.255.255.0 <docker_host_IP>
e. Verify a path from the remote host to the Docker image: $ traceroute 172.17.0.2
8. Other images of interest...
a. CentOS
$ docker pull centos
# passwd root
# yum -y update && yum -y upgrade
# exit
b. Python: $ docker pull python
c. BusyBox: $ docker pull busybox
d. SecurityOnion: $ docker pull danielguerra/security-onion
e. Kali Linux:
$ docker pull kalilinux/kali-linux-docker
$ docker run -it --rm kalilinux/kali-linux-docker
# passwd root
# apt-get -y update && apt-get -y install kali-linux-all
f. Snort:
$ docker pull opennsm/snort
$ ./containnsm run -I snort:2.9.8.0 -- snort --version
g. Docker Bench for Security
$ docker pull docker/docker-bench-security
$ docker run -it --net host --pid host --cap-add audit_control -v /var/lib:/var/lib -v /var/run/docker.sock:/var/run/docker.sock -v /usr/lib/systemd:/usr/lib/systemd -v /etc:/etc --label docker_bench_security --rm docker/docker-bench-security
h. PEScanner
$ docker pull remnux/pescanner
$ sudo docker run --rm -it -v ~/workdir:/home/nonroot/workdir remnux/pescanner bash
i. Squid Web Proxy
$ docker pull sameersbn/squid:3.3.8-10
$ docker run -it --rm sameersbn/squid:3.3.8-10
# vim /etc/squid3/squid.conf
j. Also, check out https://hub.docker.com/u/honeynet/
Wednesday, March 16, 2016
Integrating Gmail with Thunderbird, & GnuPG
Here's a quick how-to on integrating GnuPG with Thunderbird and Gmail. Enjoy.
1. Install packages: $ sudo apt-get -y install thunderbird gnupg enigmail
2. Configure Thunderbird
a. Press "Skip this and use existing account."
b. Enter the below information
User Name: username@gmail.com
Email Address: username@gmail.com
Password: <password>
Incoming Mail Server: IMAP imap.gmail.com 993
Outgoing Mail (SMTP) Server: SMTP smtp.gmail.com 465
c. Navigate to ' https://www.google.com/settings/security/lesssecureapps ' and 'Turn on' access for less secure apps. Not too fond of this setting.
3. Verify existence of Enigmail and Restart Thunderbird.
a. Verify existence of Enigmail: Tools > Add-ons > Extensions > Enigmail
b. Close and relaunch Thunderbird.
4. Configure Enigmail:
a. Launch Wizard: Enigmail > Setup Wizard
b. Press "Next" to setup a standard configuration
c. Enter a passphrase and confirm it. Press "Next".
d. Actively use your system in order to generate enough etropy for faster key generation.
e. Select "Create Revocation Certificate" and burn to a disk. Re-enter your passphrase. Save to desired file location and press "OK"
f. Press "OK" and "Finish" to complete configuration.
5. Upload Public Key: Enigmail > Key Management > select key > Keyserver > Upload Public Keyserver > select "pgp.mit.edu"
6. Export public key and secret key to file.
a. File > Export Kyes to File > Export Public Keys Only > select file path > Save
b. File > Export Kyes to File > Export Secret Keys > select file path > Save
c. Burn to CD with the revocation certificate.
7. Sign an email: Write > Attach My Public Key > click "This message will be unsigned and encrypted" > check "Sign Message" > OK
8. Navigate to Thunderbird's "Preferences" > "Account Settings" > "OpenPGP Security" > check "Sign messages by default" and press "Ok".
1. Install packages: $ sudo apt-get -y install thunderbird gnupg enigmail
2. Configure Thunderbird
a. Press "Skip this and use existing account."
b. Enter the below information
User Name: username@gmail.com
Email Address: username@gmail.com
Password: <password>
Incoming Mail Server: IMAP imap.gmail.com 993
Outgoing Mail (SMTP) Server: SMTP smtp.gmail.com 465
c. Navigate to ' https://www.google.com/settings/security/lesssecureapps ' and 'Turn on' access for less secure apps. Not too fond of this setting.
3. Verify existence of Enigmail and Restart Thunderbird.
a. Verify existence of Enigmail: Tools > Add-ons > Extensions > Enigmail
b. Close and relaunch Thunderbird.
4. Configure Enigmail:
a. Launch Wizard: Enigmail > Setup Wizard
b. Press "Next" to setup a standard configuration
c. Enter a passphrase and confirm it. Press "Next".
d. Actively use your system in order to generate enough etropy for faster key generation.
e. Select "Create Revocation Certificate" and burn to a disk. Re-enter your passphrase. Save to desired file location and press "OK"
f. Press "OK" and "Finish" to complete configuration.
5. Upload Public Key: Enigmail > Key Management > select key > Keyserver > Upload Public Keyserver > select "pgp.mit.edu"
6. Export public key and secret key to file.
a. File > Export Kyes to File > Export Public Keys Only > select file path > Save
b. File > Export Kyes to File > Export Secret Keys > select file path > Save
c. Burn to CD with the revocation certificate.
7. Sign an email: Write > Attach My Public Key > click "This message will be unsigned and encrypted" > check "Sign Message" > OK
8. Navigate to Thunderbird's "Preferences" > "Account Settings" > "OpenPGP Security" > check "Sign messages by default" and press "Ok".
Thursday, January 7, 2016
ICS Essentials: Dissecting PTP Packet Captures
In this follow-up to the previous Precise Timing Protocol (PTP) blog post, we flipped our evil bits and analyzed a PTP capture file; thus, enumerating an unknown target's PTP implementation. The target PCAP file is available on Wireshark's Wiki: https://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=ptpv2.pcap
Capture & Display Filters. PTP typically traverses across the network over UDP [RFC768], IPv4 [RFC791, IPv6 [RFC2460] or Ethernet as "ptp-event" or "ptp-general" messages. Wireshark supports the generic "ptp" display filter, but more granular packet-field filters are available on the site's "Display Filter Reference: Precision Time Protocol (IEEE1588) display filter" page. Alternatively, you can specify a port/protocol specific capture filter to limit packet ingest: "udp port 319 or udp port 320 or tcp port 319 or tcp port 320". For PTP over Ethernet packets, specify: "ether proto 0x88F7". As mentioned earlier, we analyzed the Wireshark provided "ptpv2.pcap" file. Based on the capture file's contents, we can assume the aforementioned capture filter was utilized as the viewed packets are either Ethernet encapsulated, sourced from, or directed to an IANA registered PTP port.
Time Source Identification. A reverse OUI lookup disclosed the time source's vendor (i.e., Hirschmann): Ethernet II, Src: Hirschma_00:09:ba (00:80:63:00:09:ba). This layer two address is correlated with subsequent messages that list the same MAC address as the network's Grand Master Clock:
The layer 3 header also reveals that neither Quality of Service (QoS) nor Differentiated Services Codepoint (DSCP) values are applied to the IPv4 encapsulated traffic: Differentiated Services Fiel: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not ECN-Capable Transport)) -- ip.dsfield . The DSCP value, which ranges from 0 to 64 as per RFC 2474, may be indicative to the time source device's manufacturer. For instance, Juniper's PTP value is set at "ipv4-dscp 56"; whereas, the Cisco ASR 9000 has a default value of 46. A review of the Hirschmann RPS datasheet stated that the vendor does in fact, support TOS/DSCP prioritization. Perhaps the administrator failed to correctly configure the device? Is this indicative of the target network's design?
Leveraging Wireshark's Statistics > Endpoints functionality easily identifies which addresses are communicating by what protocol. A review of the IPv4 addresses tab clued us into that only the Hirschmann was the sole time-source (192.168.2.6) transmitting UDP packets to 2240.0.107 (Mcast_PTP_v2) and 224.0.1.129 (Mcast_PTP_v2_messages) multicast addresses. The inspection of each packet's PTP flag bits revealed no unicast messages: ".... .0.. .... .... = PTP_UNICAST: False" -- ptp.v2.flags.unicast. All of the Delay Request messages were transmitted as multicast. We observed the same behavior earlier in the capture within the layer two traffic as the destination MAC addresses are all multicast (e.g., start with a "01:" octet). Given there isn't any master-initiated unicast communication, PTP delay responses or follow-up messages nor slave initiated sync/delay request messages , we assume that either the Hirschmann switch is the sole PTP device or an additional capture/display filter was implemented; thus, preventing us from observing additional endpoints. The fact that there isn't any unicast traffic is also peculiar given certain vendors' integration of the PTP standard. For example, Cisco's ASR 1000 supports IPv4 unicast not multicast and only supports unicast negotiation mode in PTPv2 boundary clocks.
Each packet also had a "subdomainNumber: 0" value -- ptp.mm.default.data.set.subdomainname. NIST defines a "PTP subdomain" as "a logical grouping of 1588 clocks that synchronize to each other using the PTP protocol, but that are not necessarily synchronized to PTP clocks in another PTP subdomain. Subdomains provide a way of implementing disjointed sets of clocks, sharing a common network, but maintaining independent synchronization within each set." Furthermore, Boundary Clocks (BCs) "define the segments within a subdomain." This packet capture either was limited previously identified Hirschmann switch or we may be observing a smaller ICS cell (logical) zone. Subsequent captures would provide clarification on its topology and connected devices.
Time Conversion. The Sync message included a time-stamp in Epoch seconds: originTimestamp (seconds): 1169232201 -- ptp.v2.pdrq.origintimestamp. Converting these seconds to a human-readable calendar date revealed the time of capture: Fri, 19 Jan 2007 18:43:25 GMT. Naturally, this is dependent on a properly configured time source. Since the master clock included the time within the Sync packet, we know that the clock is configured in "One-Step" mode. If the time would have been absent in the Sync packet and later found in the Follow-up message, we could've assumed that the master clock was configured for two-step mode. The latter found most typically in Rockwell devices.
We have discussed a few ways traffic analysis can be quite revealing both from defense, as well as offense perspectives. The above is just a small sampling of what is possible; thus, I encourage all administrators to capture and review their networks for any information disclosure, misconfiguration or potentially malicious traffic.
https://wiki.wireshark.org/Protocols/ptp
https://www.wireshark.org/docs/dfref/p/ptp.html
https://tools.ietf.org/html/rfc2474#section-4.1
http://www.epochconverter.com/
http://www.nist.gov/el/isd/ieee/terms1588.cfm
http://www.chronos.co.uk/files/pdfs/itsf/2013/Day1/14.05_david_chen_nokia_solutions.pdf
http://www.ieee802.org/1/files/public/docs2015/as-cummings-ieee-1588-security-requirements-0115-v41.pdf
https://tools.ietf.org/html/draft-ietf-tictoc-ptp-enterprise-profile-05
https://tools.ietf.org/html/rfc7384
Capture & Display Filters. PTP typically traverses across the network over UDP [RFC768], IPv4 [RFC791, IPv6 [RFC2460] or Ethernet as "ptp-event" or "ptp-general" messages. Wireshark supports the generic "ptp" display filter, but more granular packet-field filters are available on the site's "Display Filter Reference: Precision Time Protocol (IEEE1588) display filter" page. Alternatively, you can specify a port/protocol specific capture filter to limit packet ingest: "udp port 319 or udp port 320 or tcp port 319 or tcp port 320". For PTP over Ethernet packets, specify: "ether proto 0x88F7". As mentioned earlier, we analyzed the Wireshark provided "ptpv2.pcap" file. Based on the capture file's contents, we can assume the aforementioned capture filter was utilized as the viewed packets are either Ethernet encapsulated, sourced from, or directed to an IANA registered PTP port.
Time Source Identification. A reverse OUI lookup disclosed the time source's vendor (i.e., Hirschmann): Ethernet II, Src: Hirschma_00:09:ba (00:80:63:00:09:ba). This layer two address is correlated with subsequent messages that list the same MAC address as the network's Grand Master Clock:
- ClockIdentity: 0x008063ffff0009ba -- ptp.v2.mm.clockidentity. The IETF demands that the clock servers "always be identified by their clock ID and not the IP or Layer 2 address." In IPv4 networks, the utilization of a Layer 3 address may indicate a lack of NAT or simply an ineffective PTP architecture.
- grandmasterClockIdentity: 0x008063ffff0009ba -- ptp.v2.mm.grandmasterclockidentity. This subnet had a single master clock, known as the grandmaster clock or best master clock, which forwarded time to subordinate devices. The identities include a "ffff" padding implanted between its MAC address, which is similar to Rockwell Automation's inclusion of "fffe" padding as a CIP Sync identifier value. Perhaps, this is a format CIP Synch format specific to Hirschmann?
- Note: Wireshark protocol field-specific display filters follow the double hypens throughout this blog entry.
- 0x10: atomicClock
- 0x20: gps
- 0x22: terrestrialRadio
- 0x40: ptp
- 0x50: ntp
- 0x60: handSet
- 0x90: other
- 0xA0: internalOscillator
Leveraging Wireshark's Statistics > Endpoints functionality easily identifies which addresses are communicating by what protocol. A review of the IPv4 addresses tab clued us into that only the Hirschmann was the sole time-source (192.168.2.6) transmitting UDP packets to 2240.0.107 (Mcast_PTP_v2) and 224.0.1.129 (Mcast_PTP_v2_messages) multicast addresses. The inspection of each packet's PTP flag bits revealed no unicast messages: ".... .0.. .... .... = PTP_UNICAST: False" -- ptp.v2.flags.unicast. All of the Delay Request messages were transmitted as multicast. We observed the same behavior earlier in the capture within the layer two traffic as the destination MAC addresses are all multicast (e.g., start with a "01:" octet). Given there isn't any master-initiated unicast communication, PTP delay responses or follow-up messages nor slave initiated sync/delay request messages , we assume that either the Hirschmann switch is the sole PTP device or an additional capture/display filter was implemented; thus, preventing us from observing additional endpoints. The fact that there isn't any unicast traffic is also peculiar given certain vendors' integration of the PTP standard. For example, Cisco's ASR 1000 supports IPv4 unicast not multicast and only supports unicast negotiation mode in PTPv2 boundary clocks.
Each packet also had a "subdomainNumber: 0" value -- ptp.mm.default.data.set.subdomainname. NIST defines a "PTP subdomain" as "a logical grouping of 1588 clocks that synchronize to each other using the PTP protocol, but that are not necessarily synchronized to PTP clocks in another PTP subdomain. Subdomains provide a way of implementing disjointed sets of clocks, sharing a common network, but maintaining independent synchronization within each set." Furthermore, Boundary Clocks (BCs) "define the segments within a subdomain." This packet capture either was limited previously identified Hirschmann switch or we may be observing a smaller ICS cell (logical) zone. Subsequent captures would provide clarification on its topology and connected devices.
Time Conversion. The Sync message included a time-stamp in Epoch seconds: originTimestamp (seconds): 1169232201 -- ptp.v2.pdrq.origintimestamp. Converting these seconds to a human-readable calendar date revealed the time of capture: Fri, 19 Jan 2007 18:43:25 GMT. Naturally, this is dependent on a properly configured time source. Since the master clock included the time within the Sync packet, we know that the clock is configured in "One-Step" mode. If the time would have been absent in the Sync packet and later found in the Follow-up message, we could've assumed that the master clock was configured for two-step mode. The latter found most typically in Rockwell devices.
We have discussed a few ways traffic analysis can be quite revealing both from defense, as well as offense perspectives. The above is just a small sampling of what is possible; thus, I encourage all administrators to capture and review their networks for any information disclosure, misconfiguration or potentially malicious traffic.
References:
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xmlhttps://wiki.wireshark.org/Protocols/ptp
https://www.wireshark.org/docs/dfref/p/ptp.html
https://tools.ietf.org/html/rfc2474#section-4.1
http://www.epochconverter.com/
http://www.nist.gov/el/isd/ieee/terms1588.cfm
http://www.chronos.co.uk/files/pdfs/itsf/2013/Day1/14.05_david_chen_nokia_solutions.pdf
http://www.ieee802.org/1/files/public/docs2015/as-cummings-ieee-1588-security-requirements-0115-v41.pdf
https://tools.ietf.org/html/draft-ietf-tictoc-ptp-enterprise-profile-05
https://tools.ietf.org/html/rfc7384
http://www.cisco.com/c/en/us/td/docs/routers/asr1000/configuration/guide/chassis/asrswcfg/1588v2ptp.html.
https://www.belden.com/docs/upload/PB342_RSP_Switches.pdf
https://www.maku-info.eu/index.php/en/produkte-e/physical-security-e/diva-connect-vms-e.html
https://www.belden.com/docs/upload/PB342_RSP_Switches.pdf
https://www.maku-info.eu/index.php/en/produkte-e/physical-security-e/diva-connect-vms-e.html
Thursday, December 31, 2015
Happy New Year: Analog Sensor & IOT Relay Code
Happy New Year! To start the year out right, I am sharing my Arduino code for enabling/disabling power using a Digital Loggers' AC/DC Control Relay and a Funduino Keyes photosensitive analog sensor. Tweak the if/else numbers to suit your environment or swap out the module for another sensor. Next year, you won't even have to switch on your Christmas tree!
Subscribe to:
Posts (Atom)