|
Hey y'all, there's a publically-released OpenSSH exploit that can leak memory or private keys to a compromised/malicious server (but not MITM). Add the line UseRoaming = No to the top (i.e. applies to all hosts, do not cat it on the end if you have host-specific config) of your /etc/ssh/ssh_config files immediately and consider rotating SSH keys afterward particularly if you're not using keyphrases for your private key. http://undeadly.org/cgi?action=article&sid=20160114142733 Paul MaudDib fucked around with this message at 02:54 on Jan 15, 2016 |
#
?
Jan 15, 2016 02:46
|
|
|
|
| # ? Apr 19, 2024 07:38 |
|
|
Say hello to the new linux kernel root vunerability CVE-2016-0728 released today before your vendor can do anything about it.http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-kernel-vulnerability-cve-2016-0728/ posted:Introduction
|
|
#
?
Jan 19, 2016 23:14
|
|
|
unknown posted:The Perception Point Research team has identified a 0-day local privilege escalation vulnerability in the Linux kernel. While the vulnerability has existed since 2012, our team discovered the vulnerability only recently, disclosed the details to the Kernel security team Hmm.
|
|
#
?
Jan 19, 2016 23:43
|
|
|
Subjunctive posted:Hmm. The blog entry itself posted:Thanks to David Howells, Wade Mealing and the whole Red Hat Security team for that fast response and the cooperation fixing the bug.
|
|
#
?
Jan 19, 2016 23:59
|
|
|
If you're running linux without grsec (which renders this unexploitable) you're a bit of a mug imo Debian even has prebuilt grsec kernels now
|
|
#
?
Jan 20, 2016 03:09
|
|
|
Rufus Ping posted:If you're running linux without grsec (which renders this unexploitable) you're a bit of a mug imo I worked with spender, he is a cool and smart guy. Run grsec.
|
|
#
?
Jan 20, 2016 06:54
|
|
|
what's the path to better kernel security look like if I'm heavily RHEL6-ified (including SELinux)? Is getting grsec into the mix feasible?
Mr Chips fucked around with this message at 12:31 on Jan 20, 2016 |
|
#
?
Jan 20, 2016 12:24
|
|
|
Mr Chips posted:what's the path to better kernel security look like if I'm heavily RHEL6-ified (including SELinux)? Is getting grsec into the mix feasible? I don't think there are any officially sanctioned grsec patched rpms so you'd have to build the kernel yourself, probably invalidating your support contract
|
|
#
?
Jan 20, 2016 14:54
|
|
|
I'm not saying they didn't disclose, but just gave a very small embargo window to one vendor (https://bugzilla.redhat.com/show_bug.cgi?id=1297475 / https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-0728) to fix across multiple vendors before doing a very public disclosure with working exploits - all before anyone could really get a tested patch in place/released. Semi responsible security research info release, good for maximum media attention basically.  Won't be the first, won't be the last.
|
|
#
?
Jan 20, 2016 19:44
|
|
|
Surprised they didn't have a brand name and logo ready for it to be honest.
|
|
#
?
Jan 20, 2016 20:09
|
|
|
https://www.dyne.org/software/tomb/ Any analysis/criticism/props for tomb? I haven't used it yet. Apparently you can wrap it around luks and in certain applications you can also retrieve your key file over a network and pipe it in during mount, which saves storing the key on the same device as the encryption container. Seems like a neat idea.
|
|
#
?
Jan 22, 2016 05:49
|
|
|
DeaconBlues posted:https://www.dyne.org/software/tomb/ Sure. quote:However we strongly encourage people in need of strong encryption to not use Winslows, or at least to not generate encrypted partitions with it, since it can contain backdoors in the random number generation, as pointed by Bruce Schneier and Niels Ferguson in this short essay about the Dual_EC_DRBG. Why would you want to use an encryption tool that is not cross-platform and with authors who write "Windows" as if they're infantile? To add to this, they lay claim to "certain backdoors in the [RNG]" which is interesting because it cites a problem in Windows 2000, an operating system old enough to be able to drive a car. Also the paper it cites from 2007 (which you can read here) makes zero mention of it being a backdoor or otherwise being intentional. Lastly, the problem affected XP as well (due to the similar code base), but Microsoft fixed it in Service Pack 3. I am not going to rant or discuss this part further because this topic goes beyond what I am comfortable to talk about but the guys who wrote this Tomb garbage appear to be willing to jump to conclusions. quote:Steganography helps here. Tomb offers the possibility to bury and exhume keys from jpeg images: if steghide is installed on a system then Tomb will offer this commands in its command-line help. Steganography is dumb and shouldn't be even hinted at if you're trying to be serious about a cryptography product. https://github.com/dyne/Tomb/blob/master/tomb Also it's a glorified shell script that is basically a wrapper for GPG, meaning that it isn't revolutionary. I haven't the chance to further look at the code, but I don't have much faith considering how it's written and the stupidity on the website. Seriously, don't just suggest a random cryptography tool like this. Not only is it written by individuals who cannot write "Windows" without turning into children, they preach the use of idiotic deception to hide your keys. If you need a tool to share files amongst machines, use 7-Zip or something that actually is cross-platform and isn't written by someone trying to create some uninformed narrative. If they're serious cryptographers, they'd not cite a 9-year old paper on an attack on Windows 2000/XP that has since been fixed as evidence of a supposed backdoor within WIndows. Lain Iwakura fucked around with this message at 17:01 on Jan 22, 2016 |
|
#
?
Jan 22, 2016 16:49
|
|
|
OSI bean dip posted:Steganography is dumb and shouldn't be even hinted at if you're trying to be serious about a cryptography product. This is probably a semantic thing where we're using different definitions of steganography but my point is that deniable encryption isn't a dumb thing.
|
|
#
?
Jan 22, 2016 18:02
|
|
|
wyoak posted:In the US key disclosure is now protected under the fifth amendment, but I don't know about other countries, and I don't know how specific that ruling is either. It'll get interesting when cases involving corporations refusing to comply with eDiscovery subpoenas start popping up.
|
|
#
?
Jan 22, 2016 19:20
|
|
|
Ozu posted:"generally known"  That's delightful.
|
|
#
?
Jan 22, 2016 19:24
|
|
|
Subjunctive posted:
"Look, we know the volume is full of CP, we have detailed scans of your eDonkey share showing it. Now turn over the key so we can tally up how many non-shared images you had and get this sham of a court case over with." "I forgot the key." "The hell you did. Cough up or we hold you in contempt indefinitely."
|
|
#
?
Jan 22, 2016 22:47
|
|
|
"What hard drive? You mean that smoldering pile in the microwave?"
|
|
#
?
Jan 24, 2016 22:38
|
|
|
"My password contains a confession to the crime I am being charged with, therefore it is protected by the fifth amendment."
|
|
#
?
Jan 25, 2016 08:28
|
|
|
doctorfrog posted:"My password contains a confession to the crime I am being charged with, therefore it is protected by the fifth amendment." That would actually be a novel defense, except for the fact that it's been used, and they compelled the person to type it in without knowing what was being typed to avoid disclosing it to law enforcement.
|
|
#
?
Jan 25, 2016 12:41
|
|
|
Hidden encrypted containers are a solved problem. Alternatively, do what the real CP rings do - RDP into a server with hardware encryption. The files never touch your computer.
|
|
#
?
Jan 25, 2016 13:50
|
|
|
If you log into a website with a user id and an rsa token (generated on a laptop / mobile, using a pin), would the login to the website be considered 2fa? It seems to meet the requirements. (something you have, something you know)
|
|
#
?
Feb 15, 2016 22:36
|
|
|
PBS posted:If you log into a website with a user id and an rsa token (generated on a laptop / mobile, using a pin), would the login to the website be considered 2fa? No. For proper 2fa you need something you know (password) and something you have (token). The userid can easily not be something you only know especially in an environment that combines first names and last names for the username or where you publicly post. edit: example: I am John Anthony Smith. You are Angela Julia Faraday. My user name is "jasmith". I take Angea's token. Just because I happen to know that her username is most likely "ajfaraday" is not enough to satisfy "something you know". It is better said as "something you privetly know" or in most cases password. Just don't be like some sites I've assessed where they used tokens and replaced the "you know" password with a grid of images so you select the one that you picked during account creation or something Web 2.0. EVIL Gibson fucked around with this message at 00:38 on Feb 16, 2016 |
|
#
?
Feb 15, 2016 22:45
|
|
|
EVIR Gibson posted:No. For proper 2fa you need something you know (password) and something you have (token). I figured someone might interpret it that way, I wasn't mentioning the userID as a second factor, I was just mentioning that it was a field that was present. Sorry for the confusion. To reword my question, I'm curious if the website login itself is considered 2FA if the only login requirements are a UserID and a "passcode". The passcode itself would likely be considered 2FA since you need an RSA enrolled device and to know the PIN used to generate the token. (have/know fulfilled) The benefit I see to this approach is you're only entering a TOTP on public/insecure devices. This is of limited use from the perspective of protecting data that's being accessed on a public device, but it would prevent capturing the credentials and using them for some other system. The fault is that the password you're now authenticating with is just eight numeric characters that changes every X seconds.
|
|
#
?
Feb 16, 2016 01:40
|
|
|
If you force the user to change their password after every login, does simple u+o auth become 2-factor? I certainly wouldn't say so.
|
|
#
?
Feb 16, 2016 01:58
|
|
|
Subjunctive posted:If you force the user to change their password after every login, does simple u+o auth become 2-factor? I certainly wouldn't say so. I get what you're saying (maybe), but in this case the password itself is 2fa to get. If I'm answering my own question I'd say no, the weblogin itself isn't 2fa because you're just entering a single passcode to authenticate. (Even though the passcode itself is 2fa to get) I'm wondering if this kind of login would be considered secure overall, and what any obvious pitfalls to it would be. PBS fucked around with this message at 02:10 on Feb 16, 2016 |
|
#
?
Feb 16, 2016 02:06
|
|
|
i'm confused. securid works with your pin(something you know) and your token code(something you have, changes every 60 seconds), and the two of those must be correct when you're challenged. so your passphrase is PASSWORD123456 or PASSWORD456789 or whatever. are you asking about using the code _only_? don't do that. edit: apparently you're not but i'm still confused by the question
|
|
#
?
Feb 16, 2016 02:14
|
|
|
Dex posted:i'm confused. securid works with your pin(something you know) and your token code(something you have, changes every 60 seconds), and the two of those must be correct when you're challenged. so your passphrase is PASSWORD123456 or PASSWORD456789 or whatever. are you asking about using the code _only_? don't do that. Let me explain a little further. The goal is to log into X website, the website login page has two fields. One field is UserID, the other is Passcode. The passcode itself is something you generate. You generate the passcode by entering your PIN into an RSA SecureID token client, either on a phone or computer. So if your PIN is 123456, you input this into the SecureID token client and it will spit out something like 01923227. Go back to the webpage, enter userid in userid field, enter 01923227 in the passcode field, hit login. PBS fucked around with this message at 02:28 on Feb 16, 2016 |
|
#
?
Feb 16, 2016 02:21
|
|
|
i keep forgetting that client exists actually, which is why i was confused, we just pin + fob code directly. same thing ultimately since the server needs access to the token seeds anyway to confirm it was valid, still 2faquote:The fault is that the password you're now authenticating with is just eight numeric characters that changes every X seconds. you can manage that - trying to log in twice with the same code, or using the incorrect code twice in a row, locks me out of vpn and site logins until an admin resets my account
|
|
#
?
Feb 16, 2016 02:37
|
|
|
Dex posted:you can manage that - trying to log in twice with the same code, or using the incorrect code twice in a row, locks me out of vpn and site logins until an admin resets my account Yeah, if online brute force attacks are even a little bit of a risk for you, fix that before worrying about the number of factors.
|
|
#
?
Feb 16, 2016 02:46
|
|
|
There's a lockout policy in place.
|
|
#
?
Feb 16, 2016 02:50
|
|
|
PBS posted:Let me explain a little further. There is a pretty awful Cisco appliance that has a SSL portal that works like this.
|
|
#
?
Feb 16, 2016 03:30
|
|
|
PBS posted:So if your PIN is 123456, you input this into the SecureID token client and it will spit out something like 01923227. Where/how/why is doing the calculation to take "123456" to "01923227". Where in relation to the application requiring the authentication. How is it converting a the FOB token to 01923227. And why exactly is the client requirement to come up with something like this? Just from thinking of what your system is trying to do you are going to a get a lot more problems of people passing token time outs while they go through this conga-line of confusion.
|
|
#
?
Feb 16, 2016 04:32
|
|
|
EVIR Gibson posted:Where/how/why is doing the calculation to take "123456" to "01923227". Where in relation to the application requiring the authentication. How is it converting a the FOB token to 01923227. his application isn't involved in this part of the chain, it's all rsa securid and their client software. i'd suggest reading their docs if you're curious about the how and why of it
|
|
#
?
Feb 16, 2016 15:40
|
|
|
PBS posted:I get what you're saying (maybe), but in this case the password itself is 2fa to get. Whether "this kind of login" is secure depends on the infrastructure surrounding it. RSA's implementation is secure 2FA, but it would be possible to present something that looks almost identical to the user that is not 2FA. With the SecureID setup, the password/PIN/thing-you-know is managed by the server. The token is independent and has no relationship to it. Enter a wrong PIN, and the only way to know is when you actually try to use it on the server. If you compromise the token system, and can get or provision a token associated with arbitrary credentials to yourself, the system will still not authenticate you without the correct PIN and keeps you out. But, take something that looks superficially similar from a client perspective: I have an "authenticator" app on my phone, which has a passcode set. I have to enter the passcode to get access to the app, so it might seem just as secure - but the authentication is all contained in my phone. If I can provision another token, the whole system is broken. So, that's not 2FA at all. Having all the factors wrapped up in one number is a red herring. The same thing ultimately happens when you send an auth request to most any server that's not using challenge/response: all your credentials are wrapped up in a single request, encrypted, and sent along. The pitfalls are about what you'd expect. PINs aren't very strong passwords, and all the communication happens over a single channel (which isn't inherently a bad thing, but now that "user has an always-on, always connected computer in their pocket, accessible over a different network, which can inform them of login attempts" is a reasonable assumption in many cases, we might as well use it).
|
|
#
?
Feb 16, 2016 18:23
|
|
|
PBS posted:Let me explain a little further.
|
|
#
?
Feb 16, 2016 21:03
|
|
|
So, this is apparently interesting: http://www.apple.com/customer-letter/Reddit comment posted:Apple's letter is a dead canary, the backdoor is already in place. vvv: They're limited to numeric passwords? I'm too used to Android where at-rest pops up a full keyboard and at least suggests going beyond just numbers E2: though actually, why do they allow the OS to be upgraded when the phone is still locked? I thought all data connections were a no-go while the lock screen is up. It seems like part of the firmware should be a hook that says "Forced software upgrade without unlocking the phone? fine, but wipe all user data before writing the new os/firmware" Sentient Data fucked around with this message at 14:14 on Feb 17, 2016 |
|
#
?
Feb 17, 2016 13:24
|
|
|
The Reddit poster needs to read the whole letter. The phone is unlocked by the PIN, and the requested OS version a) allows PINs to be tested via software, much faster; and b) disables the auto-wipe after 10 failed entries.
|
|
#
?
Feb 17, 2016 13:28
|
|
|
Sentient Data posted:So, this is apparently interesting: http://www.apple.com/customer-letter/ iOS can do passwords of essentially arbitrary length on a 77-character keyboard. But very few people do it, because unless you've pissed off the NSA, "4-6 digit numeric PIN, 10 attempts erases it" is good enough to secure data on the phone. The hardware itself can be put into a low-level recovery mode called DFU. This enforces signing requirements, but otherwise lets you write pretty much whatever you want to the firmware. The normal use would be to wipe and restore the firmware even if the OS layer is hosed, but with images of all the software that should be on the device, it wouldn't be too hard to come up with a few strategic jump instructions around "if failed attempts > 10, wipe device" and "if attempts in past few minutes > threshold, delay next attempt".
|
|
#
?
Feb 17, 2016 16:47
|
|
|
nm i should read the whole thread
|
|
#
?
Feb 17, 2016 16:50
|
|
|
|
| # ? Apr 19, 2024 07:38 |
|
|
Plus it's pretty annoying having an actual real password on your phone because think about how often you unlock it. Most people I know don't even bother with a 4 number pin code. I think the newer iPhones or iOS forces a 6 digit code now if you set one (as in 4 digits aren't allowed).
|
|
#
?
Feb 17, 2016 20:58
|
|
