Web sites for customers of agricultural equipment maker John Deere contained vulnerabilities that could have allowed a remote attacker to harvest sensitive information on the company’s customers including their names, physical addresses and information on the Deere equipment they own and operate.

The researcher known as “Sick Codes” (@sickcodes) published two advisories on Thursday warning about the flaws in the myjohndeere.com web site and the John Deere Operations Center web site and mobile applications. In a conversation with Security Ledger, the researcher said that a he was able to use VINs (vehicle identification numbers) taken from a farm equipment auction site to identify the name and physical address of the owner. Furthermore, a flaw in the myjohndeere.com website could allow an unauthenticated user to carry out automated attacks against the site, possibly revealing all the user accounts for that site.

Sick Codes disclosed both flaws to John Deere and also to the U.S. Government’s Cybersecurity and Infrastructure Security Agency (CISA), which monitors food and agriculture as a critical infrastructure sector. As of publication, the flaws discovered in the Operations Center have been addressed while the status of the myjohndeere.com flaws is not known.

Contacted by The Security Ledger, John Deere did not offer comment regarding the bulletins prior to publication.

Sick Codes, the researcher, said he created a free developer account with Deere and found the first myjohndeere.com vulnerability before he had even logged into the company’s web site. The two flaws he disclosed represent only an hour or two of probing the company’s website and Operations Center. He feels confident there is more to be found, including vulnerabilities affecting the hardware and software deployed inside the cabs of Deere equipment.

“You can download and upload stuff to tractors in the field from the web. That is a potential attack vector if exploitable.”

Ag Equipment Data: Fodder for Nation States

The information obtained from the John Deere websites, including customer names and addresses, could put the company afoul of data security laws like California’s CCPA or the Personal Information Protection Act in Deere’s home state of Illinois. However, the national security consequences of the company’s leaky website could be far greater. Details on what model combines and other equipment is in use on what farm could be of very high value to an attacker, including nation-states interested in disrupting U.S. agricultural production at key junctures, such as during planting or harvest time.

The consolidated nature of U.S. farming means that an attacker with knowledge of specific, Internet connected machinery in use by a small number of large-scale farming operations in the midwestern United States could launch targeted attacks on that equipment that could disrupt the entire U.S. food supply chain.

Despite creating millions of lines of software to run its sophisticated agricultural machinery, Deere has not registered so much as a single vulnerability with the Government’s CVE database, which tracks software flaws.

At Risk: Devastating Attacks on Food Chain

Agriculture is uniquely susceptible to such disruptions, says Molly Jahn, a Program Manager in the Defense Sciences Office at DARPA, the Defense Advanced Research Projects Agency and a researcher at the University of Wisconsin, Madison.

Molly Jahn is Program Manager at DARPA and a researcher at the University of Wisconsin, Madison.

“Unlike many industries, there is extreme seasonality in the way John Deere’s implements are used,” Jahn told Security Ledger. “We can easily imagine timed interference with planting or harvest that could be devastating. And it wouldn’t have to persist for very long at the right time of year or during a natural disaster – a compound event.” An attack aimed at economic sabotage and carried out through combines at harvest time in the midwest it would be “devastating and unrecoverable depending on the details,” said Jahn.

DHS Warns That Drones Made in China Could Steal U.S. Data

However, the Agriculture sector and firms that supply it, like Deere, lag other industries in cyber security preparedness and resilience. A 2019 report released by Department of Homeland Security concluded that the “adoption of advanced precision agriculture technology and farm information management systems in the crop and livestock sectors is introducing new vulnerabilities into an industry which had previously been highly mechanical in nature.”

DHS Report: Threats to Ag Not Taken Seriously

“Most of the information management / cyber threats facing precision agriculture’s embedded and digital tools are consistent with threat vectors in all other connected industries. Malicious actors are also generally the same: data theft, stealing resources, reputation loss, destruction of equipment, or gaining an improper financial advantage over a competitor,” the report read.

The research group that prepared that report visited large farms and precision agriculture technology manufacturers “located throughout the United States.” The report concluded that “potential threats to precision agriculture were often not fully understood or were not being treated seriously enough by the front-line agriculture producers,” the report concluded.

Jahn said the U.S. agriculture sector has emphasized efficiency and cost savings over resilience. The emergence of precision agriculture in the last 15 years has driven huge increases in productivity, but also introduced new risks of disruptions that have not been accounted for.

“We have not thought about protecting the data from unwanted interference of any type,” she said. “That includes industrial espionage, sabotage or a full on attack…I have consistently maintained cyber risk on the short list of existential threats to US food and agriculture system.”

Security researchers analyzing a widely used open source component have discovered security vulnerabilities that leave hundreds of thousands of software applications vulnerable to attack, according to a report released Monday.

The group of five researchers found the security vulnerabilities in netmask, an open source library used in a staggering 270,000 software projects. According to the report, the flaws open the door to a wide range of malicious attacks that could enable attackers to ferry malicious code into a protected network, or siphon sensitive data out of one.

Exploitable Flaw in NPM Private IP App Lurks Everywhere, Anywhere

Among the attacks enabled by the flaw are so-called server-side request forgeries (SSRF), as well as remote file inclusion, local file inclusion and more, the researcher called Sick Codes told The Security Ledger. Work to discover the extent of the flaws continues. The researchers have received a preliminary vulnerability ID for the flaw, CVE-2021-28918.

Even worse, the flaws appear the stretch far beyond a single open source module, affecting a wide range of open source development languages, researchers say.

Work on one vulnerable open source module uncovers another

In addition to Sick Codes, the researchers conducting the investigation are Victor Viale (@koroeskohr), Kelly Kaoudis (@kaoudis), John Jackson (@johnjhacking) and Nick Sahler (@tensor_bodega).

According to Sick Codes, the vulnerability was discovered while doing work to fix another vulnerability in a widely used NPM library known as Private IP. That module, which was also widely used by open source developers, enables applications to block request forgery attacks by filtering out attempts to access private IP4 addresses and other restricted IP4 address ranges, as defined by ARIN. In a report published in November, researchers revealed that the Private IP module didn’t work very well and was susceptible to being bypassed using SSRF attacks against top tier applications.

Spotlight Podcast: Security Automation is (and isn’t) the Future of Infosec

SSRF attacks allow malicious actors to abuse functionality on a server: reading data from internal resources or modifying the code running on the server. Private-ip was created to help application developers spot and block such attacks. SSRF is one of the most common forms of attack on web applications according to OWASP.

The researchers working to fix the Private IP flaw turned to netmask, a widely used package that allows developers to evaluate whether a IP address attempting to access an application was inside or outside of a given IPv4 range. Based on an IP address submitted to netmask, the module will return true or false about whether or not the submitted IP address is in the defined “block.”

Opinion: Better Code Won’t Save Developers in the Short Run

The module has a range of other useful features, as well, such as reporting back on how many IPs are inside a given block. And, with no other “dependencies,” netmask seemed like the perfect fit to fix Private IP’s problems.

There’s only one problem: netmask itself was flawed, as the researchers soon discovered. Specifically: the module evaluates certain IP addresses incorrectly: improperly validating so-called “octal strings” rendering IPv4 addresses that contain certain octal strings as integers.

For example, the IP4 address 0177.0.0.1 should be evaluated by netmask as the private IP address 127.0.0.1, as the octal string “0177” translates to the integer “127.” However, netmask evaluates it as a public IPv4 address: 177.0.0.1, simply stripping off the leading zero and reading the remaining parts of the octal string as an integer.

Sample output from the netmask NPM module showing incorrect parsing of the IPv4 address. The flaw could enable a range of attacks on applications using the popular open source module.
Sample output from the netmask NPM module showing incorrect parsing of the IPv4 address. The flaw could enable a range of attacks on applications using the popular open source module. (Image courtesy of Sick Codes.)

And the flaw works both ways. The IP4 address 0127.0.0.01 should be evaluated as the public IP address 87.0.0.1 as the octal string “0127” is the same as the integer “87.” However, netmask reads the address as 127.0.0.1, a trusted, localhost address. Treating an untrusted public IP address as a trusted private IP address opens the door to local- and remote file inclusion (LFI/RFI) attacks, in which a remote authenticated or unauthenticated attacker can bypass packages that rely on netmask to filter IP address blocks.

A Popular Module with a Sterling Pedigree

Netmask is the creation of Olivier Poitrey, an accomplished developer who is the Director of Engineering at Netflix and a co-founder of the firm NextDNS. The module was first released nine years ago and gained prominence around 5 years ago, with version 1.06, which has been downloaded more than 3 million times.

The netmask module currently sees around 3.1 million downloads weekly, though development on netmask appears to have ceased during the last five years, up until the release of version 2.0.0 around 10 days ago, after discovery of the security holes.

Throwing open the doors to hackers

The implications for modules that are using the vulnerable version of netmask are serious. According to Sick Codes, remote attackers can use SSRF attacks to upload malicious files from the public Internet without setting off alarms, because applications relying on netmask would treat a properly configured external IP address as an internal address.

Similarly, attackers could also disguise remote IP addresses local addresses, enabling remote file inclusion (RFI) attacks that could permit web shells or malicious programs to be placed on target networks.

Parsing IPv4 Addresses: Black Magic

Updates to address the flaws in netmask began appearing on March 19 with the release of version 2.0.0. A subsequent update, 2.0.1, was released on Monday. To date, only 6,641 downloads of the updated netmask module have completed, meaning the vast majority of open source projects using it remain vulnerable. Contacted via chat, Poitrey advised netmask users to upgrade to the latest version of the module.

But researchers say much more is to come. The problems identified in netmask are not unique to that module. Researchers have noted previously that textual representation of IPv4 addresses weren’t ever standardized, leading to disparities in how different but equivalent versions of IPv4 addresses (for example: octal strings) are rendered and interpreted by different applications and platforms.

In the case of the netmask flaw, the true culprit ends up being “some unexpected behaviors of the parseInt function in Javascript combined with an oversight on those odd IP notations nobody (uses),” Poitrey told Security Ledger. “Parsing IPs correctly is black magic,” he said. “Those weird notations should just be deprecated, so nobody can exploit them like this.”

More to come

The impact of the flaw will become more clear in the weeks ahead, according to Sick Codes, as more examples of the IPv4 parsing problem are identified and patched in other popular open interpreted languages. “The implications are infinite,” he said.

In the past 20 years, bug hunting has transformed from a hobby (or maybe even a felony) to a full-time profession for tens of thousands of talented software engineers around the globe. Thanks to the growth in private and public bug bounty programs, men and women with the talent can earn a good living by sniffing out flaws in the code for applications and – increasingly -physical devices that power the 21st century global economy. 

Asus ShadowHammer suggests Supply Chain Hacks are the New Normal

Bug Hunting Smart TVs To Supply Chain

What does that work look like and what platforms and technologies are drawing the attention of cutting edge vulnerability researchers? To find out we sat down with the independent researcher known as Sick Codes (@sickcodes). In recent months, he has gotten attention for a string of important discoveries. Among other things, he discovered flaws in Android smart television sets manufactured by the Chinese firm TCL and was part of the team, along with last week’s guest John Jackson, that worked to fix a serious server side request forgery flaw in a popular open source security module, NPM Private IP

Spotlight Podcast: How Machine Learning is revolutionizing Application Fuzzing

In this interview, Sick Codes and I talk about his path to becoming a vulnerability researcher, the paid and unpaid research he conducts looking for software flaws in common software and internet of things devices, some of the challenges and impediments that still exist in reporting vulnerabilities to corporations and what’s in the pipeline for 2021. 


As always,  you can check our full conversation in our latest Security Ledger podcast at Blubrry. You can also listen to it on iTunes and check us out on SoundCloudStitcherRadio Public and more. Also: if you enjoy this podcast, consider signing up to receive it in your email. Just point your web browser to securityledger.com/subscribe to get notified whenever a new podcast is posted.