"Unmasking IPVM" - "John Honovich Should Be Cancelled."
The following article was published by someone calling himself "Samuel Smith" from Hong Kong, on IPCamTalk and Reddit, concluding that I, quote, "should be cancelled". Both sites subsequently removed it with neither our involvement nor request.
I do believe in freedom of speech, even for China Communist Party shills, even when it is against me. Ergo, presented below, in full, the article, with a short response by me after it:
Unmasking IPVM
How a toxic mix of rage, inferiority spawned the security industry’s most polarizing figure
Samuel Smith
On the evening of November 13, 1994, Dartmouth University’s Student Executive Assembly Committee signed a letter calling on its 19-year-old Secretary, John Honovich, to resign. The letter stated Honovich had acted to promote his own interests and consistently caused "infighting, confrontation, unproductivity, a poor public image, and has run counter to the expectations of the student body we are expected to serve efficiently and honorably.”
The next morning, the Dartmouth Editorial Board said, “In meetings Honovich has shouted over other members, raised his voice at administrators and chanted incessantly that the president and vice president are 'liars;' he has embodied the plague that has sickened the Assembly over the last few years. In an organization that should no doubt incorporate political viewpoints spanning an immeasurable spectrum, tolerance, cooperation and respect are necessary. The difference between good and bad politicians is knowing where to draw the line - and the Assembly cannot stand idly by while Honovich repeatedly crosses it. The only way the Assembly can hope to regain the respect that Honovich has destroyed is to show the campus that it will not stand for such irresponsible, distracting and disrespectful behavior and that it will stand up against members who use the Assembly as a tool for their own political gain.”
An immature, vain, aggressive and irresponsible teenager became an immature, vain, aggressive and irresponsible adult. It probably would not surprise anyone who knew John Honovich and saw his rage at Dartmouth that he would later so frighten a 41 year-old male that [the man] asked a court to issue a restraining order against John Honovich; or that a security equipment company would fire him; or that he would launch a tabloid website called IPVM to attack and bully the very industry that refused to accept him; or that, perhaps most outrageously, he would think that it would be ok if he hacked into Americans’ security cameras, posted their personal data on his blog and then encouraged others to hack into those cameras too.
This is the story of how John Honovich’s duplicitous website lies and cheats to make him more money.
John Honovich Manufactures Controversy to Make Money
IPVM is a subscription-based website founded in 2008 by John Honovich, a self-proclaimed leader in the video surveillance industry. According to one website that has covered John’s Honovich controversial behavior, “Many believe that he generates controversy through his abusive attacks on companies in the industry and then makes those same companies subscribe to his service so they can review his attacks.”
John Honovich and his helpers at IPVM review products and provide commentary on security industry companies and individuals. The source of any additional funding remains a mystery. His commentaries are highly biased, misleading, and often false.
As the same website that chronicles some of John Honovich’s most egregious infractions stated, “The site does not limit itself to attacking small companies. No company in the surveillance industry is immune to his outbursts. However, is his plan truly to build a subscriber base forced to pay to read the latest malicious content posted about their company on his blog or is there something more deep rooted that forces his pen?”
John Honovich Targets Asian Companies for Being Asian
John Honovich’s greed is only exceeded by an intransigent rage that helps drive him to deploy litany tactics designed to go after any Asian technology company simply because they are Asian.
When the Chinese two-way radio company Hytera submitted public comments to the FCC regarding a proposed rulemaking aimed at curtailing Chinese telecommunications companies operating in the U.S., John Honovich and his employees—without any credible evidence—accused the company of lying.
When Japanese stalwart Panasonic alerted its partners regarding a U.S. policy that would potentially impact their ability to purchase Panasonic products, IPVM again accused the company of knowingly deceiving its partners.
And when a prominent US cybersecurity expert joined a major Chinese tech firm, John Honovich was not ashamed to openly called him “White Monkey.”
John Honovich Is So Biased that the Mainstream Press Does Not Trust Him
John Honovich has set himself up as an unregulated, one-stop testing/media/lobbying operation, which uses its platform, former employees working at mainstream media outlets, and contacts on the Hill, to harass, defame, plant negative and misleading stories about, and—apparently—directly lobby against leading Chinese technology companies. Congressional authorities have been notified about John Honovich’s potential flouting of lobbying disclosure requirements. In August of 2021, House and Senate ethics officers— as reported by Axios—even sent John Honovich a letter indicating he could be required to register as a lobbyist. In a terse and ironic—considering John Honovich’s history of bullying anyone who disagrees with him— comment to Axios, John Honovich accused Hikvision of “bullying a small US business.” John Honovich’s website plainly admits how it operates:Notable media outlets like the Associated Press, the London Times, CNBC and Foreign Policy--when alerted to key facts about John Honovich—have either clarified previous reporting or made editorial judgments not to cover certain issues solely seeded by John Honovich or his website.
One industry trade reporter said, “No one likes John Honovich or believes much of what he says, but you also don’t want to be the one he’s bullying, so I just ignore him.”
John Honovich Hacked Cameras to Peek Into Our Bedrooms
In John Honovich’s crusade to destroy one company in particular—Hikvision—he hacked thousands of its devices without the consent of their actual owners. He then produced a YouTube video instructing the public on how to hack those cameras.
In 2017, John Honovich searched the Internet for Hikvision cameras and used a known vulnerability to bypass the username and password of more than two-thousand unpatched cameras across the United States and Europe. As a result, John Honovich gained unauthorized access to computing systems (IP cameras) owned and managed by U.S. and European citizens.
John Honovich violated U.S. law thousands of times to do this. Section 5 of the United States Computer Fraud and Abuse Act states, “Exceeding Authorized Access. Several portions of the CFAA prohibit obtaining information by accessing a protected computer either (a) without authorization, or (b) in a manner that ‘exceeds authorized access.’”Apparently, he does not think the law applies to him.
An IPVM video instructed viewers how to exploit a vulnerability on any camera that customers had not yet patched with the firmware that the company posted online six months prior. This caused significant exposure to U.S. and E.U. citizens who own and use those cameras to secure their properties and lives.
On December 18, 2017, John Honovich published an article on his website that is open for public viewing. The article explains how John Honovich used the Hikvision vulnerability to gain unauthorized access into the cameras of U.S. citizens who connect their cameras directly to the Internet and who did not patch their cameras in the eight months since the company released the patched firmware. It also includes a map that plots the suspected location of each camera in the United States. When a visitor to the website hovers their mouse over the map, a popup image shows a screenshot taken by John Honovich from each camera that he illegally hacked. Here is an alarming example that shows how John Honovich leered into a child’s bedroom.
In a public blog post, John Honovich brags about his unethical and potentially illegal activity against U.S. citizens who own the company’s cameras. From the article:
“Device IPs were exported from Shodan, the result of a search for Hikvision cameras in the US. Each device was evaluated against 3 key criteria:
Was it located in the US, based on results of an IP Geo LookupJohn Honovich admits that he used the vulnerability to gain unauthorized access to victim IP cameras; looked at the name displayed on the video images; and took a picture from the camera. And on January 2, 2018, John Honovich updated his hack map article to include cameras all across Europe. To this day, the article and the map of IPVM hacked cameras remain accessible and open to the public.
John Honovich Bullies Anyone He Disagrees With
When the FCC invited interested parties to comment on its proposed rule-making that would effectively ban the sale and marketing of certain Chinese companies, John Honovich’s predatory instincts sprung to life. When 20 American Dahua partners came out in support of Dahua, John Honovich published their comments and images on his tabloid, in what appears to be a shameless attempt to place a Scarlet Letter on hardworking Americans.
He followed up this attack by blasting nearly 100 small-medium sized American business owners who also supported Hikvision, and were participating in the FCC process, by openly naming and shaming them on his website.
One U.S. business owner said, “Why is this guy putting my name out there!? This is a public comment period and I have every right to comment. For someone who says he’s a voice of the people, it’s pretty ironic that he would try and silence me this way.”
One American company had enough. In a cease and desist letter sent to IPVM, one security equipment maker said,“Your campaign to intentionally defame Arecont includes recent postings by you entitled ‘Lying at Arecont Vision’ and ‘Liars at Arecont Vision’. In these postings, in which you say you are relying on the findings of an alleged security blogger, you accuse my client of lying in its advertising, specifically with respect to a MegaDome® print advertisement. You also make an off-handed remark alluding to what you characterize as Arecont’s ‘fallacious megapixel math.’ I will give you the benefit of the doubt - this one time – that, perhaps, you honestly believed at the time that what you posted was true and that the image in the circle marked ‘actual image’ was not an actual image from Arecont’s camera. Be advised, however, that the image in the circle labeled ‘actual image’ in Arecont’s print advertisement is, in fact, an actual, true image from an Arecont camera. Rather than falsely conclude that the image was simply too good to be true and, therefore, that it must be false advertising, you should have investigated the quality of Arecont’s products more thoroughly. Then, perhaps, you would not find yourself in the situation you are now in. Dissemination of false, defamatory information is actionable in a court of law.”
John Honovich Should be Ignored … and Cancelled
John Honovich’s time at Dartmouth was a harbinger of things to come. As one website cataloging his infractions put it:
“Recently, court documents were obtained detailing a dark past with allegations of physical and mental abuse. This in itself may not be as telling as the actual statements of his 41-year old male accuser. Statements like ‘He [John Honovich] always carried out his threats which got worse when I complain and/or challenge his control or power.’ The complaint continues, “He brags about his ability to verbally attack others. He squeezes his girlfriend’s head and pulls her arms behind her back.” And finally the complainant filed a Restraining Order against John Honovich indicating that “[John Honovich] would cause any reasonable person to suffer extreme emotional distress.” Mr. Honovich then continued to violate the Restraining Order and was arrested by the Honolulu Police Department. He was ordered to immediately turn over all firearms, ammunition, permits and/or licenses to the Honolulu Police Department.”
As yet another blogger stated:
“One by one, the pieces [of John’s life] are not that damaging, but put together, they paint a picture of a man with an unusual, and perhaps morbid psychology. It takes more than a little poking fun at people to have 8 out of 12 people sign a petition for your resignation. It takes a little more than friendly harassment to get a TRO [temporary restraining order] stuck on you. It takes more than a few inflammatory tweets to get someone to create a whole blog dedicated to exposing him.”
John Honovich is simply not credible. He cannot and should not be trusted. In fact, given the serial nature of his transgressions, John Honovich should be cancelled.
While "Smith" makes a broad array of accusations that I am happy to address, as people are interested, I will start by focusing on 3 particular ones.
Dartmouth Student Government: I was 18 years old, not 19, and while in November there was a letter calling for me to resign, just 2 months later, that same student government elected me Vice President. I am not sure how productive it would be to analyze the details of what I did as a teenager more than a quarter-century ago but suffice to say, the situation was more complex and I had far more support than "Smith" construes.
Arrest by the Honolulu Police Department: That was more than 20 years ago. I had an argument with a housemate about the rent which led to him getting a TRO against me. Then, when another housemate arranged for a mattress company to return a mattress I had bought, the housemate who got the TRO contacted the police arguing that by having the housemate facilitate returning a mattress, I violated the TRO. This was as bizarre as it sounds. The charges were shortly dropped, without me doing anything.
Hikvision Hack map: This is something that Hikvision has been complaining about for years. Hikvision's Jeffrey He notably declared that "This is the most outrageous behavior I have seen in my 27 years in the global security industry." Evidently, it was even more outrageous than Hikvision placing a backdoor in tens of millions of its devices or abusing human rights in Xinjiang or selling manipulated fever cameras, etc. As we explained at the time, we simply used the authorized access that Hikvision designed into their products.
I think criticism, even of this variety, is useful for the subjects to better understand their actions and to improve. For sure, I am more mature and sophisticated than I was a teenager, the core thread of this article.
As for "canceling" John Honovich, as IPVM approaches 30 team members, our goal is beyond "John Honovich", to be an institution that researches, exposes, and advocates for better and more ethical usage of technology around the world, including the PRC and USA.
Any questions or feedback, please let me know!
John "unmasks" himself every time he communicates. I don't always agree but that's the fun of it. Imagine a world without IPVM - now that's no fun.
Very interesting. How factual is this litany? I alway read article of this nature with a high level of distrust. I am sure John is and was a rabble rouser, that is not always bad. When I raise my montra of "protect us from zealots no matter what their cause", someone once replied, "if we did not have zealots, how would we know where the middle is?" A very good point.
Poke the PRC bear and instead of DIRECT truthful answers and information to dispute your reports, all they can do is make personal attacks.
When they get persi Al, you know you hit a nerve. Keep up the good work John.
Well I don’t think he will be traveling to China any time soon.. that is for certain.
….
Right John?
………. John??
😆
Still, not vulnerability, but backdoor
then don't you wonder why it has been assigned a CVE (CVE-2015-7755) where V stands for Vulnerability?
Hint: vulnerability is a generic term for a weakness in an information system that could be exploited or triggered by a threat source, and this clearly is.
Bonus: not all backdoors are vulnerabilities.
<<< %s(un='%s') = %u
Still, not vulnerability, but backdoor.
Even Rapid7 write 'backdoor' on this one.
I would think the PRC or Vlad would be able to hire more proficient English speakers. Looking at the usage of language, it would appear to be written by a non-native English speaker.
A simple study of the following sentence makes it quite clear:
John Honovich’s greed is only exceeded by an intransigent rage that helps drive him to deploy litany tactics designed to go after any Asian technology company simply because they are Asian.
It is a very interesting piece linguistically and in terms of understanding the use or propaganda pieces, but, since it is not the purpose of this forum...
I think the most concerning information contained in the entire report is that John squeezes his girlfriend's head. Really John?
Ok, UI24 isn't very consistent into what's been written then. On other hand, UI24 did write many times that specific CVE are a 'vulnerability', and it's clearly not within the definition of 'vulnerability'.
The ethics of making a map of these backdoored devices is another discussion, that's also handled in this thread, but I'm trying to staying out from that one.
I don't think that backdoor vs vulnerability is an argument #24 is trying to make. See this quote from somewhere above:
anything that allows to bypass a security control can be considered as a backdoor. Even hard-coded default credentials. So this vulnerability counts as backdoor, this is not in question.
You actually expoited a vulnerability
Dear UI24,
I have now tried to keep quiet for a while, but now I want to ask you something - as you stated that you are Cybersecurity Engineer.
Q: What is the difference between;
http://camera.ip/onvif-http/snapshot
and
http://camera.ip/onvif-http/snapshot?auth=YWRtaW46MTEK
HINT:
First URI: Provides snapshot with credentials
Second URI: Provides snapshot without credentials
FYI:
$ echo -en 'YWRtaW46MTEK' | base64 -d
admin:11
My answer as non Cybersecurity Engineer, only as a simple vulnerability researcher. This is NOT a vulnerability, this code is there on purpose (for whatever reason), and must defiantly be classified as backdoor.
Have a nice day
Was not purporting it to be fact. But I agree I should have started it with " It is my view that"......
But i dont have time to list all of the positive aspects of CCTV in our society versus all the negative ones. Even though Im not a betting man, Id drop some serious coin on the positive outweighing the negative. I mean, cmon, theres alot of assholes out there who would get to continue to be assholes if it werent for CCTV. But no technology is perfect, and alot of good technology and advancements in technology gets used for evil instead of good all the time (And that IS a FACT) but using that standard as a judgement guage, Im not sure that justifies the elimination of any new technology or advancements in technology either way. Or even the proliferation of any technology for that matter.
PC's and the internet in general would be a good example of my point.
| 01/17/22 04:24pm
Despite this, no one has ever accused Juniper to have intentionally planted it on shipped devices
Perhaps. Most of the followup on that vulnerability you reference seems to trace it to an NSA-originated bit of code. It's unclear exactly how that particular code got into Junipers firmware (eg: did they include it all willingly knowing what it was, did they include it not knowing what it was, or was it somehow planted in the source code without any help from Juniper management), but the general agreement on it is that it was essentially a backdoor that has government fingerprints on it.
This has been a primary part of the argument for banning Hikua/Huawei, and other Chinese government controlled networking gear from use in the US, we all know that large governments are waging cyber warfare. I am certainly not saying the US government is not doing the same kinds of things when they can, and of course the Chinese government is as well.
Juniper also handled the response and messaging different than Hikvision, though also not exactly with a stellar plan, IMO.
You are arguing about whether this was "intentional" on Hikvision's part, as if to imply it would have gone through some kind of internal voting process or highly considered decision, and you're claiming that IPVM and others should not call it an intentional backdoor. IMO you're splitting hairs on this topic. There was code in Hikvision products for years that enabled unchallenged admin level access to devices to entities that knew the right strings to add to the cgi calls.
At this point we are going in circles on this and not adding much new, so you can make your next post/rebuttal and consider yourself as having had the last word on this thread from my perspective.
#24, you said:
no matter how structured and managed the processes are within a company, human errors can always occur
and also said:
I'm saying that companies with poor/weak QA in place don't look at source code.
Your opinion then is that with Hikvision that "human errors can always occur" or "that they have "poor/weak QA" or?
are you really saying that this "lazy developer" who you believe did this also made it very hard to find?
No. As I said, this piece of code was very easy to find (actually, too easy to find to assume this is intentionally planted malicious backdoor, have a look at my comment about Juniper below) once you have access to source code. I'm saying that companies with poor/weak QA in place don't look at source code.
what is your working definition for a "backdoor" in this context?
anything that allows to bypass a security control can be considered as a backdoor. Even hard-coded default credentials. So this vulnerability counts as backdoor, this is not in question.
We're discussing whether this was intentional (and this is the message IPVM is spreading with its articles) or not.
To me this sounds as double-standard. To give you an example of this, consider CVE-2015-7755: this was a vulnerability discovered on Juniper firewall. It's very similar to the one we're discussing here, it's an authentication bypass using an hard-coded password which allowed to impersonate admin (detailed report here). Needless to say, this vulnerability is even worse than Hikvision one because it applies on firewalls, which by definition have a leg on untrusted network, instead cameras shouldn't be facing untrusted network (let alone the internet). Anyway, in Juniper case, the "magic string" (i.e. the hard-coded password) was
<<< %s(un='%s') = %u
Compared to the silly "auth=admin" used by Hikvision, this one has been smartly chosen because it seems like the (many) debug strings which often appears in software codes, so it may go unnoticed even during code reviews. Because of this, to me this sounds as this was an intentional backdoor to be put on production devices.
Despite this, no one has ever accused Juniper to have intentionally planted it on shipped devices, or to "have contributed" to this backdoor in any way. And no-one ever dared to publish a Juniper hack map (there were 25k+ vulnerable devices on shodan at that time, and given that firewalls are meant to protect networks which deserve security, just imagine how catastrophic this would've been).
I dare not imagine what media would've said if it was Huawei instead. This is the double-standard world we're living.
You say:
vulnerabilities like the one we are discussing are often difficult to spot once they're put in firmware code
But previously you said:
Maybe a lazy developer added this quick-and-dirty piece of code for his own use during dev/integration for quickly bypassing authentication and testing features across different devices because he didn't want to bother with the different default passwords.
Why would it be hard to spot, as you say, a specific piece of code inserted into bypass authentication?
I totally agree with you that many vulnerabilities can be difficult to discover but are you really saying that this "lazy developer" who you believe did this also made it very hard to find?
I've seen various forms of bypass for development and testing over the years. They are generally really easy to read as if they were innocuously placed in, they are clearly shown, yes/no?
Are you saying you believe Hikvision has no code reviews? That Hikvision has no senior engineering managers actually examining what gets shipped to production? Any lazy developer can just check in anything they want?
I think that, no matter how structured and managed the processes are within a company, human errors can always occur. Here's an interesting list of software bugs with extreme consequences. You may notice most of them happened within governmental/defense industry which is the industry with the highest overhead in terms of management and supervision layers. Let alone such trivial bugs can appear in consumer/business electronics industry too.
I'm not aware of bug-free software. Critical vulnerabilities are present in Bosch, Axis, Cisco devices too, companies which have demonstrated structured processes in place, so I'm not surprised this can happen in Hikvision too.
For the record, vulnerabilities like the one we are discussing are often difficult to spot once they're put in firmware code, because they can only be found by analyzing source code (either via peer review or SAST) and this is not always the case in companies with poor QA which usually focuses on testing compiled code only (e.g. manual functional tests, DAST etc.).
| 01/17/22 12:55pm
I thought you meant the latter all this time, but the quote above seems to imply the former.
A few thoughts on this:
1) I think everyone can agree that this kind of code/process is something that needed to be deliberately added. The way it works is via specific strings, not something like a SQL injection, buffer overflow, or other kind of exploit that leverages existing code for unintended or unanticipated results.
2) The functionality fits the textbook definition of a "backdoor", given that it provides a away to get admin level access to a device, even if the user took precautions to change the admin password or other default credentials.
3) It persisted in the code for a number of releases and appears to have been utilized by other Hikvision devices/software/etc at some point, implying that it was not forgotten or overlooked code.
In terms of malice vs. laziness, that is a tough call, and it could possibly be both. EG: we know that the NSA often finds vulnerabilities in products that it does not disclose, and uses for its own purposes. It is possible that this backdoor was first added out of a sort of laziness, but then when noticed by other aspects of Hik/Chinese government was not ordered to be removed because of the potential for future exploit use. People are saying "the Chinese government wouldn't do something this obvious", which gives them excellent plausible deniability, while maintaining full remote admin access to millions of endpoints on all kinds of networks.
I personally doubt that this code/functionality originated in the form of some government order to create a backdoor, but I do not think that means upper level officials were not aware of it and the potential it provided.
#24, Brian mentioned something below, which I hadn't realized:
I pieced together that what LIKELY happened is he was doing some general investigation of the communications between a Hik NVR and camera, and observed that the NVR was able to control/update a camera that it did not have admin credentials for. This led to some network traffic monitoring and the discovery that if you passed a certain character string to the camera it would execute the API commands as an admin user, even if you did not know the admin password.
My personal belief is that at least part of the justification for this was to reduce support overhead for Hikvision, allowing NVRs to control connected cameras without needing known credentials for each camera. A bit of a "possession is 9/10ths of the law" kind of thing, if the camera is on your network and you have access to the NVR you then should be allowed to control the camera.
Using the backdoor in production code cast a different light on it (to me at least). I was not aware of that before.
That makes accidental debug less likely. I guess it's possible (given modern software development) that the code was an accident by the camera team that the VMS team started using without triggering any extra security reviews. But it's almost guaranteed that more than one person saw this and knew it was going into production.
Now, Brian + John, when you use the words "backdoor deliberately added", do you mean this was a dumb idea okayed by lazy/incompetent managers (as opposed to being an accident); or do you mean it was added maliciously with a view to possible future attacks; or something else entirely? I thought you meant the latter all this time, but the quote above seems to imply the former.
I personally find the lazy/incompetent thesis more likely, especially if it was actually being used by the VMS. That's not a way to keep something secret.
(Sorry, Brian, haven't been able to reply. Work got real busy lately. And John, sorry about hijacking your thread about nonsensical attacks by having an actual discussion.)
| 01/17/22 02:02am
Yes I think it helps
While we're on the subject, given your claimed expertise and desire for precise wording, what is your working definition for a "backdoor" in this context?
This Hikvision vulnerability is a shame and makes us question the overall quality of its products, at least at that time.
They also make us question what the Chinese Government ownership has to do with the "venerability".
Maybe a lazy developer added this quick-and-dirty piece of code for his own use during dev/integration for quickly bypassing authentication and testing features across different devices because he didn't want to bother with the different default passwords.
#24, help me to understand this type of defense. Are you saying you believe Hikvision has no code reviews? That Hikvision has no senior engineering managers actually examining what gets shipped to production? Any lazy developer can just check in anything they want?
To be clear, I definitely believe you are knowledgeable and respect your taking a contrarian position here but I am unconvinced by this type of "lazy developer" rationalization. Thoughts?
Obviously criticism by IPVM is not being received with a view of improvement and improved transparency.
I think IPVM is to be commended for drawing attention to human rights violations. More companies need to do this.
The ultimate customers definitely need to be more aware. These unfortunate situation is not just om IPVM but numerous other worldwide sources. Also directly from people involved.
Besides the human rights violations there are have been other very significant problems identified..
More worldwide companies need to stand up and push back against China rhetoric. Good on him for making a stand.
What normally happens to a person in China is they "disappear" and may or may not re appear.
Also look what China said about activities in South China Sea and the situation now.
All those fishing boats - tied up together. They must thing people are stupid. If reflects badly on China.
if you think arguing these semantics helps your case
Yes I think it helps because -given that base64 is just encoding and has nothing to do with encryption- a base64 encoded string is just clear text and shows Hikvision made no effort to even slightly obfuscate the "magic string", which is unreasonable for a backdoor.
no practical way for this bit of admin authorization bypass to get into the code accidentally
I don't think lines of codes self-generate. I think these lines were added for some reasons during dev or integration, and then they were forgotten in production. Maybe a lazy developer added this quick-and-dirty piece of code for his own use during dev/integration for quickly bypassing authentication and testing features across different devices because he didn't want to bother with the different default passwords.
Are you saying Hikvision is producing third rate products, or are you just throwing in a comment about other Chinese companies here?
consumer market is flooded with chinese cameras which are security nightmares. The holes exploited by Mirai showed these companies lacked basic security posture. Now with P2P isn't much better. This Hikvision vulnerability is a shame and makes us question the overall quality of its products, at least at that time.
So what is your point? The actual vulnerability is not relevant because of the method of disclosure. Better the Snowden approach.
The difference is intent.
Suggest a method of disclosure that would get as much attention, be safer, and result in an action that would protect all of those vulnerable.
HikVision notifying all registered licensed users and all OEM's immediately of the problem with a link to the fix would have been nice.
The discussion this has created has illuminated many things, including how many would prefer to make excuses than resolve the problem.
I live in the USA
so what? You're not subject to other countries' regulations? Are you aware that GDPR applies to any entity (anywhere in the world) that processes data belonging to EU citizens?
It's a bit different, and I expect you can actually figure out why its not comparable if you're actually a vulnerability researcher
The two things are two different methods for achieving the same (illegal) result: gaining unauthorized access to something you don't own. When you're in court, the method doesn't count much. If you obtained data illegally, the judge won't care much if you obtained it through directory traversal, SQL injection, or appending a string to a URL.
| 01/17/22 12:19am
base64 is not encryption, it is encoding.
Fair point, I was trying to keep the conversation more generic, but if you think arguing these semantics helps your case, then score a point I guess.
As I said, I don't think it's intentional
But you would agree there was no practical way for this bit of admin authorization bypass to get into the code accidentally, or as the unintended results of some other feature or function, right?
A lot of chinese companies deliver third rate products
Are you saying Hikvision is producing third rate products, or are you just throwing in a comment about other Chinese companies here?
admin override via a lightly encrypted string
base64 is not encryption, it is encoding. If you confuse the two, with all due respect I don't think you're the right person to discuss about vulnerabilities and cybersecurity.
Your argument is that somehow the code to allow for an admin override via a lightly encrypted string got into the code by accident, and then was subsequently overlooked by developers and QA for 3+ years all on complete happenstance? There was no intention on the part of Hikvision/their developers to include this code, and leave it in there across multiple firmware releases?
As I said, I don't think it's intentional for 2 reasons: a) intentionally planted backdoors are as covert as possible because they should not be discovered, I provided you a good example with NSA-planted backdoors on Cisco devices: no one would have known without Snowden. Thinking that Hikvision designed a backdoor as simple as the string auth=admin, and left the code unhidden is just ridiculous; b) mistakes like that may happen in software development, and can stay unnoticed in companies with poor QA. A lot of chinese companies deliver third rate products and demonstrated very poor QA which led to catastrophic vulnerabilities (think about Mirai).
The point is, according to my experience and reasoning I believe that was not intentional, but I don't dare to say it's certainly not intentional, because no one can sustain any of the two options with certainty without further proofs.
It was written and intended as an opinion. My apologies for not being clear in that regard upfront. I cannot edit after voting but I would insert “It is my view that……” at the very start.
IPVMU Certified | | 01/16/22 08:31am
And maybe there is another BIG question? What do we expect from banned companies? Is it simple war with everything made in PRC or the world wants to show WHY and WHAT is not acceptable. If that is only the war and we try to find a reason to ban.. it's more complex - where is the line that shows who is ethical in that game..
If we would like to simple protect the market for our own producer - this is reasonable.. but we should this maybe says clearly:) But then .. maybe there are not too much easy ways (like taxes for imported goods etc) to eleminate these products from the market?
I'm wonder what will happend in the rest of the world eg. Europe.
I wonder more about belt and road countries in Africa, S and C America, etc...
due to the belt and road are they even able to resist/ban PRC controlled equipment providers?
IPVMU Certified | 01/15/22 09:23pm
Strange attack. However HIK is the biggest player and has many bugs to loose - so the rage is going on.
I'm wonder what will happend in the rest of the world eg. Europe.. something's going on in Italy and Great Britain, something in Poland .. let's see
The benefits of CCTV globally outweigh the negative aspects of the day to day intrusion into the general public lives of the law abiding citenzry.
Now do PRC/HikVision human rights abuses...
The benefits of CCTV globally outweigh the negative aspects of the day to day intrusion into the general public lives of the law abiding citenzry.
says you. I would not make such a generalization purporting it to be fact.
Absolutely agree.
If those in our security industry including distributors and OEM's can agree to do their part by not using equipment that places network privacy at risk, we can do our part. The regulations and bans tie the bow on the box.
Next is continuation of technology development that mitigates and eliminate the risks that already exist becoming top priority.
The benefits of CCTV globally outweigh the negative aspects of the day to day intrusion into the general public lives of the law abiding citenzry. It is TRUE that a greater global conversation is way overdue regarding the global exansion of surveillance use for any other political purpose, including governmental use for the purposes of spying on free citizens, or the segregation, control and/or eliminiation of any ethnic, racial, or religious group.
With that being said, and with absolutley zero experience in espionage, Im convinced, and even a village idiot could figure out that it is the past, current, and future intent of the Chinese (and Russian) Governments, to pursue initial and ultimate permanent access to every commercial, residential, public and private network on the planet, and that those networks currently residing in the USA are of the highest priority to them, and that they will use whatever means at their disposal to accomplish that objective, either through covert cyber intrusion or even through common interfaces acquired through their global manufacturing posture. They have chosen IP Video Cameras as the primary (but not only) way of doing this because of its prolific attributes at this time in the technological history of the world. They can swear and promise that they will be good boys and girls all they want. Only a fool would believe them and all measures must be taken to interfere or prevent their ability to do these things that they most certainly ARE DOING - and if disqulaifying their product and/or their manufacturing entirely from use in the United States is essential to those counter-measures, then thats how we gotta roll. Whats the worst that can happen? Maybe we start making things for ourselves again and our economy expands? Let them complain to the FCC and Commerce Department all they want. They are bad actors, and they cant be trusted. And they are to be interacted with accordingly at all times. And any American businessman or politician who offers them a hug or a hand is a traitor and a fool.
John Honovich, what we should cancel is the CCTV expansion with its origins in China, everybody knows that they will use any tactic such us the one you received; and in my view it is just a political move. All technology coming from China, including CCTV, etc. is just a mirror copy of what we have been doing in America many years ago; we allowed it to happen unfortunately, and now we see the results. Of course they will use low level technics to shut you down, and to raise issues on you that took place many years ago it is low; we all make mistakes when we are young and none is exempt from it, that let you see how desperate they are.
What needs to be done is to organize us as a front to keep defending the bad actors, including some companies that are outside China.
| 01/14/22 01:13pm
This is not true.
You can go back on read the IPVM reports, and other things like Krebs on Security, that were publishing info on this as parts of it were disclosed. Amongst other statements from Hikvision around that time was their ""never backdoors" statement, and their overall downplaying calling it a "privilege escalation" and that the "overwhelming majority" of devices were essentially not at risk because they were not directly connected to the internet.
Yes, Hikvision released firmware patches. However they did not make an adequate effort (IMO) to push out notifications and strongly encourage affected users to upgrade asap.
Others have been sentencted for much less e.g. adding 9 characters to a website URL.
That was in the UK. I live in the USA. It was also a case related to a person using URL manipulations that were not the result of direct links on the website, URLs/calls made by other parts of the website, or methods that the designer of the website seemingly intended to be used. It's a bit different, and I expect you can actually figure out why its not comparable if you're actually a vulnerability researcher.
You actually expoited a vulnerability
What I saw from them is that they would "never" include backdoors in their products, so then this must have been intentional functionality, right?
| 01/14/22 04:53am
Keeping saying it, without ANY proof makes just clear to anybody how biased you are
How do you interpret this statement in the initial disclosure write up:
It is nearly impossible for a piece of code that obvious to not be noticed by development or QA teams, yet it has been present for 3+ years.
Your argument is that somehow the code to allow for an admin override via a lightly encrypted string got into the code by accident, and then was subsequently overlooked by developers and QA for 3+ years all on complete happenstance? There was no intention on the part of Hikvision/their developers to include this code, and leave it in there across multiple firmware releases?
I'm a cybersecurity engineer and I'm fully aware of "what happened". If you're interested to this topic, before judging I invite you to re-read my comment and replies to other comments I gave. I explained why exploiting a vulnerability of devices you don't own is considered despicable within the (white hat) cybersecurity industry and illegal in most of the countries.
Certainly, it was intentional.
Keeping saying it, without ANY proof makes just clear to anybody how biased you are and this doesn't do justice to IPVM work which is usually good. Montecrypto himself, who discovered the vulnerability, in his full disclosure said (emphasis mine): Planted backdoor or accidental bug? Make your own judgment. [...] Hikvision indicated that it was a piece of debug code inadvertently left by one of developers. It is plausible, that a developer forgot to remove a piece of test code and it went unnoticed for years. There are no attempts to hide the backdoor code which would certainly be expected in case of a deliberately planted backdoor.
The fact you appear to have such a certainty, Montecrypto himself doesn't have, is kinda pathetic. Others have tried to explain you that base64-encoding of "admin:<whatever>" is not something you would expect from an hidden and obscure "magical" backdoor intentionally planted and shows it was instead an unfortunate (and shameful) piece of code left there during development/integration.
However I noticed you skipped my question: "If I use a Windows vulnerability to access your computer without your consent (I'm assuming you're using Windows but the same applies to other OSs) and make your own files publicly available, who should be sentenced, me or Microsoft?". I'd be curious to know your answer as this example -in terms of behaviour- is exactly what IPVM did with that map.
I would done same thing, all because of the reason to raise awareness
You DO NOT raise awareness by exploiting a vulnerability on devices you don't own. Awareness is raisen through responsible disclosure, and this is what Montecrypto did. IPVM added nothing to this.
Ah... how funny would be to make public your own data by exploiting a vulnerability of your OS and then justifying by saying "come on, I just wanted to raise awareness on how flawed and vulnerable your OS is...".
[the Hikvision hack map] became one of IPVM's most popular posts, I had many industry friends at other companies call me and tell me how much they enjoyed it ;)
this is not funny. You actually expoited a vulnerability for gaining unauthorized access to devices, retrieved data you don't own, stored it and made it publicly and easily available to anyone (even to non-members, how bad...). I actually saw people's faces in those screenshots. That's creepy. Others have been sentencted for much less e.g. adding 9 characters to a website URL.
Tl;DR - The Hikvision hack map came about because Hikvision attempted to mislead people about the extent of the problem.
This is not true. As the Montecrypto full disclosure shows, Hikvision started publishing firmware updates for affected devices one week after they were notified of the vulnerability and much before the vulnerability became publicly known. In the cybersecurity world, this can be considered responsible behaviour. Any vendor tries to downplay their vulnerabilities, but this is not relevant, given that vulnerabilities are scored by independent organizations (and this one was scored 10/10). What Hikvision should've done? Phone each single device owner begging to update their devices? The best a vendor can do is acknowledge the vulnerability and promptly release patches and Hikvision, in this case, did that.
You completely misunderstood my words. Notifying the world about a vulnerability, when done correctly (in computer security world this is called "responsible disclosure") is praiseworthy. Here, the security researcher Montecrypto (who discovered the vulnerability) did a responsible disclosure, so this was perfectly right. He didn't expose anyone's data. Hikvision is certainly to blame for having such a bad vulnerability and shows how shameful was their QA process in place (at least at that time).
What I'm saying is that IPVM gained unauthorized access to vulnerable devices by exploiting this vulnerability and actually publicly exposed people's data, and anyone with minimal knowledge of cybersecurity will say this is just wrong. They didn't just expose the vulnerability, they actually expoited it on devices they don't own and this is bad and -often, like in this case- a crime. As simple as that.
Firstly, I prefer to be called 'researcher' before 'hacker' :) Still, sure, I do hack some code, or even crack some other code to do what I want it to do.
(Hacker, cracker, researcher... etc. has very close bands, but the ultimate goal differs a lot)
I'm mostly on same page as you when it comes to vendors, but surely - it really do take some considerable time to develop and/or fix some bugs/vulnerabilities without breaking other code and/or dependencies.
Finally, just a tip when/if you would find any RCE, register the 'ui25.wtf' domain here and just let it go =]
Brian,
when I first saw the map I was thinking 'wtf...', but not long after that - I realised that I would done same thing, all because of the reason to raise awareness. Very important IMO to raise awareness that's not damn joke and should not be downplayed, it's real stuff and indeed can impact users/customers/integrators in far more severe situations.
Good job!
Obviously this statement it is consistent with the logic used when HikVision exec clarified last year that Network owners and their managers are entirely responsible for any breaches that occur.
Or in other words,
“vulnerabilities and exploits created by our products are YOUR Problem.”
I have only some comments in the 'debate' you don't want
You just can't tell a hacker to ignore something can you...
Yeah, I'd lean a lot more towards public disclosure personally, but most of the stuff I find is while on the job, so company policy takes over :|
I kinda like giving vendors a chance to get a patch out, but after watching how slow some of them are, I wouldn't mind yeeting a few vulnerabilities so people could take things off line while they wait. "We'll take care of that in the next version [which comes out in six months]" or "Actually, that's not a vulnerability as long as you never let users have administrator rights to their own computer" or "Well, that requires SDK access [completely false], so it's not a problem"... I mean, seriously, dudes...
But company policy says we don't want our partners to look bad because then some other integrator might pitch a different VMS and steal our show.
If I ever find an RCE, that policy is going to get changed very quickly.
| 01/13/22 10:45pm
I'll throw some comments in here since I was involved with this from the perspective of reporting on it for IPVM as it was unfolding.
First, I had some email conversations with montecrypto between the time when the vulnerability discovery announcement was made, and it before the details were publicly disclosed. He did not give me any specifics on the exploit prior to the date he agreed on with Hikvision (90+ days, IIRC). From the conversations with him I pieced together that what LIKELY happened is he was doing some general investigation of the communications between a Hik NVR and camera, and observed that the NVR was able to control/update a camera that it did not have admin credentials for. This led to some network traffic monitoring and the discovery that if you passed a certain character string to the camera it would execute the API commands as an admin user, even if you did not know the admin password.
Every indication I have ever seen, from other comments/disclosures online and my own observations and verification of things makes it appear that this functionality was deliberately added by Hikvision. Among other things, part of the reason I think this was deliberate is because it does not involve buffer overflows, malformed URLs, uploading packages/scripts to the camera, etc. It uses well-documented commands along with a string that has to match a defined hash/format that would not likely occur randomly or as a result of leftover debug code. My personal belief is that at least part of the justification for this was to reduce support overhead for Hikvision, allowing NVRs to control connected cameras without needing known credentials for each camera. A bit of a "possession is 9/10ths of the law" kind of thing, if the camera is on your network and you have access to the NVR you then should be allowed to control the camera.
After the vulnerability was made public, Hikvision chose to try and downplay it, deny the magnitude of it, and otherwise take what I would consider to be an inappropriate response, which put the resellers and users of their products at increased risk.
Hikvision had PLENTY of time to contemplate how to handle the messaging strategy, how to respond to this, how to prepare statements, and so forth. They were not caught off guard by the public disclosure of the vulnerability, and they arguably had adequate time and resources to prepare fixes, patches, press releases, and related items well in advance of the disclosure release.
The camera hack map really came about in response to Hikvision's attempts to downplay this and spin it. They were denying that this was impacting customers, etc. (I'm avoiding too many specifics here because I don't want to go back and re-read all my notes to put together a precise timeline). I forget how I first became aware of it, but I recall hearing about some of the cameras having OSD text changed to "HACKED" on them. This was easy to setup a scan for (pull data from Shodan, use Hikvision's deliberately included admin override to read OSD settings, log results).
The original map was just a screenshot I posted in a comment in one of the threads where I was trying to illustrate that the vulnerability and impact was much larger than what Hikvision was claiming to their dealers. From there it morphed into the full interactive map that you saw (and became one of IPVM's most popular posts, I had many industry friends at other companies call me and tell me how much they enjoyed it ;) ).
If Hikvision had simply owned this in the same manner companies like Axis had, there would have been no need to attempt to correct their misleading comments, and that map probably would have never even existed, it would not have been worth the effort.
Regarding the images and pinpoints, ALL of the data for the map was made using calls to services or devices that conformed to the APIs, URLs, etc. that the originators of those services and devices implemented in their software, published online, or otherwise made available via unencrypted network connections and calls. No encryption schemes were broken, no buffer overflows, SQL injections, or malformed calls or commands were used or needed to gather the data. Making the calls did not disable any of the devices or services, prevent them from being simultaneously used by other users or services, performing their intended functions, or otherwise compromise their availability or continuity.
In the course of gathering data, a number of OEM units were also available for access. Information for those units was not included, only units that appeared to be Hikvision branded were included. While Hikvision could not (IMO) reasonably claim they had no idea this deliberate backdoor existed in their products, their OEM partners were most likely not informed of it upfront and were not aware, so it made sense to not include them. I think at some point there was a list published of other affected brands, based on this data, but the images/geolocations of those units were not published.
Tl;DR - The Hikvision hack map came about because Hikvision attempted to mislead people about the extent of the problem.
Firstly, I really like your post as it touching many valid points and also some greyish areas, to where I have only some comments in the 'debate' you don't want =)
- Announcing to the public is fine (I won't get into the responsible disclosure vs full disclosure debate)
'responsible disclosure' are in my opinion information to vendor prior 90 days to 'full disclosure'.
I do not consider 'responsible disclosure' to give vendors information 90 days before publish some shady details in some blogpost and/or youtube video. If that's the intention, there are no need for any kind of publication at all, as the researcher will not help anyone outside the vendor (so get a t-shirt with the name of vendor).
I am fully aware there are some drawbacks for releasing 'full disclosure', but those drawbacks are less than the actual benefits in the long run for the users/customers.
For instance, we all know that users/customers/integrators do not upgrade their firmwares for some reason, it can be that users/customers/integrators do not know - as vendor do not don't marketing cybersecurity issues with their products as they do with new products.
You and I can have our opinions about that, and maybe even argue few months or years about it, but since we both know that's the case, there are other vendors that makes (most likely) user/customers/integrators more secure with the updates of signatures in their IPS system and stopping exploitation of vulnerable devices.
And one of the most efficient way for making correct signatures for the IPS/IDS is to have valid and correct information about the vulnerability and/or exploit soonest possible, and not some shady details in some blogpost and/or youtube video.
This is one of my main reasons to always publish valid and correct information about the vulnerability and/or exploit.
/bashis
Your not understanding does not make it not so.
Peer to peer networking via QR codes and Serialized servers was I believe, listed as the 3rd most popular method of providing remote access to Video systems. In the IOT APP world it is utilized by over 90% of all products.
That process allows anyone to connect a device to any network via RJ45 or WIFI. Once connected, downloading an APP, or using a Browser one only needs to enter the QR or serial code, and they have full access to that device and the network on which it sits.
As soon as the device detects a network and internet connection it calls home (A server located somewhere in the world). It then checks in providing at least enough information to identify itself, it's originating IP address, it's internal IP address, QR and/or Serial ID. Of course it can provide much more information and connection to other devices than just the one intended. (check out Fing to see how much information is possible and connection methods). It continues to check in periodically to ask the server if there any requests to open a session or provide access to a remote user.
Sometimes an additional Password is required, but generally the QR or Serial ID is all that is needed. So even if the proud owner of the new device doesn't use the APP, once plugged into network anyone with access to the server and with QR or Serial code can access the device. (manufacturers and their staff have that information).
From that point on, what can be seen, or accessed is only limited by the manufacturers firmware and/or software. Firewalls see nothing about which they should be concerned since request comes from a device located on the network.
That is "Front door"access. No back door is required. This feature has been built in deliberately to most IP video, Analog HD Recorders, and virtually ALL IOT products from inception. The features are in plain sight. It is not a hack, the end user invites them in, so they may have the ability to access their IOT device.
Video manufacturers say this is not a problem because you can turn off the feature.
Unfortunately some systems may still 'check in' automatically even if system owner turns off the remote access feature in the user portion of the management software. Apparently the only thing definitely turned off is the remote users ability to access their own system.
Why? A manufacturer might suggest it is necessary in order for them to monitory health, receive check-ins, requests for firmware updates , or any other reason that they feel is important. Even if you are not aware it is happening.
This wonderful feature provides a Wide Open Front Door allowing the manufacturer and any associates with whom they choose to share the information full access to the device, and to its’ network. Apparently they consider themselves invited in, the moment the device was connected to end users network.
Proving that malicious back doors not only exist, but are deliberate needs to be an ongoing concern of our industry. We know they the doors exist because the front doors are in clear sight and arrive master keyed by the factory. Interesting note is that typically on Security Recorders and cameras the feature is defaulted on.
Currently all products and their servers have technology built in deliberately that presents a huge risk to any network on which they sit. Just sayin ..
Ah, I should have looked up the definition. By that, yes it is magic. I still stand by the rest.
Integrator #24 has a good point about accessing these devices and posting the pictures. This is a very touchy area of white hat hacking. I personally would not have done this, but other white hats (case in point) might be fine.
- Discovering vulnerabilities is fine
- Notifying manufacturers is fine
- Announcing to the public is fine (I won't get into the responsible disclosure vs full disclosure debate)
- Raising awareness is fine
- Testing the vulnerabilities on systems you don't own is... questionable. Technically, you could be breaking laws, but a lot of white hats do this as research to determine how bad the impact is.
- Retrieving and storing private information from systems you don't own is... probably illegal. Storing is the big part. Testing the exploit is one thing, storing the stuff you found is really not a good idea for white hats. If you're using it as proof to notify the people affected, maybe it's okay. But other than that, you're starting to move out of the white hat area. Now, guys like Troy Hunt deal a lot with stolen data dumps as a public service, but generally speaking, don't do this.
- Posting the images publicly along with map pin points... also probably illegal. These are images you don't own. Giving estimated locations, really not a nice thing. I don't think the map pin points really impact the legality, but it's pretty close to doxxing.
That said, it was obvious that IPVM was doing this purely for public awareness, rather than trying to spy on or dox people. White hats have done a lot of questionable things in the past for the public good. While it looks illegal, and I disagree with doing this, I doubt that a court of law would do anything more than say, "try to be more careful next time".
I mean magical as it is commonly used, e.g., Wikipedia:
In computer programming, a magic string is an input that a programmer believes will never come externally and which activates otherwise hidden functionality. A user of this program would likely provide input that gives an expected response in most situations. However, if the user does in fact innocently provide the pre-defined input, invoking the internal functionality, the program response is often quite unexpected to the user (thus appearing "magical")
"Magic string" is a misrepresentation of the vulnerability.
YWRtaW46MTEK seems like a random bunch of characters, but as was mentioned in the original report, it was arrived at by base64-encoding "admin:11".
if that parameter contains a base64-encoded "username:password" string, the HikCGI API call assumes the idntity of the specified user. The password is ignored.
The string that gets mentioned is not random or magic in any way.
- username:password isn't magic - that's a common way to deal with authentication
- base-64 encoding isn't magic - base-64 is quite common (shouldn't be used for passwords, but quite common)
- YWRtaW46MTEK isn't even unique - there are many other strings you could use
It's probably not in the source code (I don't have the firmware so I can't say for sure). If the Hikvision didn't have a user called admin, the string probably wouldn't even work even on a vulnerable camera.
From my perspective, this could easily be a developer's backdoor left in by accident. Somebody could have been testing that snapshot feature, or some other part, and didn't want to login every time. It is possible that it was deliberate, but it is not a smoking gun. I place the chances at 60% deliberate because it's so mind-boggling dumb, and 40% accident because developers sometimes are dumb (these are just gut numbers).
If the string were actually unique, and if it weren't as simple as doing a base-64 of "admin:password", or if that string itself were hardcoded into the camera firmware, then I would agree that it was a deliberate magic string. But none of that seems to be true, so I can't go along with calling it a magic string intentionally put into the camera.
Now, if you want to go the PRC direction, you could make an argument that given their political attitude and history, maybe they shouldn't be given the benefit of the doubt for mind-boggling accidents. I won't argue with you on that.
It's not Hikvision that exposed data, but actually IPVM that exposed people's data by gaining access to a device without authorization, exploiting a vulnerability.
Exposing the vulnerability and notifying the world is the crime, not creating the vulnerability?
Unreal.
Ah, yes. I forgot about Montecrypto.
Either way, this guy probably thinks you're Montecrypto also. LOL.
Newest Discussions
| Discussion | Posts | Latest |
|---|---|---|
|
Started by
David Leinenbach
|
8
|
less than a minute by Undisclosed Manufacturer #1 |
|
Started by
Undisclosed #1
|
3
|
28 minutes by Undisclosed #2 |
|
Started by
Undisclosed Integrator #1
|
7
|
18 minutes by Undisclosed Manufacturer #3 |
|
Started by
Brian Rhodes
|
1
|
less than a minute by Brian Rhodes |
|
Started by
John Honovich
|
18
|
2 minutes by John Honovich |
