Yesterday, Chris Sullo of Nikto fame, asked me a simple question; in so many words, what was the “first web vuln”. To be clear, he is asking about the first vulnerability in a web server / service / program. Seems relatively straight-forward but I challenge anyone to answer it with their own data set, especially CVE. One reason I have it a bit easier is that at the time, OSVDB (now VulnDB) actually had a metadata point called the “web related” classification. So a quick search showed 13 vulnerabilities in 1994, a great start! Or so I thought.
Of them, 11 were dated 1994-01-01 which we did when the exact date wasn’t known, but the year was. Or so I hope we did that consistently! Only three stood out with any specificity, the rest were more generic entries that were created specifically to support the Nikto scanner.
VulnDB Date Title
3103 1994-10-18 Retrospect Remote Control Panel De-initilization Remote DoS
29256 1994-04-05 CERN httpd Error Message Remote File Enumeration Weakness
91 1994-01-01 Multiple Web Server Version Remote Disclosure Weakness
228 1994-01-01 Multiple Vendor /cgi-bin/upload.cgi File Upload Remote Code Execution
238 1994-01-01 Multiple Web Server robots.txt Remote Information Disclosure
397 1994-01-01 Multiple Web Server Dangerous HTTP Method PUT
3092 1994-01-01 Multiple Web Server Interesting Web Document Found
3093 1994-01-01 Multiple Web Server Dangerous Web Document Found
3233 1994-01-01 Multiple Web Server Default Page Fingerprinting Weakness
3268 1994-01-01 Multiple Web Server Open Directory Indexing Remote Information Disclosure
5646 1994-01-01 Multiple Web Server Dangerous HTTP Method DELETE
5647 1994-01-01 Multiple Web Server Dangerous HTTP Method MOVE
93981 1994-01-01 Multiple Web Server HTTP Header String Remote Information DisclosureAmusingly, CVE-1999-0569 is attached to 3268 above, which NVD still scores as CVSSv2 10.0. This is definitively wrong as CVSSv2 did not consider the follow-up impact when scoring, where CVSSv3 did. So this should be CVSSv2 5.0 and arguably CVSSv3 9.8 if the disclosure resulted in e.g. root/admin credentials being disclosed. I digress, back to the digging!
We can see from the list, only three have real details for a specific, singular vulnerability:
VulnDB Date Title
3103 1994-10-18 Retrospect Remote Control Panel De-initilization Remote DoS
29256 1994-04-05 CERN httpd Error Message Remote File Enumeration Weakness
228 1994-01-01 Multiple Vendor /cgi-bin/upload.cgi File Upload Remote Code ExecutionVulnDB 228 seems suspicious for sure. This is where the “vulnerability disclosure forensics” begins. I am sharing my two primary replies to Sullo below, mostly as is, with touch-ups for broader consumption, formatting, and links.
My First / Quick Reply
VulnDB 228 is Nikto 001404 and 001405, Nessus 10290 (now 404), and Snort 1481 with -no- other reference unfortunately. The Snort reference is live, but no real help. Searching Nikto repo on GitHub:
"001404","OSVDB-228","0","@CGIDIRSupload.cgi","GET","200","","","","","The upload.cgi allows attackers to upload arbitrary files to the server.","",""
"001405","OSVDB-228","0","/upload.cgi+","GET","200","","","","","The upload.cgi allows attackers to upload arbitrary files to the server.","",""
So no real joy there as far as what products are impacted either. That means hunting for the deprecated Nessus plugin which I finally found (and it was more painful than it should have been):
name["english"] = "Upload cgi";
name["francais"] = "cgi upload";
script_name(english:name["english"], francais:name["francais"]);
desc["english"] = "The 'upload.cgi' cgi is installed. This CGI has
a well known security flaw that lets anyone upload arbitrary
files on the remote web server.
summary["english"] = "Checks for the presence of /cgi-bin/upload.cgi"; No joy there either, but we get verification of the path. Moving on up the list you will see quite a bit before /cgi-bin/phf (which Sullo suggested might be the first). Initial Conclusion: Definitely not the first, but likely one of the first high-profile as upload.cgi would have been as well. All that said, it does make me ask the question, how many of these do we know, for fact, were exploited back in our day? ‘phf’ for sure… what else? I’m interested in figuring out the early KEV.
Sullo’s Reply
Anyway, if this is the right program, upload.cgi is 2003.
https://web.archive.org/web/20031014173213/http://www.securityfocus.com/archive/1/314389
That would put CERN as the first you have documented, correct?
My Second / Longer Reply
OK so… let’s establish that OSVDB/VulnDB 228 was created based on Nikto, or as a result of you and I working on it, as the first two references for that entry are the Nikto IDs. Third was Nessus, fourth was Snort (still live on the web, no references/date).
Pretty sure these are two different vulnerabilities. While I don’t have solid refs for the first, witness:
Multiple Vendor /cgi-bin/upload.cgi File Upload Remote Code Execution
Nessus ID: 10290
Upload Lite upload.cgi Arbitrary File Upload
Nessus ID: 11359 That’s a big jump in the world of Nessus plugins, reinforcing that these are several years apart. Nessus 0.99.4 does not have that plugin but 1.22 does, the two earliest versions I could quickly find. Extracting the files from nessus-plugins-1.2.2.tar.gz, I notice that the install-sh script is dated June 22, 1999, so definitely not the 2003 vuln. More specifically:
-rw-r--r-- 1 root 502 1725 Dec 17 2001 scripts/upload_cgi.naslNow, I don’t think we can fully trust that date as when it was commited to the plugin repo, but I cannot imagine that date would be 1+ years before our 2003 vuln was disclosed.
Next, I searched the subject lines for Bugtraq from 1993-10 -> 1995-04 and no hits for “upload.cgi”, suggesting it was disclosed elsewhere or part of a tool at the time.
Next, consider the Nikto lines:
"001404","OSVDB-228","0","@CGIDIRSupload.cgi","GET","200","","","","","The upload.cgi allows attackers to upload arbitrary files to the server.","",""
"001405","OSVDB-228","0","/upload.cgi+","GET","200","","","","","The upload.cgi allows attackers to upload arbitrary files to the server.","",""Can you dig into your side in any fashion to determine roughly how old those Nikto IDs are? Or maybe I can… looking at the next distinct entry:
"001411","CVE-1999-1177","8","@CGIDIRSnph-publish.cgi","GET","200","","","","","This CGI may allow attackers to execute arbitrary commands on the server.","",""That corresponds to:
Lincoln D. Stein nph-publish.cgi pathname Parameter Traversal Arbitrary File WriteFrom 1997-03-14. I don’t think you would have had a signature for a 2003 vuln that far back, right?
While searching this out, ran across this … yeah that is a glorious piece of something hacker related =)
Ok last for my quicker searches, checking my local archive of old vulns, mirrors of early databases where I could, etc.:
https://0day.today/exploit/19385 – looks like that site is still annoying but now redirecting to a general page. Can’t see an immediate archive of it, but if their ID scheme follows e.g. Exploit-DB it will be later than the time period we’re after. Otherwise, no hits even in my collection which if this was from 1994, odds are good I would have it.
Finally, let’s go back to 1994, and we have a whopping 13 vulns flagged ‘web related’. Again, likely more since there were no requirements for completion and promoting entries, some classifications were added later, etc. Of the 13, the upload.cgi is the only one that mentions a script. The only other that has any specificity is:
1994-10-18 Retrospect Remote Control Panel De-initilization Remote DoSSo I start skimming all 1994 and it is full of the classics including -froot, Sendmail, AIX, Vixie Cron, Solaris, HP-UX, etc. I don’t see any others that should be flagged ‘web related’ reinforcing that this is likely not a 1994 vuln, but could be 1995/1996. It also could have been something we saw hacking around or early pentests, yet still not cataloged with the appropriate year, and yet “seen in the wild” while not corresponding to a specific vendor.
So for now, chalking this up to a pure mystery where we got it. I think we can safely say the following:
228 - 1994-01-01 - Multiple Vendor /cgi-bin/upload.cgi File Upload Remote Code Execution
53382 - 2003-03-08 - Upload Lite upload.cgi Arbitrary File Upload - These are two distinct vulnerabilities
- OSVDB, Nikto, and Nessus forensics all show these two are far apart
- The 1994-01-01 date, which we would have defaulted to not knowing a more specific date, is almost certainly wrong even by a year or two.
- Even the Nessus description, along with Nikto/OSVDB, suggests this was an early CGI that was prevalent. e.g. from the Nessus plugin “This CGI has a well known security flaw…“
- I’d guess that ‘Multiple Vendor’ comes from someone writing an upload.cgi and it being re-used in more than one product.
I think I need to make this a blog. If we’re lucky, some other geezer will remember better.
Leave a Reply