88  dP  dP"Yb   dP"Yb  88        88  dP   .d 8888b.  888888    88  dP   .d 88   88 88""Yb
88odP  dP   Yb dP   Yb 88        88odP  .d88  8I  Yb 88oo."    88odP  .d88 88   88 88__dP
88"Yb  Yb   dP Yb   dP 88  .o    88"Yb    88  8I  dY    `8b    88"Yb    88 Y8   8P 88""Yb
88  Yb  YbodP   YbodP  88ood8    88  Yb   88 8888Y"  8888P'    88  Yb   88 `YbodP' 88oodP

1f ur n0t a k00l k1d pls g0 aw4y fr0m the k1ub...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	


back



           Press release: 13th November, 2017
           ==================================
by klubsman gaucho, revised and upload by klubsman shamoanjac

  It has come to our attention that our website has been defaced.
The story began a few days ago, when a user by the name of ``jman''
got into our internal communication channel. While it was a minor
security breach, the effect was minimal, and it was decided that
he'd be in with our group.
  Then November 12th rolled around, and it was discussed whether
PHP should be enabled in the main webpage. It was decided that it
should, and the server administrator enabled it. User jman then
asked if he could edit the main page, as he told the online members
that it was his idea to make some scripts.
  It was then, after around one hour or so, that it was revealed to
be a ruse, and that jman was actually against the koolkidsklub.tech
website and its community. He got access to the data-www group and
defaced the website, embedding videos in bad taste. He also copied
IP logs of members of the community and released them, to no apparent
harm.
  It should be noted that, even if technically unsophisticated, the
attack still managed to cripple our website and community for a few
hours. As it is spoken in hacker parlance, PEBKAC. The user element
of a computer system is the one that is more prone to failures, and
still in the 21st century it remains so and is expected to be for
all considerable future.


Extent of the damage
~~~~~~~~~~~~~~~~~~~~
  No real harm was done, other than IP addresses and public keys for
connecting. Other than knowing who comes from what country nothing 
much could be done, unless members of the community use static IP 
addresses. Git server is running, IRC was taken down but is now 
functioning normally. The webpage was rolled back, but unfortunately
no backups were done for the latest iteration of it, so it was rolled
back to its previous version

Measures to avoid it happening again
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Measures were taken to avoid the problem happening again. First of
all, the permissions to the mainframe were fixed, so if they are not
working correctly contact our server administrator for fixing.
  Secondly, the perpetrator of this attack has been banished from our
community, due to committing acts against an unspoken but trivial code
of conduct that we use.

For future consideration
~~~~~~~~~~~~~~~~~~~~~~~~
  It should be decided whether no users other than the administrator
should touch the main webpage (data-www group). If you want to make
changes to the main site, send him the modified files for him to
consider, and if they are not website-breaking, he'll add them.
  Another point of consideration is having tests for newcomers. The 
test should have both a technical component and a psychological
component. The technical one should be to test whether the user is
actually a technology-oriented person or not. The prospective member
should present us with an example of code to which he or she has
contributed significantly, or demonstrate significant knowledge of
computer science or maths. The contributions don't have to be
impressive, but they have to be material.
  As for the psychological part, the user should either have a
current member that vows for him or her, or be proven to actually
desire to contribute to the community. For this, the user shall
have git access first and foremost, and until he has contributed
to projects that act for the greater interests of the community
he should not be allowed to connect via ssh to the mainframe.
The user should also have to wait at least two months time at a
minimum, so even if the user contributes impressively he should
not be immediately allowed to execute programs in the main machine.
  With these mechanisms in place, social engineering attacks should
be expected to be reduced significantly, so these options should be considered.