Lua Website links hacked

243 views
Skip to first unread message

Adam P

unread,
Dec 21, 2024, 4:00:43 PM12/21/24
to lua-l
The website page


has bad links. The pdf links we hacked. These should be removed for security reasons. Thanks.

Lars Müller

unread,
Dec 21, 2024, 5:07:32 PM12/21/24
to lu...@googlegroups.com, thomas...@gmail.com

That page is (part of) a wiki: Anyone can ideally edit it. There should be no need to write an email to this list, just edit it yourself if you notice something like this. In this case, I would have edited the links to good archive.org links:

- https://web.archive.org/web/20230308221513/http://thomaslauer.com/download/luarefv51.pdf
- https://web.archive.org/web/20230403194354/http://thomaslauer.com/download/luarefv51single.pdf
- https://web.archive.org/web/20230308221513/http://thomaslauer.com/download/luarefv51.zip

But unfortunately it seems the wiki has a bug so I can't:

http://lua-users.org/cgi-bin/wiki.pl

Software error:

Could not get editing lock at (eval 35) line 764.

For help, please send mail to this site's webmaster, giving this error message and the time and date of the error.

(Time and date: 22:01 at Saturday, 21 December 2024 UTC, but unfortunately I'm not sure who to contact; who is the webmaster, and where do I get an e-mail address? Maybe someone else on this list has an idea?)

    
I've also CC'd Thomas Lauer using the e-mail address given on the page. He might be unaware that thomaslauer.com apparently expired (?) and belongs to someone else now.

In any case note that lua-users.org is not hosted by the Lua authors or Tecgraf, see http://lua-users.org/MiniCharter.html.

- Lars
--
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lua-l/59607497-148e-44eb-8d2c-8ca1990b2ba1n%40googlegroups.com.

Berwyn Hoyt

unread,
Dec 22, 2024, 12:29:28 AM12/22/24
to lu...@googlegroups.com
Hi Lars,

You are correct: the wiki has been locked since before July (so the pdf attackers must have another way in!)
  • John Belmonte said on Oct 15 that he unlocked it, but his unlocking didn't actually work.
  • Rodion offered on Oct 18 to attempt to migrate the wiki to a github pages solution without the spam issues. But not many responded, so I'm not sure whether he began to work on this.
Rodion, are you still listening in? I'm still behind it, but I think the change would want more than me to be in favour, lest your work be ignored.

Cheers,
Berwyn

Родион Горковенко

unread,
Dec 23, 2024, 3:38:09 AM12/23/24
to lu...@googlegroups.com
Berwyn, Hi!

I'm still tuned-in, though I think I'm confused whether some actions from John were expected or page sources are already accessible somewhere?

(to add to confusion I had difficulty remembering what exactly I had on mind but your hint and message history should help)

Lars Müller

unread,
Dec 23, 2024, 10:41:34 AM12/23/24
to lu...@googlegroups.com

Thanks Berwyn for clearing that up. The attackers didn't edit any links, they just picked up Thomas Lauer's personal domain (thomaslauer.com) after it expired it seems.

I might also be interested in a GitHub pages solution. Are the wiki sources accessible anywhere?

Happy holidays,
Lars

Berwyn Hoyt

unread,
Dec 27, 2024, 1:46:17 AM12/27/24
to lua-l
John Belmont, are you still around?

I think you are the only one who can answer Lars' request to release the sources for this project. Just to reiterate, you asked for help on Oct 15, and it was offered on Oct 18 and Dec 23. Lars (below) and I have asked for the wiki sources to be released for this purpose.

Are you kindly able to provide the sources, and are you also the person authorised to switch http://lua-user.org/wiki to point to github pages once the migration is complete?

Many thanks,
Berwyn


Philippe Verdy

unread,
Jan 3, 2025, 1:35:10 AMJan 3
to lu...@googlegroups.com
That's the problem when allowing external links, even if they are safe one time, we still need a way to block these dead links if the target content changes for any reason (here an expired domain that has then been cybersquatted and used to "promote" junk (here some Asian gambling site) or perform security attacks (through various site redirects and scripts that are actively testing visitor's browser capabilities or attempting to harvest known bugs or issues, and get as much information about the visitor using many user profilers from advertizing companies, or various online tools in order to steal personal data or perform "social" engineering).

Ideally, for PDFs, they should be hosted only on stable and maintained hosting sites with active administration and actively maintained security tools, procedures and charters (e.g. Wikimedia Commons if they are eligible by an open/free licence, or possibly wellknown collaboration sites like Github or Reddit), not on personal sites; so external file hosting sites should be whitelisted rather than blacklisted, and an administrative procedure should be used to add some other site and assess their security and maintenance, or if a file is safe, it could be hosted directly in a local cache (the external link would then be adminsitratively edited to go to the hosted copy, with enough data about its original source).

And in all cases, external links should always use secure HTTP protocol, and should only use canonical URLs without redirects (so no "short link" unless they redirect to exactly the same domain and not even to any other subdomain of the same base domain, to avoid other external scripts and trackers, especially on all social networks) and these canonical final URLs must be stable and not unique by visitor or browser session, and independant also from the device, OS or browser used or the country or IP of the visitor. They should be no additional popups, and privacy should be respected. We shoul not need to get the target file after silently contacting tons of other tracking sites to get random cookies from many third-party domains (the file hosting site may still be use its own local performance metrics, but anonymized) .

Reply all
Reply to author
Forward
0 new messages