/baphomet/ - Deepweb, Hax, Casual Chat, Raids

The SDcard reader was incased in a plastic case & a strap making it physically impossible to put in the usbrubberducky casing. Just to indicate that I didn't put it in the usbrubberducky, then insert that in my computer.

>>108447

i wouldn't trust anything from hak5 since they released the pineapple without ever auditing their own code. just my .02

anyone use these usbrubberduckys before? I ordered one because of job (needed hardware key logger but had larger budget). Ordered a handful of things.

also, i'm op. Small update. I pulled the system.log and pf logs and ran for entries akin to those that occurred after using the sd card in the sd card reader. They only occurred after the time of putting in the media…

Meaning, i felt i may have been being paranoid, so i checked the back logs to make sure it wasn't my system. It wasn't. I contacted hak5 but they haven't responded.

fucking a

>>108487

judging by those ip's, whose to say they didn't trust the wrong manufacturer? wouldn't be the first case of backdoored hardware being sold…

Interesting OP, have a bump.

Also why don't you just set up a teensy 2.0 to do this for you? Don't pay those 'le commericial h4x0rs :^)' any more money

I plugged the sdcard provided into a sdcard reader on another machine, and it mounted the boot/recovery partition and tried writing files to a trash directory…

"Sandbox: Finder(265) System Policy: deny(1) file-write-create /Volumes/Recovery HD/.Trashes/505"

Anyways, i retrieved the firmware and I'm loading it into ida pro.

What kind of laptop are you using?

Some of the messages you have posted suggest MacOS?

>>108636

All my messages should suggest Mac OS X.

That looks like an exploit for the HFS driver.

Try imaging the sdcard on an OpenBSD system.

Don't try to mount it, just read the raw blocks.

If the exploit didn't remove itself after hitting your Mac, congratulations, you've captured your first 0day.

The "full disclosure" mailing list will be interested.

>>108667

www lad, sounds good. lucky me has an openbsd desktop. so i'll dd that sd card from the raw node.

funny thing , i'm already a subscriber of that list.

A more likely possibility is an exploit for the Finder.

A kernel exploit should have been able to break out of the sandbox. This did not.

Mac OS X software is often distributed in *.dmg files. Those are HFS disk images. This hole is bigger than just sdcards.

Easy way to find if the exploit is in the filesystem on the sdcard: dd the image to a known-safe sdcard and insert that card into a Mac.

Even if the sdcard image comes back clean, don't give up. The sdcard or the reader could have a hidden area holding the exploit. Uncovering this will be harder and will require sacrificing a few more sandbox accounts for the cause. Post here and I'll help any way I can.

Did the sdcard come from hak5 or another source? I'm trying to determine if this was a general attack or targeted at hak5 customers.

>>108697

I dd the raw node while also logging dmesg output before & after plugin for comparison, and a copy of lsusb -vv output. I created offsite backups of this, and will be placing the image onto another sd card. Upon placing the cd card & reader into a openbsd box & a linux machine, nothing like on Mac OS X occurs.

I will post again when I have tried the dd image on another media.

The sd card came included in the rubber ducky box, and held what appeared to be the factor default "inject.bin" file of the rubber ducky to produce hello world output. Using the ducky decoder (ring, lol, get it?) I reversed that to source and it had an odd hex string that didn't appear to be part of the specifications of the ducky scripting language.

In anycase, made back ups and logs, with images and archives. When I am done piddling, i was upload the tarball to mega

>>108447

>hak5

>ever

anyways i'm interested in what you find, keep us posted

The files on the sdcard will have nothing to do with crafted HFS structures.

I'm not very familiar with Mac OS X. Does the Finder actually run from a binary named "Finder" or is it "Finder.app" or something?

Your sandbox may have caught a fake Finder attempting to write to the recovery area.

Repeated "media is not present" only on a Mac OS X host is highly suspicious and suggests the sdcard or reader has malicious firmware. This is a deep rabbit hole.

Quick update/bump, I take the weekends off from computer usage & hike, cause all work and no play make jack a dull boy.

I don't want to dash everyones hope, but i hate spreading disinformation. I read somewhere about time machine making an EFI binary on a fully encrypted disk when it can not get write access to a recovery partition.

That being said, I didn't have my encrypted back external disk ever plugged into the machine when using the USB rubber ducky. But like I said, don't want to sell hope about a wild 0day when there is none.

I'll archive everything UTC noon on monday, and upload. I created images of the partition tables too.

if you missed the implication (in root of encrypted drive):

> tmbootpicker.efi

"time machine boot picker EFI binary"

Even if the above is the case (not saying it is, haven't cross referenced time stamps); the outbound connection attempts are unexplained.

Time Machine should be under the sandbox. This leaves the attempted write to the recovery volume unexplained.

>tmbootpicker.efi

This could be malware attempting to hide in plain sight or exploit the Mac firmware in some way. That file name is probably magic if Time Machine uses it.

Can you get a clean Mac to produce a similar file? Does the hash from the clean Mac match the questionable file? Is an identical file present on a known-good Mac OS X install DVD?

>>108818

sorry, i'll not be able to continue as work is calling. I will upload all information today after scrubbing for dox details. I have not looked into the efi binary.

main files will be, partition table & dd image of sd card (with raw dd containing both).

>>108824

I don't have a Mac.

Does the dd image on a known-good sdcard cause odd behavior?

Analyzing the image is futile if it isn't infectious.

>>108843

whelp this is weird as shit…

I was beginning to think that it was me being paranoid because I couldn't reproduce the issue but I'm still way off in left field.

I started to think that the first time it happened I may have plugged the rubber ducky in itself prior to the factory shipped sd card which may have produced the dmesg output.

The thing is, accessing dmesg from the CLI does not produce timestamps, which is very misleading.

I was about to write it off, saying that more than likely it was something todo with my time machine back up schedule in combination with my virtual machine software.

But here is the kicker, every now and then, when placing the rubber ducky into my machine, it executes the "injection bin" (file containing the keystrokes/pay load). But I have changed some things since then.

First, I reflashed the firmware on the rubber ducky, due to needing it to function as a USB mass storage device as well as the HID software keyboard.

Now, when i plug it into a windows machine (virtualised), it runs the inject.bin payload then loads the USB mass storage (and the red lights stop and go green when no longer running the payload). But, every now and then, when placing directly into the Mac, it'll run the payload. THEN,

instead of the red lights going away, the USB mass storage never shows up. The lights flicker green to red, and my log is filled with attempts to access my recovery partition.

Which is denied by the sandbox because the user account has no administrative privileges and can't access dmesg (much along anything else)..

cont.

>>108862

IOUSBMassStorageDriver::AbortCurrentSCSITask - fConsecutiveResetCount = 1

disk4s1: device/channel is not attached.

USBMSC Identifier (non-unique): 0x3eb 0x2422 0x100

IOUSBMassStorageDriver::AbortCurrentSCSITask - fConsecutiveResetCount = 1

disk4s1: device/channel is not attached.

hfs: mounted Recovery HD on device disk0s3

hfs: unmount initiated on Recovery HD on device disk0s3

hfs: mounted Boot OS X on device disk2s3

hfs: unmount initiated on Boot OS X on device disk2s3

>"hfs:" lines repeating ad infinity

>>108863

>>108863

then, after those error messages repeat a few dozen times, this:

andbox: Finder(351) System Policy: deny(1) file-write-create /Volumes/Recovery HD/.Trashes/507

which repeats after each:

hfs: unmount initiated on Recovery HD on device disk0s3

hfs: mounted Boot OS X on device disk2s3

hfs: unmount initiated on Boot OS X on device disk2s3

hfs: mounted Recovery HD on device disk0s3

HAHA THEN THESE

Sandbox: storeaccountd(420) deny(1) file-write-create /Users/macosx/Library/Caches/com.apple.safari

Sandbox: storeaccountd(420) deny(1) file-write-create /Users/macosx/Library/Caches/com.apple.safari

Stealth Mode connection attempt to UDP 10.5.0.11:61695 from 4.2.2.2:53

Stealth Mode connection attempt to UDP 10.5.0.11:62739 from 4.2.2.2:53

but they use to be IPs to servers which i blocked in pf.

>>108865

>>108865

whelp a new IP showed up now that I ran that, again.

>199.77.32.152

>>108843

>>108818

>>108741

>>108736

>>108697

>>108667

brews,

I don't think it is all in my head. Check it, the rubber ducky started doing that shit again, like i detailed above. SOOOO, I used old admin account to reset all passwords & remove user account. THEN, created unpriv user and rebooted. Then, created new admin account with old admin rights, removed old admin. Reset all permissions, everywhere to non execute. Then set it to nobody & no group.

But, here's the kicker. It lagged at boot and did a grey screen flash. Then when logging in under old account, it "reinitialised" as if never logged in before. That all seems sloppy, so could be FUD.

But, this is what is making me believe the coolaid.

After first boot (rebooting after the logs posted above):

ignored is_io_service_close(0x1000003b2,IOHIDParamUserClient)

Sandbox: coreduetd(80) deny(1) file-read-metadata /usr/libexec

Sandbox: coreduetd(80) deny(1) file-read-metadata /usr/libexec

Sandbox: airportd(69) deny(1) file-read-metadata /usr

Sandbox: iconservicesagen(339) deny(1) file-write-mode /private/var/folders/7t/pdc5pfms0f3gtggy1g_h08440000gv/C/com.apple.iconservices

Sandbox: storeaccountd(370) deny(1) file-write-create /Users/apple/Library/Caches/com.apple.spotlight

Sandbox: storeaccountd(370) deny(1) file-write-create /Users/apple/Library/Caches/com.apple.spotlight

Sandbox: softwareupdated(388) deny(1) system-fsctl 682f

Sophos Anti-Virus on-access kext activated

then, after rebooting a second time, from that time:

ignored is_io_service_close(0x1000003d1,IOHIDParamUserClient)

Sandbox: coreduetd(81) deny(1) file-read-metadata /usr/libexec

Sandbox: storeaccountd(341) deny(1) file-write-create /Users/apple/Library/Caches/com.apple.spotlight

Sandbox: storeaccountd(341) deny(1) file-write-create /Users/apple/Library/Caches/com.apple.spotlight

Sandbox: airportd(70) deny(1) file-read-metadata /usr

Sandbox: CalendarAgent(313) allow(0) mach-register com.apple.CalendarStore.lock.init

Sandbox: softwareupdated(368) deny(1) system-fsctl 682f

Sophos Anti-Virus on-access kext activated

Sandbox: systemsoundserve(282) deny(1) file-read-metadata /private/var/root

and lastly, booth of those dmesgs produce this at the start:

e-flags /private/var/run/diagnosticd/dyld_shared_cache_x86_64.map

Sandbox: launchd(1) System Policy: deny(1) file-write-unlink /private/var/run/diagnosticd/dyld_shared_cache_x86_64.map

Sandbox: launchd(1) System Policy: deny(1) file-write-flags /private/var/run/dyld_shared_cache_x86_64

Sandbox: launchd(1) System Policy: deny(1) file-write-unlink /private/var/run/dyld_shared_cache_x86_64

Sandbox: launchd(1) System Policy: deny(1) file-write-flags /private/var/run/dyld_shared_cache_x86_64.map

Sandbox: launchd(1) System Policy: deny(1) file-write-unlink /private/var/run/dyld_shared_cache_x86_64.map

Sandbox: launchd(1) System Policy: deny(1) file-write-flags /private/var/run/diagnosticd/dyld_shared_cache_i386

Sandbox: launchd(1) System Policy: deny(1) file-write-unlink /private/var/run/diagnosticd/dyld_shared_cache_i386

Sandbox: launchd(1) System Policy: deny(1) file-write-flags /private/var/run/diagnosticd/dyld_shared_cache_i386.map

Sandbox: launchd(1) System Policy: deny(1) file-write-unlink /private/var/run/diagnosticd/dyld_shared_cache_i386.map

Sandbox: launchd(1) System Policy: deny(1) file-write-flags /private/var/run/diagnosticd/dyld_shared_cache_x86_64

Sandbox: launchd(1) System Policy: deny(1) file-write-unlink /private/var/run/diagnosticd/dyld_shared_cache_x86_64

Sandbox: launchd(1) System Policy: deny(1) file-write-flags /private/var/run/diagnosticd/dyld_shared_cache_x86_64.map

Sandbox: launchd(1) System Policy: deny(1) file-write-unlink /private/var/run/diagnosticd/dyld_shared_cache_x86_64.map

plus, on the third reboot, a new IP connection:

>199.77.32.45

man fuck this, i'm restoring from backup. If i catch a single wiff of anything, restoring from disc. i've half a mind to say fuck apple and reinstall openbsd on this fucking laptop. lets see them get a local code execution exploit even with hardware on that, fgts.

luckily, there is no way this had any escalation of privileges or i wouldn't have known.

I just got BTFO.

> boot recovery

> time machine

> erases drive

> crash & kernel panic

> no OS

luckly, i backed up all data prior to time machine restore. fuck.

if it's conciliation, hak5 never returned any of the four emails i sent them nor do the have a support email address either. FUCK HAK5, FUCK MAC OS X.

FUCK THE POLICE

THE

POLICE

>>108887

same thing i said earlier. shit company if there ever was one. it being mcgrew's faggot ass that dropped 0day on them makes them even lamer.

Are you still willing to narrow down and isolate this exploit?

Does the dd image on a known-good sdcard cause a Mac to act suspiciously?

I'll still help if you're still willing to pursue this.

Get back at whoever blew up your Mac by exposing the exploit they used.

>>108887

>>108889

you two are correct, I was wrong.

>>108891

I may consider it, but i am truly busy else where.

The time machine back up from an off site encrypted drive was successful for 01 Feb 16, but failed trying for the day before.

I am 95% sure that it didn't get plugged in until 5 to 7 days after that date.

In any case, I have two main lines of thought here. One, i plugged in the rubber ducky at some point prior to noticing the breach or two, it was the SD card.

With out the time needed to cross reference all the logs, images, & file timestamps, i will not be able to know for sure.

Odd question, but is there anyway a segment of code could survive a firmware flash on an EPROM device?

>>108900

>i plugged in the rubber ducky at some point

The rubber ducky should not have done that. You had not yet loaded a payload.

>anyway a segment of code could survive a firmware flash on an EPROM device?

Depends on how the device firmware is flashed. If device firmware flashes itself, most definitely yes.

Suspect hak5 compromised. Evidence so far suggests mid-tier state actor or top-tier criminals. (Hi Ivan!)

>>108900

any chance of those uploads ever happening? there are a *number* of people who would absolutely love to prove that hak5 is fucking over it's customers yet again…

>>108925

this nigga had autorun enabled huh

make a disk image of the sd card with dd so we can inspect it, OP

extraordinary claims require extraordinary evidence

Bump

>>109430

after speaking with psi, I was mistaken. The virtualisation software i was using while testing produced this behaviour; leading to this misconception (it seemed even more authentic, when log messages from black listed IPs occurred at the same time).

Due to a lack of time on my part & apples shitty modifications to dmesg, combined with the timing for the black listed IPs & VM errors, an incorrect picture was painted.

Basically, turn on VM to test rubber ducky.

>VM software tells debian to auto mount host drives

>permissions on host say no

>VM software has debian in loop

mac logs recovery partition failed mounts

>notice after plugging in rubber ducky

>various client software & VM request updates

>IP block list for telemetry & updates denies

combine with logs from above

>paranoia with lack of time

this thread

Other than that, macs lack of verbosity in logs also lead to this misconception.

Final note, to the anon that said but the china hardware chip, instead of rubber ducky; then due scripts in C++, good on you! That's what i should have done in the first place.

I have no idea how to help but DAMN I want one of these. Does anyone have some useful scripts for them? One of the things I want to do is retrieve my friend's computer password and delete… stuff.