The Infosec Thread: Yes, time to move off LastPass

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Infosec Thread: Yes, time to move off LastPass

Daman: Oct 28, 2011

don't joke about my insecurity

# ¿ Nov 20, 2015 20:03

Adbot: ADBOT LOVES YOU

# ¿ May 5, 2024 00:05

Daman: Oct 28, 2011

destroy a CSO's public image with a single blog post

# ¿ Dec 25, 2015 06:38

Daman: Oct 28, 2011

what's the problem with using AV on idiot computers to quell the flow of blackshades/darkcomet hackforums trojans they try to run. really. it's known that users can't be taught. extremely common trojans like these don't crypt their on disk persistence and they'd be swept up because of this.

it exposes them to LPE occasionally but it's not like malware authors are trying to implement that for specific AV vendors when UAC bypasses are way more public and easy.

yeah the point I've heard is "users will disable AV just to run it" but that's less the case if they remember uncle jimmy saying that's how they get you. even if they do, hey, maybe they don't next time after you DBAN their poo poo.

for idiots it seems like the cost is some LPE issues that nobody's going to give a gently caress about trying to exploit on random idiots while the gain is not being infected by xxxDarkSlayer666xxx but instead someone who put effort into crypting and keeping their botnet in memory w registry persistence. it's better for an idiot to be infected by a professional with a moneymaking agenda than a teenager who just wants to gently caress with ppl tbh

# ¿ May 2, 2016 14:24

Daman: Oct 28, 2011

OSI bean dip posted:

Yeah. Like just look at this list of really loving dumb vulnerabilities:

Remote debugger in TrendMicro left enabled
Comodo forwards to non-mutable API calls on the host
Comodo disables aspects of Chrome's sandbox
TrendMicro has RCE problems
Kaspersky buffer overflow

And these are just a random sampling of vulnerabilities from that Project Zero page.

Or you can see Tavis' Sophail presentation from 2011, which covers issues like XSS in the web protection module amongst others. This presentation is really what started the rabbit hole for him to go down on how loving dumb AV is designed.

And lastly we have a bug for Symantec coming our way.

taviso's AV bugs are cool but the "RCE" is rarely actually practical or part of the actual AV itself. nobody sane is recommending you install sophos or comodo. generally enterprise AV is all worthless, other protections should be in place on the enterprise network to protect endpoints on the network/permissions layer. enterprise is a totally separate theater.

bugs that result from scanning downloaded files (CHM, kaspersky upx bug, etc) are not practical for widespread random idiot infection. you're usually not going to be able to detect and filter for specific AV users and send AV-specific payloads(with the exception of a few awful solutions nobody normally recommends that add plugins+headers). throwing these payloads at everyone would result in your poo poo getting detected in a flash. even if you ignore this problem many bugs in this category that taviso finds are also not actually remotely exploitable on platforms with ASLR and DEP (Windows), as a separate bug to generate a good heap spray or memory exhaustion usually isn't there. all of this is _high effort_ for EK authors.

bugs that result from mitm are lol who the gently caress cares, you'd get about $5 for a full chain using that on the market. not practical to use to infect random idiots.

bugs in massive products like TM are funny, but who the gently caress is recommending TM to their family? generally people suggest (the user versions of) bitdefender, malwarebytes, eset, maybe kaspersky. the non-enterprise versions tend not to include misc garbage.

some of taviso's best bugs in poo poo that actually matters, like his ESET emulation RCE, are /still/ useless to infect rando users. code execution on modern windows was totally defeated by mitigations. his example ran on OSX because of this. people tried to make his exploit generic and failed because of this. even good security researchers will overstate the practicality of their bugs so that people will patch them.

imo y'all combine enterprise vs idiot user recommendations too much. misc_ransomeware_2000 / EK_hailsatan_666 are not really using AV vulns for RCE/LPE because they loving suck and there's easier ways. most even dip the out and stop execution if they can detect AV because it's _not worth the time_. if they don't target $CJ_AV_REC and $CJ_AV_REC stops them occasionally and saves time cleaning grandma's computer there's really no problem in having them.

"lol don't use AV just update" isn't helpful when there are offerings that don't include nodejs, a loving password manager with code execution, and ASLR defeats. these will stop a variety of infections and nobody is targeting grandma for an AV RCE that requires a mitm.

# ¿ May 2, 2016 17:44

Daman: Oct 28, 2011

Subjunctive posted:

The worst thing that Tavis has found is not a set of specific vulnerabilities. Rather, it's the iron-clad evidence of industry-wide, structural disregard for the security impact of these products on the end user.

like right, you say this, but for most products when the bug is found it has pretty fast response time to patch. I'd say ESET is a decent company and while their SDLC may not be the best (causing these bugs), major bugs are patched in under three days of report time. that's really all you can ask from a vendor, bugs will happen.

Most of the critical level bugs I find stay functional in major products for years. Is Microsoft ignoring security because they vastly improved font rendering times on older systems by rolling it into the kernel? There's still security issues with that code to this day. There's a variety of stories in the Windows kernel that are similar. OSX is no different, they have so much fluff running at a privileged level that there's a huge attack surface they've only tried to fix it by creating a walled garden with as many mitigations as possible for certain platforms running their kernel. Does this mean there's evidence of industry-wide disregard for the security impact of kernel components?

Grouping every AV vendor together without considering how mature their offering is and how much auditing has been done against their products is a mistake. You're not getting remote nodejs debug servers in MBAM, and they've got MBAE which actually has a decent library of mitigations implemented using EMET as a template (MBAE being much more friendly to end-users).

Obviously trying to enumerate which vendors provide a decent product by those "catches X%" statistics bullshit is a waste of time. They all do nearly the same thing, they should probably be enumerated by the number of IOCTLs their driver serves, the amount of extraneous bullshit they include (as negatives), and the number of transparent security audits that have been done in the last few versions (several have bug bounties).

OSI bean dip posted:

AV provides a false sense of security and the suggestion that you should rely on it should only come from AV vendors themselves, not from people who shouldn't peddle crap.

of course you shouldn't rely on any one thing. defense in depth is not just a meme. picking an AV that doesn't come with debug JS servers is a part of that. most _do_ stop lovely kiddy trojans. I'd question whether the knowledge of having an AV would affect what a dumb user does at all.

OSI bean dip posted:

The problem I have with your reply here is that what you're saying is that we should overlook these vulnerabilities because no known malware is currently exploiting any of this.

of course you should consider that these vulnerabilities existed (in the specific configurations and components they occurred in) when deciding if av_vendor is a good choice. history of security issues, vendor response to these, and recent additions/changes to the product should all be taken into consideration.. one vendor's actions don't indicate every product is going to contain ridiculous issues.

OSI bean dip posted:

signatures, heuristics, behavioural and everything else being done to detect malware just simply do not work.

At a chosen point of attacker effort, defense against them does not work. the point of a dumb user running an AV solution is to raise that level past "standard irc botnet." poo poo like this is detected just fine all the time.

OSI bean dip posted:

If I can pump out 200,000 unique copies of some ransomware in a single day that signatures cannot keep up with, heuristics cannot predict without causing havoc with other applications, and suspicious behaviour will never get wind of, how can I as an AV vendor expect to be able to keep up?

To me, it seems like the argument of "if one can get through, why bother at all?" You're still going to see attackers using simple malware spread, why not protect users who don't know any better from these? AV will totally trigger on old garbage trojans people cast a huge net out with. They'll still be affected by payloads that are well-written to avoid AV, but they would've been anyways?

# ¿ May 3, 2016 02:01

Daman: Oct 28, 2011

giving Tavis 20 minutes with a dot net GUI to Windows firewall will produce nothing bc that is all glasswire is.

Also it's a joke that anyone pays attention to alerts from that or littlesnitch, malware will be injecting itself into processes that normally do network poo poo anyways.

Daman fucked around with this message at 18:58 on Jun 6, 2016

# ¿ Jun 6, 2016 18:56

Daman: Oct 28, 2011

i mean expiration with no reason is still dumb. encourages dumb things

love2016
love20161
love20162
love20163

at least with reason you can be like "you shouldn't use any part of your old password, because someone might have found it out!"

Daman fucked around with this message at 18:54 on Aug 19, 2016

# ¿ Aug 19, 2016 18:50

Daman: Oct 28, 2011

did you tell them certs are a scam to take advantage of the corporate world and that they should just upgrade your salary instead

vocabulary quizzes and typing exploit into meatsplot isn't worth ur time as a skilled engineer

# ¿ Nov 6, 2016 15:05

Daman: Oct 28, 2011

Martytoof posted:

My boss asked me which US security conference I wanted to attend this year and I just told her I'm not stepping foot across that border right now.

There's got to be something worthwhile in Europe ~~or Canada~~ instead.

Canada actually has a bunch of the best conferences tbh, RECON cansecwest northsec etc

as a cheap floridian I'll probably never get the chance to hit these up

# ¿ Mar 15, 2017 02:13

Daman: Oct 28, 2011

in dns tunneling you'll usually get data via base32 encoding into subdomain requests. it'll look like random characters. does that exist here? would help a lot.

otherwise I'd try the obvious that I can't via a phone. use "042" as an xor otp, or "jml", or the last byte in one of those requests.

you might also consider the dot in responses as immutable, as a separator between a subdomain and a domain. if you know the domain, you could probably derive the xor key using the bytes after the dot. really the most unlikely solution.

Daman fucked around with this message at 07:09 on Jul 20, 2017

# ¿ Jul 20, 2017 07:05

Daman: Oct 28, 2011

Mopp posted:

Alright, I've tried XORing with obvious OTPs but with no success. All Google examples of DNS tunnel CTFs show only base64 encoding, nothing like this.

I've added a screenshot of Wireshark to show the tunneling in more detail.

oh cool that one looks way closer to some protocol stuck as hex text in that field

0x11 and 0x05 are probably key to understanding the stupid protocol. 0x11 is probably a length, the 0x05 is something else. if 0x11 is a length, then it could be a USHORT so the zero byte before or after it may be a part of it. my guess is the following zero byte is a part of the value, same with 0x05 if they're both little endian USHORT. I'd treat 0x05 as an xor otp or look for five things occurring.

one of the bytes that's zeroed there is probably the packet type or sequence number. probably the first one.

you're likely going to see initiating messages that look like that one, and then messages that follow will probably look very similar to eachother until some entire payload data is transferred. then there will likely be another message similar to the first somewhere.

you probably need to look at the entire big picture like that to understand it and guess at what to use to xor better.

also this is super similar to one of a consulting groups interview questions lol

check if domains reappear and payloads to the same domain look similar

Daman fucked around with this message at 06:30 on Jul 26, 2017

# ¿ Jul 26, 2017 06:24

Daman: Oct 28, 2011

lol that's pretty neat, drop that into a unicorn engine script. you can set up a stack and memory in unicorn, put the seed argument bytes into locations in the memory, and then set the arguments to that function(on the stack where you'll set rbp to point in this situation) to the memory address where you put each respective argument buffer. then tell unicorn to run it and you'll have the decrypted result in unicorns memory region, probably.

really cool challenge, what CTF is this for?

edit: or you could try to reverse and break the cipher but that's probably harder

I'm sorry my unicorn description sucked but it's like
* make a big memory buffer with unicorn api
* decide the stack is at like... 0x1000
* decide to put the bytes for each arg at like... 0x5000, 0x5200, 0x5400
* set ebp to 0x1000
* set esp to 0x1000-4
* other registers don't really matter
* set the memory at 0x1000+8 to the address of where the bytes for arg1 are, in this example it would be 0x5000
* same for 0x1000+12, and 0x1000+16...
* one arg is just a numerical seed, so 0x1000+whatever should be set to that
* run it up to the leave instruction and you'll probably have something decrypted at 0x5000ish

I might've switched up plus and minus up there, so beware. but you get the idea. btw it looks like it might be x86 that got decompiled by r2 as x86-64 so watch out for that

Daman fucked around with this message at 10:28 on Jul 28, 2017

# ¿ Jul 28, 2017 09:53

Daman: Oct 28, 2011

Mopp posted:

edit: the problem could be phrased like this: how can i execute the shellcode above and get the output?

sooo unicorn engine literally does this. either way, you shouldn't be trying to reverse it to C. you should write C to copy the shellcode to a buffer and call it, or you should emulate it. there's just no reason to reverse it and too much room to gently caress it up.

for example I wrote a script to run the key generation algorithm (with the malloc call at the beginning nop'd out). my result:
a@ubuntu:~$ python lol.py
D5333EC5 E94E7277 BAB1FE3D 86CCB28F

~~https://gist.github.com/anonymous/64465673ebb96f7ecb888b0b83d1b251~~ <-- nevermind, this code is wrong and bad see below

you can use the commented out parts and change the argument loading to use the same script to emulate the decryption algorithm (the other shellcode you posted). good luck!

edit: i've been informed that i hosed it up, the +0xca in emu_start should be +0xc6

edit2: ok, i probably hosed up my unicorn usage. reimplemented it in C to verify it was correct and got a different result. welp. i verified this disassembles to the correct call of the shellcode.

code:

~$ gcc memcpy.c -o mem -m32 && ./mem
calling it, hope you didn't gently caress up
C28222B7 B746D25A 8F180FFC FADCFF11

https://gist.github.com/cff0caa797450f9ccf36a0256ee577cd

edit3: well, i fixed the unicorn script. ESP should be set to stack_base+4 on function call, not stack_base-4. stack frames r hard
https://gist.github.com/5af52a4dafd95e8261186f5b1b4bc440

code:

~$ python lol.py
C28222B7 B746D25A 8F180FFC FADCFF11

Daman fucked around with this message at 00:19 on Jul 29, 2017

# ¿ Jul 28, 2017 21:14

Daman: Oct 28, 2011

Diva Cupcake posted:

It's a post-auth guest-privs-minimum RCE with a POC already in existence per the NIST calc. Good thing is that wsearch shouldn't be enabled by default on most servers.

https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?calculator&version=3&vector=(CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:P/RL:O/RC:C)

fixed

# ¿ Aug 10, 2017 07:43

Daman: Oct 28, 2011

you should find a position doing security engineering it sounds like, portland. if you can code you want to stay coding and definitely not working alongside a bunch of people who definitely do not write any of their own software

# ¿ Sep 10, 2017 02:35

Daman: Oct 28, 2011

don't pay for a sans cert with your own money ever... their quality varies greatly, anyway

take that oscp and prove to employers you can grep exploitdb

# ¿ Dec 22, 2017 10:11

Daman: Oct 28, 2011

Is there no way to buy a single license for enterprise, lol?

# ¿ Dec 31, 2017 20:34

Daman: Oct 28, 2011

so they claim they had the guy's IP hitting their server, right.

but then they restricted their malware to only run if a pirate serial is inserted. obviously, the cracker wasn't the only one using the keygenned serial if he was giving it out on a forum.

they probably stole more credentials than just that guy. whether they used them, who knows, they only admitted to that crime once. I'm pretty sure they're admitting to stealing creds from multiple people.

# ¿ Feb 21, 2018 21:58

Daman: Oct 28, 2011

EssOEss posted:

Oh, I see what you mean - it is the equivalent of the lock icon on the address bar that tells you the website is trustworthy, right? That makes a lot of sense. Code signing says the exe is known good, just like seeing the lock icon means it is safe to enter my passwords onto that website.

ya you're being sarcastic but actually yes, the green lock happening when you go on google.com means they absolutely trust everything that's getting sent to your browser.

just like when you do code signing, you have to absolutely put your company's name behind that signed binary being your product.

consumers don't care about fuckups, sure, but you're a lovely company if you don't try to avoid fuckups.

# ¿ Mar 1, 2018 02:35

Daman: Oct 28, 2011

if traditional endpoint protection means third party AV, that's a waste of time

carbon black or similar is a real good thing to have. it's an idiot proof way of setting up an equivalent to sysmon+WEF+siem alerts.

windows defender ATP does the same but better. the GUI is less poo poo, faster, better default rules, etc. they even supposedly support non-win10 systems now.

# ¿ Mar 14, 2018 18:21

Daman: Oct 28, 2011

Samizdata posted:

I stick with Telegram.

this isn't e2e encrypted forward secret comms, this is for furry group chats.

signal is still 100% fine and better than the competition

# ¿ May 14, 2018 18:38

Daman: Oct 28, 2011

hackbunny posted:

No idea, they're embargoed and people are very tight-lipped about it. The rumored codenames for both include the word "smack", for what it's worth

It's just DoS, but only takes a few very easily blocked packets.

# ¿ Aug 5, 2018 19:21

Daman: Oct 28, 2011

Theris posted:

What are you considering an "average CPU" here? Software Bitlocker on my 950 Pro (thanks for never actually enabling eDrive like you said you would, Samsung ) with a 6700k has zero performance impact in disk benchmarks and CPU usage low enough that it more or less blends into the background noise of how much CPU gets used when hitting a disk hard anyway.

is it actually enabled? you do need to disable and then re-enable bitlocker on the drive after toggling it.

# ¿ Nov 6, 2018 08:21

Adbot: ADBOT LOVES YOU

# ¿ May 5, 2024 00:05

Daman: Oct 28, 2011

bitlocker doesn't even default to hw encryption for any ssds I've seen, including my 850 evo running in transparent mode.

# ¿ Nov 12, 2018 04:04

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Infosec Thread: Yes, time to move off LastPass