Arthur T Knackerbracket has processed the following story:
Malicious hackers are exploiting a critical vulnerability in a widely used security camera to spread Mirai, a family of malware that wrangles infected Internet of Things devices into large networks for use in attacks that take down websites and other Internet-connected devices.
The attacks target the AVM1203, a surveillance device from Taiwan-based manufacturer AVTECH, network security provider Akamai said Wednesday. Unknown attackers have been exploiting a 5-year-old vulnerability since March. The zero-day vulnerability, tracked as CVE-2024-7029, is easy to exploit and allows attackers to execute malicious code. The AVM1203 is no longer sold or supported, so no update is available to fix the critical zero-day.
Kyle Lefton, a security researcher with Akamai’s Security Intelligence and Response Team, said in an email that it has observed the threat actor behind the attacks perform DDoS attacks against “various organizations,” which he didn’t name or describe further. So far, the team hasn’t seen any indication the threat actors are monitoring video feeds or using the infected cameras for other purposes.
Akamai detected the activity using a “honeypot” of devices that mimic the cameras on the open Internet to observe any attacks that target them. The technique doesn’t allow the researchers to measure the botnet's size. The US Cybersecurity and Infrastructure Security Agency warned of the vulnerability earlier this month.
The technique, however, has allowed Akamai to capture the code used to compromise the devices. It targets a vulnerability that has been known since at least 2019 when exploit code became public. The zero-day resides in the “brightness argument in the ‘action=’ parameter” and allows for command injection, researchers wrote. The zero-day, discovered by Akamai researcher Aline Eliovich, wasn’t formally recognized until this month, with the publishing of CVE-2024-7029.
[...] This vulnerability was originally discovered by examining our honeypot logs.
The vulnerability lies in the brightness function within the file /cgi-bin/supervisor/Factory.cgi.
In the exploit examples we observed, essentially what happened is this: The exploit of this vulnerability allows an attacker to execute remote code on a target system.
Figure 3 is an example of a threat actor exploiting this flaw to download and run a JavaScript file to fetch and load their main malware payload. Similar to many other botnets, this one is also spreading a variant of Mirai malware to its targets.
In this instance, the botnet is likely using the Corona Mirai variant, which has been referenced by other vendors as early as 2020 in relation to the COVID-19 virus.
Upon execution, the malware connects to a large number of hosts through Telnet on ports 23, 2323, and 37215. It also prints the string “Corona” to the console on an infected host (Figure 4).
Static analysis of the strings in the malware samples shows targeting of the path /ctrlt/DeviceUpgrade_1 in an attempt to exploit Huawei devices affected by CVE-2017-17215. The samples have two hard-coded command and control IP addresses, one of which is part of the CVE-2017-17215 exploit code:
The botnet also targeted several other vulnerabilities including a Hadoop YARN RCE, CVE-2014-8361, and CVE-2017-17215. We have observed these vulnerabilities exploited in the wild several times, and they continue to be successful.
Given that this camera model is no longer supported, the best course of action for anyone using one is to replace it. As with all Internet-connected devices, IoT devices should never be accessible using the default credentials that shipped with them.
(Score: 3, Funny) by mcgrew on Sunday September 01, @10:47PM (3 children)
How can a five year old exploit be "zero day"?
We are all S/Ners here
(Score: 5, Insightful) by dwilson98052 on Sunday September 01, @10:58PM (1 child)
Do not try to understand the exploit. That's impossible. Instead... only try to realize the truth. There is no security.
(Score: 0) by Anonymous Coward on Sunday September 01, @11:43PM
There. Fixed that for you.
A compromise would be for the ostensible customer / ostensible owner to be able to selectively disable misfeatures. Having the source would allow that for sure, but there are other ways.
"""
.......................
1. If you deliver your software with complete and buildable source
code and a license that allows disabling any functionality or
code the licensee decides, your liability is limited to a refund.
.......................
Clause one is how to avoid liability: Make it possible for your
users to inspect and chop out any and all bits of your software
they do not trust or want to run. That includes a bill of materials
("Library ABC comes from XYZ") so that trust has some basis,
paralleling why there are ingredient lists on processed foods.
The word "disabling" is chosen very carefully: You do not need to
give permission to change or modify how the program works, only to
disable the parts of it that the licensee does not want or trust.
Liability is limited even if the licensee never actually looks at
the source code; as long has he has received it, you (as maker) are
off the hook. All your other copyrights are still yours to control,
and your license can contain any language and restriction you care
for, leaving the situation unchanged with respect to hardware-locking,
confidentiality, secrets, software piracy, magic numbers, etc.
Free and Open Source Software (FOSS) is obviously covered by this
clause which leaves its situation unchanged.
"""
http://geer.tinho.net/geer.blackhat.6viii14.txt
(Score: 2) by JoeMerchant on Monday September 02, @12:52PM
Zero day refers to when the good guys became aware of the problem.
🌻🌻 [google.com]
(Score: 3, Interesting) by JoeMerchant on Monday September 02, @12:58AM (4 children)
Amcrest, I guess this particular vuln doesn't apply.
Unfortunately, my use case (watching AC coils for frost) does occasionally benefit from outside access. If I could buy good R22 for the unit I would just recharge and be good for another 11+ years, but unfortunately that's not possible. So, instead of guessing when the evaporator coils might have frozen over (about one day in 20, during the summer) I can just check the camera.
I don't care who sees my coils, but I certainly do care who is inside my NAT with access to my internal network.
🌻🌻 [google.com]
(Score: 2) by RS3 on Monday September 02, @05:14AM (3 children)
Temp sensor on the coils? Then maybe shut off compressor? And / or more fan speed?
Can't buy good R22? How about bad R22? Sorry, dumb joke. But seriously, I have only a moderate understanding of refrigeration. Would more R22 prevent the freezing?
(Score: 5, Informative) by JoeMerchant on Monday September 02, @12:51PM (2 children)
No, the problem started because the coils needed cleaning, so the AC guy "recovered" our 11 year old good working R22 into his tank while he cleaned the coils (and they certainly needed cleaning), then after recharging the system to specified operating pressures, it works fine except when it runs continuously and the outside temperature drops abruptly (as at sunset, or perhaps a thunderstorm), then frost starts to form, and if it continues running continuously in that state for a couple of hours without cycling the compressor off for at least 5 minutes, it will slowly frost over completely.
So, watch for frost, when too much is seen cycle the compressor off by raising the thermostat set point a few degrees for a few minutes (until the frost is gone).
Too little refrigerant leads to gas in the condenser phase, lower efficiency and lower cooling capacity, and sometimes this frosting effect as well. Too much leads to liquid in the evaporator, lower efficiency and lower cooling capacity. I suspect I have contaminated R22 (with what would be speculation squared), but giving this frosting effect generally seen at a low charge but with "proper" pressures. Efficiency and capacity seems in line with previous performance (with the dirty coil) but I suspect changing the charge level would only make it worse.
I did put a little 2F thermostat bump up in the evening timer program that helps somewhat, but not 100%. The camera was $50 and can be used elsewhere once the AC system is replaced (presumably when it gets worse), the camera saves going to the air handler, opening the intake, removing the filter, crawling on the floor and sticking my head in a 12x12" hole with a flashlight to inspect for frost state, instead I can pull up the live picture on my phone and adjust the thermostat as needed from anywhere...
Which is great right up until it becomes a gateway for global hackers to access my 401(k).
🌻🌻 [google.com]
(Score: 2) by RS3 on Monday September 02, @01:40PM (1 child)
> Which is great right up until it becomes a gateway for global hackers to access my 401(k).
Oh that's easy- don't keep the keys to your 401(k) account login in your camera. Boom, solved. :)
But seriously, thanks, that's all very interesting.
I'm not sure why the tech recovered your R22 before cleaning the coils. Was it a precaution in case he damaged a coil?
I'm pretty good with thermodynamics, and occasionally dabble with refrigeration systems. I was going to dig in and learn more, wanted to understand pressure / temperature charts to determine system fill, etc. The term "superheat" popped up, dug deeper, decided it was far too much to learn for something I only dabble in once every third blue moon. Not to mention the many many refrigerants in existence now.
I wasn't suggesting temperature sensor versus camera. I'm more thinking you might be able to automate the system if you add a temp sensor, correlate the temp with frost buildup (a self-feeding process- the more frost, the less airflow, and the colder the evap gets, and more frost), and not have to monitor it so often.
Admittedly humidity is a big factor, and there are really nice cheap humidity sensors available so you could add that to the equation. If you wanted to. :)
(Score: 3, Informative) by JoeMerchant on Monday September 02, @07:34PM
>why the tech recovered your R22 before cleaning the coils
Because the coils were physically removed from the air handler for a "proper" cleaning with a garden hose, so they were cut out, then resoldered, vacuumed and recharged...
I did an "in system" cleaning myself a few years back, I would rate it as about 25% effective as compared to the hose job.
>far too much to learn for something I only dabble in once every third blue moon. Not to mention the many many refrigerants in existence now.
Knowing the theory is good, but there's almost always practical aspects that confound an academic who only knows the theory, no matter how well they know that theory.
>more thinking you might be able to automate the system if you add a temp sensor, correlate the temp with frost buildup (a self-feeding process- the more frost, the less airflow
Yeah, many ways... One relatively easy way would be a simple analysis of how much white coverage is in the picture, too much white calls for a jump in the thermostat set point until the white is gone. The video capture side is pretty straightforward with RTSP and motion jpeg available on the camera. Getting in the thermostat API seems more challenging (Ecobee).
Meanwhile, I just check the standard app when I think about it.
.
🌻🌻 [google.com]
(Score: 2, Insightful) by Anonymous Coward on Monday September 02, @04:16AM (15 children)
Then all copyrights and patents should be forfeited, and all source code provided on demand. They can put that up on their site. We need a balance of power in this business
(Score: 2, Insightful) by shrewdsheep on Monday September 02, @10:06AM (14 children)
When a product is released, specifications, documentation and source code would have to be put into escrow with an organization like archive.org. As long as the company sends a yearly ping (through some official process), the escrow is upheld. Otherwise, assets are released.
Contact your congrescritter/representative.
(Score: 3, Interesting) by pTamok on Monday September 02, @12:16PM (9 children)
If the product is bought by consumers (that is, not business-to-business), then consumer rights come into play. The EU is looking at repairability and long-term maintainability, and I suspect that a minimum length of time for 'fitness for purpose' may well become mandatory - and it could be as long as seven years (e.g. what is a reasonable length of time for 'white goods', like fridges, freezers and washing machines to last for). That has implications for any device dependent on software. Car manufacturers are already being bitten by this - a lot of people assumed GSM phone technology was 'permanent', much like many assumed the first iteration of WiFi was 'permanent'.
Note that there are still pieces of industrial equipment dependent on the use of obsolescent IBM Personal Computer standard equipment and old operating systems. This is a symptom of people not understanding how to design for long term support and maintenance, and buyers not being willing to pay the extra costs required to get such a guarantee.
(Score: 1) by shrewdsheep on Monday September 02, @12:32PM (8 children)
An escrow system could solve problems like these, too. A shortsighted buyer could still get support after end-of-life in the aftermarket that could stem on the released information. At the moment, it is hit and miss whether information is available after support ends (try finding manuals). Also companies tend to fold (or are intentionally folding) taking information with them.
(Score: 1) by pTamok on Monday September 02, @12:57PM (3 children)
Escrow systems don't work well for patented/copyright technology. The owner of the intellectual property might not want to offer a licence to a third party maintainer, or required expensive and/or other onerous conditions.
FLOSS is far better, because you can pay someone else to update software, and you can distribute the updates. Unless escrowed software includes rights to distribute modified copies, it makes the escrow almost useless.
Patents present similar problems: a failed manufacturer might have obtained a licence to use and sell patented technology. As an end user, there is no guarantee that the patent holder will grant similar rights to you, of if they will, at a price you can afford.
End-of-life problems with technology are hard.
(Score: 0) by Anonymous Coward on Monday September 02, @06:12PM (2 children)
Compulsory licensing should be a part of every copyright and patent, and then, at EOL, it is put into the public domain.
(Score: 1) by pTamok on Monday September 02, @08:32PM (1 child)
It might be a leetle difficult to get the wide-ranging change in laws needed to effect that.
Also note that many manufacturers license patents and other intellectual property from someone else to be able to use them in their products: they do not own the copyright or patent that 'should be' compulsorily licensed at a particular product's EOL.
Don't get me wrong: I'm very sympathetic to the idea of things being maintainable/repairable after manufacturer's EOL, but getting there by evolution, not revolution is probably the more achievable path.
(Score: 0) by Anonymous Coward on Monday September 02, @08:55PM
Compulsory licensing applies during the whole lifetime of the copyright/patent. Means what it says, you must grant a license, but not necessarily for free. Public domain takes over at EOL, and that has to apply to every unsupported device, various other components still under C/P protection will, by law, be licensed for third party repair/fabrication/distribution.
Patents are easy, they only last 20 years. The near infinite copyright regime we are under is a bit more difficult. Still, compulsory licensing will go far to mitigate that issue for out of print/stock material. It will definitely slow down the present day upgrade treadmill [youtube.com]...
(Score: 3, Interesting) by janrinok on Monday September 02, @01:04PM (3 children)
I can understand, and perhaps even agree, to the proposal. But I cannot see how it would be funded and what items it would cover.
If it is the original company who set it up then what happens to the site when the company goes into liquidation or simply decides to cease trading?
If it is managed by an entirely separate entity then who funds the personnel and hardware to manage such an entity?
Is it one entity responsible for all electronic items that are produced (by a single company, within a single country, worldwide?), and how would people know which site to look for?
I'm sure somebody can think of solutions to all of these problems with the exception of one - who pays?
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 0) by Anonymous Coward on Monday September 02, @04:58PM (2 children)
I already did, forfeiture of copyright/patents covers all bases. It allows third party support without criminal violation. No escrow is needed. It simply eliminates copyright/patent protection for discontinued products, and another positive for the company is that it would free them of all liability. The only people that would "pay" would be the lawyers for loss of income
(Score: 2) by janrinok on Monday September 02, @05:08PM (1 child)
So who would hold the actual information. On which server? For which products? How did they get it? And who is paying for the server, the connection, and the staff that manage all the software, documentation etc?
How do you make a Taiwanese company hand over the design, software and docs associated with the AVM1203?
I said that all of the other problems are easy to solve. You ignored the difficult one.
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 0) by Anonymous Coward on Monday September 02, @06:06PM
the copyright/patent office should keep copies of everything. If we do need an escrow, that would be it, a bit more secure than any private entity that can just disappear. And regardless of what happens to the source code etc, we will still have the right to reverse engineer and roll our own software/support from that, and make a little mad money besides. So no, I didn't ignore the "difficult" problems. Really the only difficult problem is getting a perfectly good idea on the law books to help balance the power between buyer and vendor.
(Score: 3, Informative) by JoeMerchant on Monday September 02, @12:58PM (3 children)
"Contact your congrescritter/representative."
Easily done. Unfortunately, until you are in the six digit donation club you are "handled" by the critter's junior staff.
Once you have laid down table stakes, then the bidding war starts between you and all interested parties on the other side, oh trust me, even if your critter doesn't get them in on the proposed legislation, many of the 534 others will seek them out "for $$$comment$$$."
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Monday September 02, @05:04PM (2 children)
Doesn't cost you a penny to vote them out. All the money in world doesn't matter if they don't get the vote, which places the corruption a little closer than Washington D.C.
(Score: 2) by JoeMerchant on Tuesday September 03, @01:15AM (1 child)
Think of someone you know with an IQ of 100, then realize that fully 50% of voters are dumber than that.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Tuesday September 03, @05:22PM
That's all fine and dandy, but let's not blame the people that win elections for that. And aside from IQ, ignorance is a choice, to remain un/misinformed. Voters choose their own fate. Majority rule might not be suitable after all...
(Score: 5, Insightful) by anubi on Monday September 02, @04:43AM
Even on my "toy" Arduinos, I design in a physical jumper to enable writing to critical areas.
We lost computer sanity decades ago when we embraced over-the-air unsupervised changes.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]