Fuzzing IEC 61850 protocol - CVE-2018-18957

Hi Internet,

Summary: While fuzzing(I've used AFL for this), a stack based buffer overflow was found in libIEC61850 (the open-source library for the IEC 61850 protocols) in prepareGooseBuffer in goose/goose_publisher.c and /linux/ethernet_linux.c

Steps to reproduce:

$ ./goose_publisher_example crash_goosecr_stack_smash_overflow_aaaaaaaaa
Using interface crash_goosecr_stack_smash_overflow_aaaaaaaaa
*** stack smashing detected ***:  terminated
Aborted
$

File: crash_goosecr_stack_smash_overflow_aaaaaaaaa
[This file will be expired after 30 days.]

Debugging:

(gdb) run crash_goosecr_stack_smash_overflow_aaaaaaaaa
Starting program:
/home/input0/Desktop/libiec61850/examples/goose_publisher/goose_publisher_example
crash_goosecr_stack_smash_overflow_aaaaaaaaa
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Using interface crash_goosecr_stack_smash_overflow_aaaaaaaaa
*** stack smashing detected ***:  terminated

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@...ry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51    ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@...ry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff7805801 in __GI_abort () at abort.c:79
#2  0x00007ffff784e897 in __libc_message (action=action@...ry=do_abort,
fmt=fmt@...ry=0x7ffff797b988 "*** %s ***: %s terminated\n")
    at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007ffff78f9cd1 in __GI___fortify_fail_abort
(need_backtrace=need_backtrace@...ry=false,
    msg=msg@...ry=0x7ffff797b966 "stack smashing detected") at
fortify_fail.c:33
#4  0x00007ffff78f9c92 in __stack_chk_fail () at stack_chk_fail.c:29
#5  0x000055555555a211 in Ethernet_getInterfaceMACAddress
(interfaceId=0x7fffffffdeee "crash_goosecr_stack_smash_overflow_aaaaaaaaa",
    addr=0x7fffffffd91c "k_smas\377\377") at
hal/ethernet/linux/ethernet_linux.c:170
#6  0x00005555555594ee in prepareGooseBuffer (self=0x5555557637d0,
parameters=0x7fffffffd9ac,
    interfaceID=0x7fffffffdeee
"crash_goosecr_stack_smash_overflow_aaaaaaaaa") at
src/goose/goose_publisher.c:168
#7  0x0000555555559293 in GoosePublisher_create (parameters=0x7fffffffd9ac,
    interfaceID=0x7fffffffdeee
"crash_goosecr_stack_smash_overflow_aaaaaaaaa") at
src/goose/goose_publisher.c:72
#8  0x0000555555555387 in main (argc=2, argv=0x7fffffffdaa8) at
goose_publisher_example.c:52
(gdb) i r
rax            0x0    0
rbx            0x7fffffffd6b0    140737488344752
rcx            0x7ffff7803e97    140737345765015
rdx            0x0    0
rsi            0x7fffffffd410    140737488344080
rdi            0x2    2
rbp            0x7fffffffd840    0x7fffffffd840
rsp            0x7fffffffd410    0x7fffffffd410
r8             0x0    0
r9             0x7fffffffd410    140737488344080
r10            0x8    8
r11            0x246    582
r12            0x7fffffffd6b0    140737488344752
r13            0x1000    4096
r14            0x0    0
r15            0x30    48
rip            0x7ffff7803e97    0x7ffff7803e97 <__gi_raise>
eflags         0x246    [ PF ZF IF ]
cs             0x33    51
ss             0x2b    43
ds             0x0    0
es             0x0    0
fs             0x0    0
gs             0x0    0
(gdb)

SRC:
Snip : src/goose/goose_publisher.c

{
    GoosePublisher self = (GoosePublisher) GLOBAL_CALLOC(1, sizeof(struct sGoosePublisher));
    prepareGooseBuffer(self, parameters, interfaceID);
    self->timestamp = MmsValue_newUtcTimeByMsTime(Hal_getTimeInMs());
    GoosePublisher_reset(self);
    return self;
}

Snip: src/goose/goose_publisher.c

    if (interfaceID != NULL)
        Ethernet_getInterfaceMACAddress(interfaceID, srcAddr);
    else
Ethernet_getInterfaceMACAddress(CONFIG_ETHERNET_INTERFACE_ID, srcAddr);

Snip: /linux/ethernet_linux.c

strcpy(buffer.ifr_name, interfaceId);

Later CVE-2018-18957 was assigned to this issue, Read this on oss-security.

Thank you
Dhiraj

Read More

Porting CVE-2018-8120 to an MSF module

Hi Internet,

#Shortpost
I have added the support of CVE-2018-8120 to MSF module, before porting this to MSF I read through the analysis of the issue.

After reading the blog post of xiaodaozhi I understood CVE-2018-8120 happens because of a null pointer dereference in the win32k kernel module at start this would lead to BSOD in vulnerable systems, however the exploit code was written in such a fashion that would override the function pointer which is present in kernel mode that achieves escalation of privilege to the remote or your local system.

It took me a while to port this to an MSF module also I would like to thank MSF team for there review's done during that time, at last this was successfully ported and landed!

The path for this module will be `exploit/windows/local/ms18_8120_win32k_privsec.rb` view this in action. (Sweeeeeeet!)

 

This module was tested against windows 7 x64 and x86 based systems and windows server 2008 R2 x64. However this vulnerability impacts following software versions or editions which are affected.

Reference: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8120

Thank you
Dhiraj

Read More

Telegram anonymity fails in desktop - CVE-2018-17780

Hi Internet,

Summary: Strangely tdesktop 1.3.14 and Telegram for windows (3.3.0.0 WP8.1) leaks end user private and public IP address while making calls. This bug was awarded €2000 by Telegram security team. (Sweeet..)

Img Src: https://telegram.org/img/tl_card_synchronize.gif

Telegram is supposedly a secure messaging application, but it forces clients to only use P2P connection while initiating a call, however this setting can also be changed from "Settings > Privacy and security > Calls > peer-to-peer" to other available options. The tdesktop and telegram for windows breaks this trust by leaking public/private IP address of end user and there was no such option available yet for setting "P2P > nobody" in tdesktop and telegram for windows.

PS: Even telegram for android will also leak your IP address if you have not set "Settings > Privacy and security > Calls > peer-to-peer > nobody" (But Peer-to-Peer settings for call option already exists in telegram for android).

To view this in action in tdesktop:

1. Open tdesktop,

2. Initiate a call to anyone,

3. You will notice the end user IP address is leaking.

 

Other scenario:

1. Open tdesktop in Ubuntu and login with user A

2. Open telegram in windows phone login with user B
3. Let user B initiate the call to user A
4. While user A access log will have public/private IP address of user B.

Not only the MTProto Mobile Protocol fails here in covering the IP address, rather such information can also be used for OSINT. This issue was fixed in 1.3.17 beta and v1.4.0 which have an option of setting your "P2P to Nobody/My contacts", Later CVE-2018-17780 was assign to this vulnerability.

Regards

Dhiraj

Read More

Telegram uses SOCKS5 to share user/creds

Hi Internet,

Summary: Telegram is supposedly is a secure messaging application but it uses SOCKS5 to transmit user credential's, neither traffic nor credentials are encrypted in the SOCKS5 protocol, but this is how the SOCKS protocol works (see https://tools.ietf.org/html/rfc1929), SOCKS5 carries passwords in cleartext. Telegram team is aware with this and says its working has intended.

Img Src: https://telegram.org/img/tl_card_open.gif

Product affected: tdesktop 1.3.16 alpha, Browser Info: Firefox 62.0 (64 bit), Tested on: Ubuntu 18.04 LTS x64

Steps to reproduce the issue:
1. Open tdesktop
2. Go to Settings > Advanced Settings > Connection type
3. Open "Proxy Settings" check "Use proxy"
4. Put some random Hostname, Port, Username and Password
5. tdesktop tries to connect it, while it connects click on that line which is made of 3 small spots (On right hand side)
6. Click share, the link gets copied.

Example Link: https://t.me/socks?server=inputzero.io&port=22&user=dhiraj&pass=MystrongPassw0rd 

The link which gets generated have the password in plaintext, SOCKS5 is a transport protocol and by itself it is not encrypted. Requests transmitting such  credentials in plain text are considered as a bad security practice.

However, the URL which gets generated via telegram is in HTTPS but, URI producers should not provide a URI that contains a username or password that is intended to be secret.  URIs are frequently displayed by browsers, stored in clear text bookmarks, and logged by user agent history and intermediary applications (proxies).

Read this on oss sec-lists. Later CVE-2018-17613 was assigned to this issue.

Regards

Dhiraj

Read More

The Secrets of Tez

Hi Internet,

Summary: The Google Pay (Tez) apps leaks end users email address, this issue was marked as WONTFIX by google.

Img Src: https://www.kisspng.com/png-tez-unified-payments-interface-google-apps-701156/preview.html

You might be aware of different technique for extracting email from LinkedIn similarly Tez app allow you to do so.

Steps to reproduce:
1. Open Tez,
2. Click on New,
3. You will see "Google Pay Connections",
4. Click on any one contact.
5. Their respective email address will be displayed.

In this case, I have never had email of "Ajay" I just had his contact saved. However in the similar fashion, I can view email address of  all the people in my contacts if they are on Tez. However it is not necessary to initiate the payment to get his/her email you can simply view it. (If user is already added in contact).

This issue was submitted to google but was marked WONTFIX, google says "Thanks for report! We think the issue might not be severe enough for us to track it as a security bug."

This is not such great bug but, such data can be use in OSINT to perform targeted attack on victim, hope you like the read.

Regards

Dhiraj

Read More