« first day (3135 days earlier)      last day (2043 days later) » 

00:42
@Anthony I disagree. Attack surface area analysis lets you predict 0days.
 
2 hours later…
02:19
@forest, if the exposure is large (attack surface), wouldn't there still be an degree of probability such that a 0 day vulnerability may or may not be exploited at your company?
@Anthony There will always be a non-zero probability (assuming you don't use formal verification), but you can reduce that probability to an extremely low value. The solution to a large attack surface is to shrink it, and there are various means to do that (privilege separation so you only have to worry about privilege boundaries, etc.).
If I'm auditing a system where a risk is a browser exploit being used to elevate privileges outside of the browser, I don't need to audit every single JavaScript API and all the complexities of the browser's HTML handling. I can limit my analysis to the privilege boundary between the browser process and the kernel, so now I'm only auditing syscalls. If I use a seccomp sandbox, I can arbitrarily reduce the number of syscalls that I need to worry about.
Another example: Imagine I'm writing thumbnailing code, and I need to ensure that a malicious image uploaded to a website can't exploit the website through a vulnerability in the encoder (assuming the full-sized image is stored without being processed except to be thumbnailed). The solution to that is to run a sandboxed process running a typical image encoder and convert it into a simple pixelmap format like PPM after doing the transform on it. That PPM can be shared through shared memory or
a pipe to an unsandboxed process which re-converts it to, say, a PNG. Now I don't have to worry about the attack surface of all of imlib2. I only have to care about the APIs exposed by the kernel to the sandboxed process (in theory, none except for exit() to close the process), and the security of the PPM-to-PNG encoder (as decoding is harder to exploit than encoding).
You mentioned managing and shrinking the attack surface, which is part of proactively managing a vulnerability, so for my linked question, which side do you lean towards?
Are you asking basically whether or not this is a good stance:
> My opinion was that even if a vulnerability discovered today has no applicable attack vectors because conditions needed to exploit it does not exist, the vulnerability is still worthy of monitoring as its future behavior may evolve.
Well, in a Cloud environment, I do see response agility / speed as critical
If a vulnerability cannot be exploited on your system, then you typically don't need to take it into account. If you might be vulnerable in the future, then it's good to take note, but generally, a vulnerability that is not applicable to your system is not a vulnerability in your product or service.
E.g. I don't need to care about a vulnerability in ia32 syscalls for Linux because I have a 64-bit-only kernel. I might take note of it so security analysis goes quicker if I ever do switch to ia32...
Imagine the extreme end: If you use Docker to run a database backend for a financial service, do you need to worry about vulnerabilities in Microsoft's Xbox One DRM validation scheme for BluRay discs? The vulnerability still exists, but it's not applicable to you, so you can ignore it.
@Anthony Overall, I'd say that, if a vulnerability might be applicable to you in the future, then you should at least take note of it. The only reason to do this is to save time, so you don't have to go through classifying potential vulnerabilities for as long if you make changes to your setup that requires re-doing analysis. The end result should be no different; it's just faster to keep some vulns in mind.
I can convert this into an answer to your question, if you wish.
s/decoding is harder to exploit/decoding is easier to exploit/
02:49
0
A: If a vulnerability has no relevant attack vectors, is monitoring still legitimate for a company?

forestIf a vulnerability cannot be exploited on your system, then you typically don't need to take it into account. If you might be vulnerable in the future in the event that you change your configuration in a way that would make you exploitable, then it's good to take note, but generally, a vulnerabil...

03:07
So basically both of us have good points. Makes sense. Will accept as answer
Yep, though the biggest takeaway should be "it depends; do risk analysis to be sure".
Forest, where you work, are you still on - prem or in a Cloud environment or even hybrid? With Cloud, assets are no longer physical anymore. Its like not I can walk in to a Co -lo data center and see racks with servers on it.
03:22
I'm a contractor so I've worked in both, though I have little experience with most cloud infra.
I personally prefer on-premises. I like being able to hook up a physical cable. :P
Other than 3rd party shared risk, (cloud hosting provider), how does the virtualized Cloud environment change monitoring / risk analysis? what other than speed / agility do you see as critical?
What counts as shared risk can be a bit vague, since side-channel attacks exist pretty much independently of the hosting provider. In general though, a virtualized environment is easier to monitor because you don't need to use something like IPMI to do low-level management.
Generally there isn't much beyond the shared risk to take into account.
Pretty much anything that can be done virtualized can also be done on a dedi, even something that's trivial to do in a cloud environ like restoring from a snapshot can be done on physical servers (e.g. with TFTP boot). Virtualization just makes some things a bit easier.
03:44
Why there's Session ID in client hello message, the first time I visit a website?
I never visit that website before.
0
Q: Why does browser send TLS session ID first time visit a website?

RickI read this answer of SSL session tickets vs session ids. When the server sends the “Server Hello” message, it can include a session identifier. The client should store it and present it in the “Client Hello” message of the next session. So my guess is that if I visit a website that I neve...

How do you know you've never visited it?
Perhaps a previous TLS connection was done before you clicked the link.
oh
@Rick I think the client sends the session ID first, asking the server to use that ID?
From skimming the RFC, at least.
@forest I tested several websites that I randomly choose from Google results.
No I guess for new connections, the session ID field is always blank.
So the only possibility is that a prior TLS connection was performed.
@Rick Try connecting to the website using a command-line utility. That way you've removed variables (like browser prefetching) from the equation.
Ah, yes, I can try with curl.
Ok let me try
Make sure curl supports session ID. I'm sure wget does, but I'm not sure about curl.
03:55
Ok then I would try wget, anyway I just need to examine the Client Hello message in Wireshark.
Btw
Is this TLS session the same as the "Application level Session"?
A TLS session is its own thing. It might change even if the application session doesn't.
At least that's the way the terminology reads. I'm not sure how Wireshark itself defines it.
By saying "Application level Session", I mean the concept which people often talk along with cookies.
Ah. Yeah they're totally different then.
Ah I see thank you help me clarify that
I could resume an HTTP session with cookies even a year later (if the cookies didn't expire), but naturally the initial TLS session would have been long finished by then.
04:00
OK I see. And those so called "session id" stored in cookies are totally different from the TLS session ID we are talking about.
Totally different, yes. The TLS session ID is an identifier that the server uses to resume a specific session when the shared master secret is still remembered. A cookie can be used to resume a session for a web application, but exactly how it works depends on the web app.
OK got it.;D Thanks~
:) same in wget
Never mind, I would just leave that SO question open. It's not a important question though.
Huh, weird. What I'd do in your place is check the source code.
Since that doesn't match what the RFC is saying.
What does RFC say?
Just that the client sends a previous session ID to the server.
But the field is blank if there is no previous session.
04:11
Ah OK I see
Never mind, not a big problem.
Btw, do you know where can I see the SNI in the TLS handshake?
What do you mean?
https://www.wikiwand.com/en/Server_Name_Indication
What do you mean by "where", I meant.
Ah I see, in wireshark...
"The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested." I want to examine this
Oh. SNI is pretty much never encrypted (ESNI is still new).
tools.ietf.org/html/rfc6066#section-3 is the relevant part of the RFC.
It's put in the extended client hello and tells the server what vhost it should get the cert from.
04:20
Ah I see
The client/brower should send the SNI at the very beginnning during the TLS handshake.
Whether the server has multiple vhosts or not, the client should send it at first.
The client sends it before the certificate is sent.
It doesn't need to send it any earlier.
Yes.
Thank you again : )
No problem. :P
 
3 hours later…
07:42
Can someone answer me this.
I have a bunch of files i wanna encrypt symmetrically
But gpg doesnt allow encryption of multiple files at the same time
So i made a tar file and then encrypted the tar file using gpg
Is that okay to do?
is it secure?
@VipulNair Yeah that's secure. It's a pretty normal way to archive multiple files with gpg.
 
1 hour later…
09:02
thanks @forest
 
3 hours later…
12:30
I'm trying to stay in touch with local folks who seem to know their stuff. Problem is that there is not really that much of a "gun culture" here, and so their knowledge is mostly limited to their practical needs. Given that most of them are/were hunters, their expertise is in that field.

It'd just be nice to have a somewhat legitimate souce of information like Stack Exchange. While it isn't perfect and has its own kind of problems (FGITW, for example), I think it's a hell of a lot more reliable than Anon telling me "lol Glocks are shit go buy a 1911 if you're serious"
@VipulNair It's also better to encrypt(tar(file1, file2, file3, ..., fileN)) than tar(encrypt(file1), encrypt(file2), encrypt(file3), ..., encrypt(fileN)), because it exposes less information (e.g. how many files you are encrypting, metadata about those files, etc.)
 
1 hour later…
13:42
@MechMK1 thanks.got it
13:56
@VipulNair You're welcome!
0
Q: aireplay-ng deauth not working

jolskeyaireplay-ng deauthentication does not work for me. Despite everything goes well before, when I enter command aireplay-ng --deauth 2000 ... it only sends a few packets (like 3-4), but sometimes more, however, it does not disable the device from the network. How can I fix that?

Are deauth attacks even viable anymore? Haven't gotten one to work in quite some time
 
2 hours later…
15:51
Me: Why hasn’t it been patched for EternalBlue?
Vendor: The reason we haven’t patched for any type of recent ransomware or other crypto viruses is because the machine has two networks which it utilizes. The first one is the system network which is a closed network and has no access to anything other than the machine. The second is the company network which our customers use to connect to the Workdata Folder. The workdata folder is used for dropping programs into. This folder is not a shared folder to the rest of the machine therefore should any ransomware get into it via your company, we ca
I don't think they understand what "RCE" means...
@jdgregson [facepalm.png] Right, because ransomware is totally going to respect boundaries that exist purely in the vendor's imaginations...
Totally. They put two nics in, so once it has system-level access it'll leave the business-critical network alone.
Did EternalBlue allow system-level RCE? The only documentation I'm finding says "RCE" in general. I assume it would be system level, since SMB is running as system or local service.
But I suppose this is par for the course when it comes to industrial equipment. Basically "We don't need to apply security updates because our stuff breaks and we'd have to fix it. Plus, like, some other customers still run NT or XP, so you're find with Windows 7 past EOL."
 
4 hours later…
19:38
1
Q: Why do web browsers provide websites with plain text passwords?

WilliamSuppose I sign up for website.com with username "John" and password "Secret". Currently the webbrowser supplies website.com with my real plain text password, and we must trust them to salt and hash it properly so that if they are hacked, damage to users is minimized. Why don't web browsers hash...

Is it me or does he makes sense?
20:08
But does it solve the password reuse problem?
i still dont see normal user using a password manager
 
1 hour later…
21:21
@NicHartley what are you talking about?I am talking about people using the same password on every site.When one site's database gets leaked the attackers gets credentials for other site
The implementation he gives solves that by combining (domain+username+password)
Nowhere did i mention MITM.
22:12
@VipulNair hash(domain+identity+secret) is significantly less secure than hash(secret+salt), because the domain name and identity are very low entropy values. Adding in a salt means that the server needs to broadcast the salt to anyone who might want to authenticate, which while the salt isn't a secret per-se, it's still best to treat it as sensitive... (and asking for a salt can be used in an enumeration attack).
The identity should also not be case sensitive. Using it as part of a hash to verify the secret will make it case sensitive.
(And, of course, stop thinking about hashes when thinking about authentication systems; think about key stretching algorithms like PBKDF2, bcrypt, scrypt, and Argon2.)
22:35
@Ghedipunk i should learn more i guess.
There are zero-knowledge proofs, where you can demonstrate that you know the password without the server ever getting that password or reverse engineer it without brute forcing it... The question, though, simply takes the domain name, identity, and secret, and turns that aggregate into a new secret that the server knows. The hash becomes the secret, and if stored improperly (which developers will, since it's a "secure" password protocol), they might as well store the password in plaintext.
 
1 hour later…
23:49
@MechMK1 They're pretty much always viable. The only time they don't work is if the client and base station are both using 802.11w protection for management frames (even Windows 7 doesn't support that, so most routers have the option disabled).
Even then, there are apparently other ways to force deauthentication.
28
A: Preventing deauthentication attacks

YLearnCisco spearheaded a method of detecting these attacks and even protecting this type of attack if it is enabled and the client device supports it (minimum support of CCXv5). The Cisco feature is called "Management Frame Protection" and full details can be found on the Cisco website. In essence, t...

3
A: How do you prevent/guard against a wireless disassociation attack

forestThis can be protected from with the IEEE 802.11w, also called Management Frame Protection (MFP), which provides authentication for Wi-Fi management frames, including those related to deauthentication and disassociation. When protected management frames are supported and enabled by both sides, the...


« first day (3135 days earlier)      last day (2043 days later) »