Lemon Amiga forum hacked!

[jbenam]

Originally Posted by Karlos

Furthermore, I've never seen anything as woeful as NPM from a supply chain vulnerability perspective

Good thing that PHP doesn’t use anything like tha-

Oh wait:
https://www.sonarsource.com/blog/php-supply-chain-attack-on-composer/
https://www.sonarsource.com/blog/php-supply-chain-attack-on-pear/

Originally Posted by Karlos

The key difference between the two ecosystems is that the issues in PHP tend to get dealt with.

Sure, after 20 years? It’s usually too late when they start deprecating stuff - it is already everywhere, everyone is already using it and they will prefer not updating instead of maintaining their code base.

When I usually meet programmers dreading to update their framework because otherwise all hell will break loose they’re usually PHP or Java devs. Node isn’t perfect when it comes to this either, but much better than both.

You clearly have an horse in this race and that’s perfectly okay.

But, be it because of easiness of development, be it because of better dev tools, be it because of a fad - PHP is gonna go extinct (or at least go in a zombie-like state like Fortran and COBOL) and neither of us can do anything it about

[Karlos]

Originally Posted by jbenam

Good thing that PHP doesn’t use anything like tha-

Oh wait:
https://www.sonarsource.com/blog/php...k-on-composer/
https://www.sonarsource.com/blog/php...ttack-on-pear/



Sure, after 20 years? It’s usually too late when they start deprecating stuff - it is already everywhere, everyone is already using it and they will prefer not updating instead of maintaining their code base.

When I usually meet programmers dreading to update their framework because otherwise all hell will break loose they’re usually PHP or Java devs. Node isn’t perfect when it comes to this either, but much better than both.

You clearly have an horse in this race and that’s perfectly okay.

But, be it because of easiness of development, be it because of better dev tools, be it because of a fad - PHP is gonna go extinct (or at least go in a zombie-like state like Fortran and COBOL) and neither of us can do anything it about

I don't have a horse in the race, because unfortunately I have to deal with both. I just don't differentiate between them from a security potential. Anyone who thinks either one is in any way intrinsically more secure than the other as opposed to only being securable by applying proper developmental and infrastructure practises is clearly a liability.

[Karlos]

One of the reasons I singled out NPM is because for the longest time you could actually supply a completely different package than the one specified and it was pretty easy to pull off too. People would think they were getting some stable tag from your GitHub repository and could be getting a completely different package delivered.

With composer, you have been able to be fully in charge of your own locally vetted cache for a long time.

So yeah, for several years NPM was by far the easiest supply chain attack vector for web applications and even server side infrastructure that used it.

[lifeschool]

Originally Posted by Karlos

So yeah, for several years NPM was by far the easiest supply chain attack vector for web applications and even server side infrastructure that used it.

Thanks for your help. Perhaps you could PM me a few options as far as safe security. Surely it cant be an issue for pure HTML 5 web sites, can it?

If Kim fixes the site, it will still be php. It is old. I presume one issue is, nobody wants to recontruct the tower all over again on a new platform?

[Predseda]

Thank all of you for the kind words. I have spoken to Kim today and he hopes the site will be back during next week.

[Karlos]

Originally Posted by lifeschool

Thanks for your help. Perhaps you could PM me a few options as far as safe security. Surely it cant be an issue for pure HTML 5 web sites, can it?

If Kim fixes the site, it will still be php. It is old. I presume one issue is, nobody wants to recontruct the tower all over again on a new platform?

I've had some experience modernising old PHP applications but as has been pointed out a lot of the issues are in bad practise in code that simply upgrading the language isn't going to readily fix. This is one reason why back in the day Wayne at amiga.org upgraded to vbulletin from xoops - the xoops version the forum ran on couldn't even run on newer versions of php. I assume the current owners had a similar issue upgrading from vbulletin to the current software.

Unfortunately the web has become a much more hostile place than it ever was.

[AlphaAmiga]

How awful! I hope the site comes back up soon, its such a great tool for the community

[onkelarie]

What a pity to hear about this. Wishing Kim the best bringing it all up and running again.

[Avanze]

Lemon64 forum I visit everyday, like EAB. I just hope this issue gets resolved.

[jbenam]

Originally Posted by Karlos

I don't have a horse in the race, because unfortunately I have to deal with both. I just don't differentiate between them from a security potential. Anyone who thinks either one is in any way intrinsically more secure than the other as opposed to only being securable by applying proper developmental and infrastructure practises is clearly a liability.

Sorry, but no one here is saying that Node.js is intrinsically more secure but it has clearly and demonstrably less potential for abuse than PHP did (and does, to a certain extent).

Originally Posted by Karlos

One of the reasons I singled out NPM is because for the longest time you could actually supply a completely different package than the one specified and it was pretty easy to pull off too. People would think they were getting some stable tag from your GitHub repository and could be getting a completely different package delivered.

With composer, you have been able to be fully in charge of your own locally vetted cache for a long time.

So yeah, for several years NPM was by far the easiest supply chain attack vector for web applications and even server side infrastructure that used it.

Well, for years in PHP you could do much worse things. Remember the PHP4 days? Dang, you could literally crack it open by sending an HTTP request.

What matters now is the state of things in 2024. You have package locks, local caches (if you wish to do so) and every change is tracked by git repos anyway - saying things like that is disingenuous at best and an attempt to spread FUD at its worst. I could play the same game with PHP but there’s no need - PHP8 has plenty of CVEs already and they speak for themselves. While Node.js might have apparently more (by a very slight number) they’re all less severe than the usual PHP vulnerability that usually ranks in the high 9s.

The two links I brought up in my previous post are all very recent (2022), while the NPM vulnerabilities are MUCH older and have all been fixed since ages.

[saimon69]

Composer never worked with me, i remember trying to use it to install a framework and failed all the time -_-
So i usually did the original sin: use my own implementation of queries and filters; what saved my 655 in my actual job is that the web app is for internal use and therefore most of the traffic is filtered by the employer firewall, but i know is futile...

[bluewizard]

This saddens me when this kind of thing happens. I am glad to hear the owner is on it and will be able to bring things back. I wish them all the best and thank them for making the resource available to us to use!

[Karlos]

What matters now is the state of things in 2024. You have package locks, local caches (if you wish to do so) and every change is tracked by git repos anyway - saying things like that is disingenuous at best and an attempt to spread FUD at its worst. I could play the same game with PHP but there’s no need - PHP8 has plenty of CVEs already and they speak for themselves. While Node.js might have apparently more (by a very slight number) they’re all less severe than the usual PHP vulnerability that usually ranks in the high 9s

Look, pointing out that NPM is routinely responsible for supply chain attacks is not spreading FUD. It's just a fact.

https://thehackernews.com/2023/11/48...ges-found.html

NPM supply chain attacks are far from new, yet it still happens. Getting a remote shell onto developer systems? What's the worst that could happen? Well that depends, but your average developer isn't often that security conscious and your average department often has lax practises like having production secrets on developer machines. There have been several high profile malware deliveries via NPM over the years, not because there's been no effort to improve it, but because the whole culture of not fixing what isn't apparently broken is so pervasive. This applies to Node, PHP, and just about everything else. In 2024, everyone uses containers and as such the incentive to keep things updated when you can just package all your thrown together obsolete crap into an image you can keep running indefinitely has never been worse.

In the end, taking the view that A is somehow not as bad as B in matters of system hardening is how you get owned in a perpetually hostile environment. Whichever technology stack you use, you have to take security seriously or hope that your infrastructure protects you.

[modrobert]

I can recommend ModSecurity (aka Libmodsecurity) if you want to secure a website with PHP running an SQL database (for example), makes it relatively easy to filter out bad requests before they happen and log it.

https://github.com/owasp-modsecurity/ModSecurity

You can extend that with tools which blocks IP addresses in firewall (e.g. 'iptables') based on logged bad requests and to mitigate (D)DOS attacks as well.

[saimon69]

Originally Posted by modrobert

I can recommend ModSecurity (aka Libmodsecurity) if you want to secure a website with PHP running an SQL database (for example), makes it relatively easy to filter out bad requests before they happen and log it.

https://github.com/owasp-modsecurity/ModSecurity

You can extend that with tools which blocks IP addresses in firewall (e.g. 'iptables') based on logged bad requests and to mitigate (D)DOS attacks as well.

Is not a "ready to go" library to just copy in XAMPP though as i need

[jaycee1980]

Originally Posted by jbenam

Drop anything that uses PHP

Nothing to do with PHP, just bad programming. I have written plenty of PHP code which has withstood allsorts of attack vectors.

[Predseda]

Never say never.

[jaycee1980]

This isnt really an attack against Lemon itself - it's just an attack. There's plenty of automated things out there just looking for a server vulnerable to any exploits of any kind - any sysadmin who runs a web server, email server etc can tell you that.

AS Virtual Programming's sysadmin, I saw attacks against our services pretty much every hour of every day. They dont care who you are or what your business is - any server they can take over and use to run further attacks is what they are looking for. Getting user details/passwords is just a bonus.

[Karlos]

^ this.

It's extremely unlikely to be targeted at the forum, it's just a malicious bot trawling for known vulnerabilities. There are plenty especially if things like cPanel or phpmyadmin are installed.

[jbenam]

Originally Posted by Karlos

Look, pointing out that NPM is routinely responsible for supply chain attacks is not spreading FUD. It's just a fact.

https://thehackernews.com/2023/11/48...ges-found.html

NPM supply chain attacks are far from new, yet it still happens. Getting a remote shell onto developer systems? What's the worst that could happen?

Sorry, you either didn’t read the article or you’re purposely omitting the point to make NPM look bad. The latter case falls under spreading FUD in my book.

The article talks about packages with VERY similar names - which is an issue that plagues literally every package system - heck, even more than that. Could be an SDK or a DLL imported using .NET. The same thing can happen with literally every language and this isn’t an NPM issue. There were also cases of infected middleware on iOS and Android being packaged by mistake thanks to being hosted on very-official-sounding repos, which impacted tens of thousands of installed apps. Does that mean that iOS or Android are at fault and should be considered inherently insecure?

If you’re a so-called dev and don’t even check if what you’re installing is *actually* what you meant to install (be it by sigs, checksum, or by just reading the freaking URL you’re cloning) the problem doesn’t lie in the framework and/or the package manager, it lies between the screen and the chair.

Originally Posted by Karlos

In the end, taking the view that A is somehow not as bad as B in matters of system hardening is how you get owned in a perpetually hostile environment. Whichever technology stack you use, you have to take security seriously or hope that your infrastructure protects you.

If you keep “misreading” (let’s call it like that) security bulletins to fit an agenda, then sure A is mostly certainly as bad as B.

Originally Posted by jaycee1980

Nothing to do with PHP, just bad programming. I have written plenty of PHP code which has withstood allsorts of attack vectors.

Great stuff, I retired a PHP4 application after 20 years just some months ago and it was never attacked. The code? It was utter trash. Did a vulnerability scan on it some years ago before rewriting it and it literally had dozens of 9+ vulnerabilities. On every part. Oh, and it had a phpmyadmin version from 1999 installed next to it.

Not getting something owned these days is not just a matter of skill, it’s also a lot of luck. But hey good for your ego if you think it was mostly down to skill.