search for: exfiltration

On 02/04/2015 02:08 PM, Lamar Owen wrote: > > 3.) Attacker uses a large graphics card's GPU power, harnessed with > CUDA or similar, to run millions of bruteforce attempts per second on > the exfiltrated /etc/shadow, on their computer (not yours). > 4.) After a few hours, attacker has your password (or at least a > password that hashes to the same value as your password),

On 02/03/2015 03:44 PM, Always Learning wrote: > There should be a basic defence that when the password is wrong 'n' > occasions the IP address is blocked automatically and permanently > unless it is specifically allowed in IP Tables. As has been mentioned, fail2ban does this. However, the reason you want a password that is not easily bruteforced has nothing to do with this,

On Thu, 26 Oct 2017, James Bottomley wrote: > Engine keys are keys whose file format is understood by a specific > engine rather than by openssl itself. Since these keys are file > based, the pkcs11 interface isn't appropriate for them because they > don't actually represent tokens. What sort of keys do you have in mind here that can't be represented via PKCS#11? -d

...er commonly installed tools from being used to create such tunnels. Examples would be 'socat' or combinations of the openssl "demo" executable together with the tcp-redirection capabilities of certain shells, e.g. bash /dev/tcp/hostname/4711. Generally I think the problem of data exfiltration is unsolvable given sufficiently knowledable users and general-purpose software. One will always forget to plug one hole and to blacklist one more approach. Ciao, Alexander Wuerstlein.

On Thu, 2 Nov 2017, James Bottomley wrote: > On Fri, 2017-11-03 at 13:11 +1100, Damien Miller wrote: > > On Thu, 26 Oct 2017, James Bottomley wrote: > > > > > > > > Engine keys are keys whose file format is understood by a specific > > > engine rather than by openssl itself.??Since these keys are file > > > based, the pkcs11 interface isn't

On Wed, February 4, 2015 16:55, Warren Young wrote: >> On Feb 4, 2015, at 12:16 PM, Lamar Owen <lowen at pari.edu> wrote: >> >> Again, the real bruteforce danger is when your /etc/shadow is >> exfiltrated by a security vulnerability > > Unless you have misconfigured your system, anyone who can copy > /etc/shadow already has root privileges. They do not need

...used to create such tunnels. Examples would be 'socat' or combinations > > of the openssl "demo" executable together with the tcp-redirection > > capabilities of certain shells, e.g. bash /dev/tcp/hostname/4711. > > > > Generally I think the problem of data exfiltration is unsolvable given > > sufficiently knowledable users and general-purpose software. One will > > always forget to plug one hole and to blacklist one more approach. > > From the original description: the security breach occurred because > tunnels arae permitted by the daemon,...

> On Feb 4, 2015, at 12:16 PM, Lamar Owen <lowen at pari.edu> wrote: > > Again, the real bruteforce danger is when your /etc/shadow is exfiltrated by a security vulnerability Unless you have misconfigured your system, anyone who can copy /etc/shadow already has root privileges. They don?t need to crack your passwords now. You?re already boned.

On Thu, February 5, 2015 9:06 am, James B. Byrne wrote: > > On Wed, February 4, 2015 16:55, Warren Young wrote: >>> On Feb 4, 2015, at 12:16 PM, Lamar Owen <lowen at pari.edu> wrote: >>> >>> Again, the real bruteforce danger is when your /etc/shadow is >>> exfiltrated by a security vulnerability >> >> Unless you have misconfigured your

...his PDF had an embedded Javascript exploit (yes, Adobe Reader does do Javascript) and that Windows machine was pwned in short order (and the user I was running as was not an administrator equivalent). I suspect that using Adobe Reader on CentOS could be just as dangerous (in terms of user data exfiltration and/or payload delivery for crypto-ransomware). Privilege escalation is not required for much mischief to be done. Random PDFs are and continue to be malware vectors.

.... 2. There?s no such thing as SUID libraries. So, how is this hypothetical library of yours going to gain privileges that the executable linked to it does not have? Point me at a CVE where a vulnerable library was used for privilege escalation. You can point at vulnerable libraries giving data exfiltration and such all day long, but privilege escalation??

Portable OpenSSH 5.8p2 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or

On Wed, 2015-02-04 at 14:55 -0700, Warren Young wrote: > > On Feb 4, 2015, at 12:16 PM, Lamar Owen <lowen at pari.edu> wrote: > > > > Again, the real bruteforce danger is when your /etc/shadow is exfiltrated by a security vulnerability > > Unless you have misconfigured your system, anyone who can copy /etc/shadow already has root privileges. They don?t need to

On Thu, June 16, 2016 14:23, Valeri Galtsev wrote: > > On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote: >> >> I doubt that most users check the dates on SSL certificates, >> unless they are familiar enough with TLS to understand that >> a shorter validity period is better for security. > > Oh, this is what he meant: Cert validity period. Though I agree >

> > If you feel like it, you could write a VFS module that adds better support > for > this on FreeBSD, but what is the use case? > I've noticed in online forums that occasionally home NAS users will for various reasons have streams_xattr enabled and receive 'access denied' errors when trying to write files with large alternate datastreams. These are typically on media

...virtual machine having a > re-initialized PRNG in every process are straightforward. > Without reinitialization, two or more cloned VMs could produce > identical random numbers, which are often used to generate secure > keys. > - Provides a simple mechanism to avoid RAM exfiltration during > traditional sleep/hibernate on a laptop or desktop when memory, > and thus secrets, are vulnerable to offline tampering or inspection. For the first usecase, I wonder which way around this would work better - do the wiping when a VM is saved, or do it when the VM is restored?...

On Thu, 2017-02-02 at 13:40 -0800, Gordon Messmer wrote: > Escalation *requires* attacking a program in a security context other > than your own. Not necessarily. Suppose the adversary is aware of a root exploit/privilege escalation in a random library. Then the heap spraying allows this attacker to easily trigger this exploit because he is able to initialize the entire contents of the

Good day! A few weeks ago, we had a security breach in the company I'm working for, because employees used "ssh -R" to expose systems from our internal network to some SSH server in the outer world. Of course, this is a breach of our internal security policy, but lead us to wonder, whether there is a technical solution to prevent our users from creating SSH-reverse-tunnels. After

...tual > machines get cloned. Umm. If this is real problem, should kernel provide such rng in the vsdo page using vsyscalls? Kernel can have special interface to its vsyscalls, but we may not want to offer this functionality to rest of userland... > - Provides a simple mechanism to avoid RAM exfiltration during > traditional sleep/hibernate on a laptop or desktop when memory, > and thus secrets, are vulnerable to offline tampering or > inspection. This second use has nothing to do with RNGs, right? And I don't think we should do this in kernel. It is userspace that initiate...

...tual > machines get cloned. Umm. If this is real problem, should kernel provide such rng in the vsdo page using vsyscalls? Kernel can have special interface to its vsyscalls, but we may not want to offer this functionality to rest of userland... > - Provides a simple mechanism to avoid RAM exfiltration during > traditional sleep/hibernate on a laptop or desktop when memory, > and thus secrets, are vulnerable to offline tampering or > inspection. This second use has nothing to do with RNGs, right? And I don't think we should do this in kernel. It is userspace that initiate...