BeOSPOS posted:

looks like we found the first vulnerability of this thread lol

Chris Knight posted:

Whack for my Larry-o
There's a keystore in the JAR-o

cheese-cube posted:

i'll buy this tag for the next 10 ppl who quote this post (might take me a couple of days to do so, ive just moved house and have no internet yet)

anthonypants posted:

idk who that guy is but he sure is good at run-on sentences, and woo uh oops

Subjunctive posted:

IDK how long it takes to clear whatever cache of things and stuff, but:

uncurable mlady
fishmech
Crusader
jre
Captain Foo
Storysmith
Westie
Mad Wack
Testiclops
BeOSPOS

should all be set.

RZA Encryption posted:

just look at the post where you requested it

ChickenOfTomorrow posted:

tag check

Chris Knight posted:

whoa baud betty bam a lam

goddamnedtwisto posted:

The funny thing is there is a name for that technique, but nobody's going to call their product "sheep dip". Well, maybe people who make sheep dips.

Sharktopus posted:

anyone know of any good opsec education resources? classes, texts, stories, anything that's accurate and educational really

Cocoa Crispies posted:

granny natting, not double dmz natting like you should be

spankmeister posted:

I know this thread can seem a bit intimidating but your reasoning isn't that far out there so really, don't be afraid to ask questions.

anthonypants posted:

https://twitter.com/webster/status/720758545688477696

quote:

Abstract
In December 2015, Juniper Networks announced that
unknown attackers had added unauthorized code to
ScreenOS, the operating system for their NetScreen VPN
routers. This code created two vulnerabilities: an authentication
bypass that enabled remote administrative access,
and a second vulnerability that allowed passive decryption
of VPN traffic. Reverse engineering of ScreenOS binaries
revealed that the first of these vulnerabilities was a conventional
back door in the SSH password checker. The
second is far more intriguing: a change to the Q parameter
used by the Dual EC pseudorandom number generator. It
is widely known [7, 33] that Dual EC has the unfortunate
property that an attacker with the ability to choose Q can,
from a small sample of the generator’s output, predict all
future outputs. In a 2013 public statement, Juniper noted
the use of Dual EC but claimed that ScreenOS included
countermeasures that neutralized this form of attack.
In this work, we report the results of a thorough independent
analysis of the ScreenOS randomness subsystem,
as well as its interaction with the IKE VPN key establishment
protocol. Due to apparent flaws in the code,
Juniper’s countermeasures against a Dual EC attack are
never executed. Moreover, by comparing sequential versions
of ScreenOS, we identify a cluster of additional
changes that were introduced concurrently with the inclusion
of Dual EC in a single 2008 release. Taken as a
whole, these changes render the ScreenOS system vulnerable
to passive exploitation by an attacker who selects
Q. We demonstrate this by installing our own parameters,
and showing that it is possible to passively decrypt
a single IKE handshake and its associated VPN traffic in
isolation without observing any other network traffic.

Subjunctive posted:

https://www.google.com/transparencyreport/safebrowsing/diagnostic/index.html#url=google.com

BangersInMyKnickers posted:

store the passwords with reversible encryption and check them

cheese-cube posted:

this is technically a secfuck i guess: earlier this week we had a line-card fail on the core router at our DC which caused some knock-on storage issues and took our first exchange CAS server offline for about 12 hours. due to our dumb network inbound SMTP only goes to the first CAS server even though there are two in an array. at around the 12 hour mark i said "lol that server aint coming back" and got the network dudes to change the static NAT mapping to direct mail to the second CAS server. when we did that we expected that a flood of mail queued by messagelabs would come through but only new emails were coming through.

turns out the secondary inbound route for mail in messagelabs was pointing to an email continuity service (messageone) which we no longer used. so when our primary CAS server went down messagelabs started forwarding all inbound mail to this provider and their MTA happily accepted it.

so for 12 hours all inbound mail was going to a third-party which we have no control over or association with. about 39K emails went to this third-party and for all we know they still have them, sitting in a postfix queue on some AWS server somewhere. apparently the lawyers are speaking to messageone and demanding that they handover the emails lollll

Segmentation Fault posted:

https://www.youtube.com/watch?v=uoZgZT4DGSY

Wheany posted:

A Pinball Wizard posted:

Dessert Rose posted:

lol @ you loving idiots making fun of a military encryption device having clearly labeled interfaces and buttons

yeah, it's totally hilarious to have the clear text and crypto interfaces as physically far apart as possible so idiot with a HS diploma doesn't accidentally beam the clear text across the public unsecured network

and it should definitely not have an easy to access button to destroy all the crypto material in the device if the enemy is overrunning the base

Sharktopus posted:

im just gonna start quoting parts of this at people in irc

surebet posted:

as a long time reader and irregular poster in the secfuck threads, would it be a faux pas to grab the gangtag? i'm doing an av swap and i'd like to dual wield gangtags

~Coxy posted:

and there was at least one ring-O cold boot vulnerability

Midjack posted:

had some real problems if you didn't defragment it very carefully too

ymgve posted:

spoiler: it was your dads porn

cheese-cube posted:

that plus the RSA conference goatse are gold-medal goatses

OSI bean dip posted:

imagemagick allowed me to make huge.jpg back in 2001

BeOSPOS posted:

I use base5318008

Crust First posted:

i've always preferred base675309 (base675309)

Shaggar posted:

I did my CMS security awareness cbt!!! check out security man here 2 protect your cyber

anthonypants posted:

at the end of the conversation it looks like the cloudflare guy is trying to recruit him but the way he starts off makes him seem like an incredibly smug rear end in a top hat https://twitter.com/grittygrease/status/728253015719743488