Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us $3,400 per month for bandwidth bills alone, and since we don't believe in shoving popup ads to our registered users, we try to make the money back through forum registrations.
«159 »
  • Post
  • Reply
Paul MaudDib
May 2, 2006

"Tell me of your home world, Usul"


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=arti...=20160114142733

Paul MaudDib fucked around with this message at Jan 15, 2016 around 01:54

Adbot
ADBOT LOVES YOU

unknown
Nov 16, 2002
Ain't got no stinking title yet!

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/...-cve-2016-0728/ posted:

Introduction
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, and later developed a proof-of-concept exploit. As of the date of disclosure, this vulnerability has implications for approximately tens of millions of Linux PCs and servers, and 66 percent of all Android devices (phones/tablets). While neither us nor the Kernel security team have observed any exploit targeting this vulnerability in the wild, we recommend that security teams examine potentially affected devices and implement patches as soon as possible.

In this write-up, we’ll discuss the technical details of the vulnerability as well as the techniques used to achieve kernel code execution using the vulnerability. Ultimately, the PoC provided successfully escalates privileges from a local user to root.

The Bug
CVE-2016-0728 is caused by a reference leak in the keyrings facility. Before we dive into the details, let’s cover some background required to understand the bug.

Quoting directly from its manpage, the keyrings facility is primarily a way for drivers to retain or cache security data, authentication keys, encryption keys and other data in the kernel. System call interfaces – keyctl syscall (there are two other syscalls that are used for handling keys: add_key and request_key. keyctl, however, is definitely the most important one for this write-up.) are provided so that userspace programs can manage those objects and use the facility for their own purposes.

Each process can create a keyring for the current session using keyctl(KEYCTL_JOIN_SESSION_KEYRING, name) and can choose to either assign a name to the keyring or not by passing NULL. The keyring object can be shared between processes by referencing the same keyring name. If a process already has a session keyring, this same system call will replace its keyring with a new one. If an object is shared between processes, the object’s internal refcount, stored in a field called usage, is incremented. The leak occurs when a process tries to replace its current session keyring with the very same one. As we see in the next code snippet, taken from kernel version 3.18, the execution jumps to error2 label which skips the call to key_put and leaks the reference that was increased by find_keyring_by_name.

...full code and more at the link...

Subjunctive
Sep 12, 2006

careful now


Cybernetic Crumb

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.

Lain Iwakura
Aug 5, 2004

The body exists only to verify one's own existence.


Taco Defender


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.

Rufus Ping
Dec 27, 2006





I'm a Friend of Rodney Nano


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

co199
Oct 28, 2009

I AM A LOUSY FUCKING COMPUTER JANITOR WHO DOES NOT KNOW ANYTHING ABOUT CYBER COMPUTER HACKER SHIT.

PLEASE DO NOT LISTEN TO MY FUCKING AWFUL OPINIONS AS I HAVE NO FUCKING IDEA WHAT I AM TALKING ABOUT.


Rufus Ping posted:

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

I worked with spender, he is a cool and smart guy. Run grsec.

Mr Chips
Jun 27, 2007
Whose arse do I have to blow smoke up to get rid of this baby?


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 Jan 20, 2016 around 11:31

Rufus Ping
Dec 27, 2006





I'm a Friend of Rodney Nano


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

unknown
Nov 16, 2002
Ain't got no stinking title yet!

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_bu...d=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.

GTO
Sep 16, 2003



Surprised they didn't have a brand name and logo ready for it to be honest.

DeaconBlues
Nov 8, 2011


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.

Lain Iwakura
Aug 5, 2004

The body exists only to verify one's own existence.


Taco Defender

DeaconBlues posted:

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.

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 Jan 22, 2016 around 16:01

wyoak
Feb 14, 2005

a glass case of emotion


Fallen Rib

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.
Steganography as a concept isn't dumb, LE has compelled individuals to give up keys for known-to-be-encrypted containers. It was the whole point of TrueCrypt's hidden volumes. 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. Steganography for the key seems pretty dumb though.

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.

Diva Cupcake
Aug 15, 2005



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.
Case law on this is actually still unsettled in the US. District Court of Vermont (In re Boucher) and 11th Circuit Court of Appeals (US v Doe) held opposing views with the stipulation that if the contents are "generally known" by the government then revealing the key isn't self-incrimination. The Supreme Court hasn't yet ruled on it.

It'll get interesting when cases involving corporations refusing to comply with eDiscovery subpoenas start popping up.

Subjunctive
Sep 12, 2006

careful now


Cybernetic Crumb

Ozu posted:

"generally known"



That's delightful.

Methylethylaldehyde
Oct 23, 2004

BAKA BAKA


Subjunctive posted:



That's delightful.

"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."

KillHour
Oct 28, 2007


"What hard drive? You mean that smoldering pile in the microwave?"

doctorfrog
Mar 14, 2007

Great.


"My password contains a confession to the crime I am being charged with, therefore it is protected by the fifth amendment."

Methylethylaldehyde
Oct 23, 2004

BAKA BAKA


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.

KillHour
Oct 28, 2007


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.

PBS
Sep 21, 2015


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)

EVIL Gibson
Mar 23, 2001

THE CLOUD WILL PROTECT US


Switchblade Switcharoo

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?

It seems to meet the requirements. (something you have, something you know)


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 Feb 15, 2016 around 23:38

PBS
Sep 21, 2015


EVIR Gibson posted:

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.

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.

Subjunctive
Sep 12, 2006

careful now


Cybernetic Crumb

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.

PBS
Sep 21, 2015


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 Feb 16, 2016 around 01:10

Dex
May 26, 2006

Quintuple x!!!

Would not escrow again.

VERY MISLEADING!


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

PBS
Sep 21, 2015


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.

edit: apparently you're not but i'm still confused by the question

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 Feb 16, 2016 around 01:28

Dex
May 26, 2006

Quintuple x!!!

Would not escrow again.

VERY MISLEADING!


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 2fa

quote:

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

Subjunctive
Sep 12, 2006

careful now


Cybernetic Crumb

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.

PBS
Sep 21, 2015


There's a lockout policy in place.

MrMoo
Sep 14, 2000



PBS posted:

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.

There is a pretty awful Cisco appliance that has a SSL portal that works like this.

EVIL Gibson
Mar 23, 2001

THE CLOUD WILL PROTECT US


Switchblade Switcharoo

PBS posted:

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.


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.

Dex
May 26, 2006

Quintuple x!!!

Would not escrow again.

VERY MISLEADING!


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

Space Gopher
Jul 31, 2006
BLITHERING IDIOT

PBS posted:

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.

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).

Marinmo
Jan 23, 2005

Prisoner #95H522 Augustus Hill

PBS posted:

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.
This (similar but not exactly the same) is a really common authentication method for banks in my country. Basically you have your (equivalent to) SSN, then you have a authenticator which you unlock with a PIN and then enter 2 4-digit number sequences the webpage gives you, which will spit out a 6 digit authentication code. Seems secure enough to me (can't use authenticator w/o PIN) but is largely being replaced by electronic mobile IDs (give SSN, open app on cell phone, enter PIN (equal to or more than 6 numbers) -> authenticated)

Sentient Data
Aug 31, 2011

My molecule scrambler ray will disintegrate your armor with one blow!


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.

[e: Snip]

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 Feb 17, 2016 around 13:14

Subjunctive
Sep 12, 2006

careful now


Cybernetic Crumb

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.

Space Gopher
Jul 31, 2006
BLITHERING IDIOT

Sentient Data posted:

So, this is apparently interesting: http://www.apple.com/customer-letter/


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"

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".

wyoak
Feb 14, 2005

a glass case of emotion


Fallen Rib

nm i should read the whole thread

Adbot
ADBOT LOVES YOU

Boris Galerkin
Dec 17, 2011



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).

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply
«159 »