Noch immer SQL-Injection im BigBug-Shop

Montag, 9. April 2012, 13:48 Uhr |  Autor:

Aus der bigware.sql der Installation des Shops:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#
# Tabellenstruktur für Tabelle `attendees`
#
 
DROP TABLE IF EXISTS `attendees`;
CREATE TABLE `attendees` (
  `attendees_id` INT(11) NOT NULL AUTO_INCREMENT,
  `attendees_gender` CHAR(1) NOT NULL DEFAULT '',
  `attendees_firstname` VARCHAR(32) NOT NULL DEFAULT '',
  `attendees_lastname` VARCHAR(32) NOT NULL DEFAULT '',
  `attendees_dob` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `attendees_email_address` VARCHAR(96) NOT NULL DEFAULT '',
  `attendees_default_address_id` INT(11) NOT NULL DEFAULT '0',
  `attendees_telephone` VARCHAR(32) NOT NULL DEFAULT '',
  `attendees_fax` VARCHAR(32) DEFAULT NULL,
  `attendees_password` VARCHAR(40) NOT NULL DEFAULT '',
  `attendees_password_uncript` VARCHAR(40) NOT NULL DEFAULT '',
  `attendees_newsletter` CHAR(1) DEFAULT NULL,
  `attendees_invoice` tinyint(4) NOT NULL DEFAULT '0',
  `guest_flag` CHAR(1) DEFAULT '0',
  `attendees_group_id` INT(11) NOT NULL DEFAULT '0',
  `member_level` INT(5) NOT NULL DEFAULT '0',
  PRIMARY KEY  (`attendees_id`)
) AUTO_INCREMENT=24 ;

Man beachte Zeile 17.

Mit “uncript” ist natürlich uncrypt gemeint und genau dies findet man auch in der Datenbank vom BigBug-Shop — das Passwort im Klartext. Warum macht man so etwas? Weil man dumm ist oder weil man sehr einfach die Passworte seiner Kunden abgreifen will, um in deren Webmail-, PayPal- oder Facebook-Account zu stöbern?


Eine einfache Suche fördert angeblich tausende von BigBug-Shops zutage. Nach 100 Suchmaschinen-Ergebnissen, die auch 100 mal eine SQL-Injection ergab, brach ich die Suche ab. Alle 100 Shops sind in der Kategorie “Schrott” einzusortieren, weshalb man nur wenige Kundendaten finden wird. Für einen Angreifer ist aber die folgende Tabelle bzw. die Daten darin interessant:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 
#  Tabellenstruktur für Tabelle `update_ftp_zugang`
# 
 
DROP TABLE IF EXISTS `update_ftp_zugang`;
CREATE TABLE `update_ftp_zugang` (
  `update_id` tinyint(20) NOT NULL DEFAULT '1',
  `ftp_server` VARCHAR(200) NOT NULL DEFAULT '',
  `ftp_user_name` VARCHAR(200) NOT NULL DEFAULT '',
  `ftp_user_pass` VARCHAR(200) NOT NULL DEFAULT '',
  `source_file` VARCHAR(200) NOT NULL DEFAULT '/',
  `ftp_server2` VARCHAR(200) DEFAULT NULL,
  `ftp_user_name2` VARCHAR(200) DEFAULT NULL,
  `ftp_user_pass2` VARCHAR(200) DEFAULT NULL,
  `source_file2` VARCHAR(200) NOT NULL DEFAULT '/',
  `config` CHAR(2) NOT NULL DEFAULT '0',
  PRIMARY KEY  (`update_id`)
) ;

Kriminelle die ihre Malware unters Volk bringen wollen, brauchen schließlich frische Domains.


Weshalb ich mir die SQL-Injection im BigBug-Shop noch einmal angesehen habe:
Bigwareshop: Sicherheitslücken weiter vorhanden” (sicherheit-online.org)

Die Entwickler des Shopsystems “Bigwareshop” ignorieren seit Monaten höchst kritische Sicherheitslücken (SQLi, bSQLi, XSS & Co.) in deren Shopsoftware.

Tags »   

Trackback: Trackback-URL | Feed zum Beitrag: RSS 2.0
Thema: Sicherheit, SQLi

Kommentare und Pings sind geschlossen.