Jump to content

SUGGESTION: prevent script attacks to caches


bevema

Recommended Posts

By chance it came to my attention in the last hour:

Many or all caches from a German geocacher are so-to-say under attack from log scripts.

Countless found-logs have been sent to these caches with identical text from each of the malicious (quite young and basic member) accounts, maybe also performing a huge traffic of sent-out watchlist-notifications.

 

I'm not sure wether this is a once-in-a-lifetime incident, but my former business experience in computer virus-research lets me fear it's the other way round. Have now the script-kiddies reached geocaching, too ;) ?

 

Behaviour detection might be the only possibility to catch such culprits:

-) block too fast logs from one account to one cache (as scripting tools are per se against the ToU)

-) block more than two found logs from one account to one cache

-) block all kinds of logs with identical content from one account to one cache

 

But I fear that the only person getting problems will be the cache owner, for not maintaining the caches correctly by deleting the malign postings immediately. A script running from Friday evening 'til Monday morning may wreak havoc all the concerned caches.

Link to comment

If I'm an incredibly fast typer (I'm not, but most kids are), I'd get cut off?

 

There's still a few caches that allow multiple finds. How would you fix this?

 

Maybe sad but true, around here, if someone does more than one cache in the day, all logs are pretty-much cut-and-paste. Most power trails are identical content. How would you fix this?

Link to comment

@fast typing: why not just copy & paste ;) ?

 

@multiple founds: well in the perfect world there would be a checkbox for cacheowners "allow multiple finds"

 

@almost identical logs on PTs: yes, indeed, but not identical logs to the same cache ;)

 

BTW, if it might speed things up, I can also add the number of my appeal, for lackeys and reviewers to get faster access to it:

 

Request {489663}

Link to comment

Log-bots are nothing new. Groundspeak will respond by banning the account and likely take other action like blocking IP addresses. Simply trying to identify what is a script and blocking that is much more difficult, especially since some cachers legitimately use tools like GSAK to log caches.

 

I realize that if your cache is being attacked it can be annoying, as would getting notification if the cache being attacked in on your watchlist. The cache owner is permitted (and even encouraged) to delete bogus logs. It can be annoying when a bot is continually re-logging a cache. In the past, I have seen Groundspeak remove the logs once the account or accounts of the spammer are banned. Sometimes this has to wait till the work week.

Edited by tozainamboku
Link to comment

 

Behaviour detection might be the only possibility to catch such culprits:

-) block too fast logs from one account to one cache (as scripting tools are per se against the ToU)

-) block more than two found logs from one account to one cache

-) block all kinds of logs with identical content from one account to one cache

 

 

While I agree in principle with what you're suggesting, I don't think it's that easy to implement.

 

Fast logging can be achieved using the "Field Notes" feature which GS has created, also many partner API apps (e.g. GSAK) have a bulk logging feature.

 

There are lots of caches out there which specifically allow multiple logs, though your later suggestion of allowing CO's to chose whether multiple logs should be allowed is a good one, if GS would implement it.

 

Blocking identical logs to a single cache would only deter the script kiddy long enough to change the script to add a unique piece of text to every log (e.g. date & timestamp each one).

 

I think implementing something that works effectively without blocking legitimate cachers would require more work than it's worth, and I'd rather they spent the development time on other features.

 

I think at the moment this is still a small enough problem to be managed by reporting cachers who are abusing the system and getting their account deleted.

Link to comment

-) block all kinds of logs with identical content from one account to one cache

 

Blocking identical logs to a single cache would only deter the script kiddy long enough to change the script to add a unique piece of text to every log (e.g. date & timestamp each one).

 

...

I think at the moment this is still a small enough problem to be managed by reporting cachers who are abusing the system and getting their account deleted.

 

Yep, it has been the same way with computerviruses in the 90's. First normal code in them, then a bunch of different commands performing the same action (and in each strain another command is used), then additional useless codeparts with various length (like push AX, pop AX). This brought a huge change in the antivirus-programs at first by implementing massive pattern recognition capabilities. When scripting viruses popped up, the whole scene changed to behaviour detection in a sandbox.

 

And I agree, as long as there are only few culprits among the cachers, they can be sorted out by hand ;) .

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...