I found more usernames from real attacks while doing the research for https://www.acquia.com/blog/learning-hackers-week-after-drupal-sql-injec...

CommentFileSizeAuthor
#2 2364993_2.patch715 bytesscor
#1 2364993_1.patch731 bytesscor

Comments

scor’s picture

Status: Active » Needs review
StatusFileSize
new731 bytes
scor’s picture

StatusFileSize
new715 bytes

remove duplicate

pwolanin’s picture

Another possible username: "evex"

google for content with the title "evilevilingevils"

Bevan’s picture

I wonder if it is better store these lists of known usernames in a central database that Drupalgeddon can check remotely each time it executes. That way we can update them without requiring Drupalgeddon users update their Drupalgeddon code. Thoughts?

greggmarshall’s picture

Or a file? The only problem with a central database is proxies/firewalls, which can be a pain. It took an act of God to get some of our servers whitelisted to talk to drupal.org.

Alternatively a test to see if a later version is on drupal.org that reports can't check if it can't get to drupal.org? Could be patterned off the update manager code base.

Bevan’s picture

Checking for newer versions and telling the user they should update first is an excellent idea. A "central database" can be a file hosted anywhere on the web, as long as it is secure. Another factor is that with either of these approaches, we can never really get ahead of attackers; They can just change the signatures/names.

xurizaemon’s picture

That's a good idea, but +1 to just committing an additional entry for the new username in the interim.

We could easily do this, including a list of usernames in the download, and attempt to retrieve an updated copy from cgit.drupalcode.org (as we do in the suspicious files check already). That could be best of both worlds?

(Currently on mobile in a foreign lands.)

pembeci’s picture

3 more from me:
* ghst
* fasd
* 4dm1n

mikefyfer’s picture

I've come across a couple for 'Kkk1123'

greggmarshall’s picture

wc846 didn't get caught by the latest version as of 2 hours ago.

Bevan’s picture

It looks like attackers are now using random names. Keeping up with that is futile.

  • xurizaemon committed 68dbf9e on 7.x-1.x authored by scor
    Issue #2364993 by scor. Additional suspicious usernames.
    
SpenserJ’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.