Aleksei Vasiliev posted:

http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html
Update - April 1: As a result of a joint investigation of the events surrounding this incident by Google and CNNIC, we have decided that the CNNIC Root and EV CAs will no longer be recognized in Google products. This will take effect in a future Chrome update. To assist customers affected by this decision, for a limited time we will allow CNNIC’s existing certificates to continue to be marked as trusted in Chrome, through the use of a publicly disclosed whitelist. While neither we nor CNNIC believe any further unauthorized digital certificates have been issued, nor do we believe the misissued certificates were used outside the limited scope of MCS Holdings’ test network, CNNIC will be working to prevent any future incidents. CNNIC will implement Certificate Transparency for all of their certificates prior to any request for reinclusion. We applaud CNNIC on their proactive steps, and welcome them to reapply once suitable technical and procedural controls are in place.

quote:

　　On March 24th, some media reported Google's accusation that CNNIC has issued certificates for the Man-in-the-Middle (MITM) attack. In response to this report, CNNIC has the following Clarification.
　　1.CNNIC has not issued any certificate for the MITM attack. Google’s online security blog has not accused CNNIC for issuing certificates for the MITM attack either. Reports made by some media are inconsistent with the facts.
　　2.MCS, a server certificate partner of CNNIC, has confirmed that the sub-ordinate certificates improperly issued were only used for internal tests in its laboratory, which is a protected environment.
　　3.CNNIC has revoked its authorization to MCS on March 22nd.
　　4.CNNIC reserves the right to take further legal actions.

uncurable mlady posted:

this sold me on cyber to wizard

Rahu posted:

All of their announcements are actually pretty good

http://www1.cnnic.cn/AU/MediaC/Announcement/201503/t20150325_52019.htm


They aren't mitm certs, they're improperly issued certs.

anthonypants posted:

is there a legitimate need for a CA to issue *.google.com in an internal environment against their external CA chain

anthonypants posted:

is there a legitimate need for a CA to issue *.google.com in an internal environment against their external CA chain

Optimus_Rhyme posted:

ok so I'm working on some research for NJE and wanted to share before i write some long rear end blog post

NJE basically lets mainframes 'trust' each other to send jobs/commands between them. You setup the same configuration with node names and IP addresses on all your mainframes and they all talk to each other. In all the examples in the documentation there's no security enabled, despite there being lots of options.

So, in the config you declare systems like:

Node 1: YOSPOS1, 10.10.0.10
Node 2: YOSPOS2, 10.10.0.11
Node 3: YOSPOS3, 10.10.0.12
etc

When using TCPIP (some places may still use SNA, whatever) you send an initialization record like so:



Notice the RIP and OIP. Those are supposed to be the IP addresses above.

So you would send something like:

OPEN YOSPOS1 10.10.0.10 YOSPOS2 10.10.0.11

meaning 'open a connection between me (yospos1) and you (yospos2)'. Once it connects you can send jobs, run console commands, etc, as a system account.

In testing I've discovered that those IP addresses don't mean dick. So long as I can figure out the names of your nodes (hint: it's probably the LPAR names) I can gently caress with your system.

So basically, in python, i craft a packet that says "OPEN YOSPOS1 1.2.3.4 YOSPOS2 4.3.2.1' and it connects me just fine.

Why? Because despite the config implying it will only accept connections from those IP addresses, those IP addresses are for outgoing connections and any IP address can use a node name for incoming NJE connections.

There's also hilarity like no error recovery. If I make a packet with your IP address and send it in with the wrong sequence number it just disconnects the whole thing.

Mainframes: The most secure platform in your enterprise (tm)

Captain Foo posted:

do the security options defeat this attack, or are you demonstrating that the insecure mode is in fact insecure

quote:

The TL;DR is that based on this audit, Truecrypt appears to be a relatively well-designed piece of crypto software. The NCC audit found no evidence of deliberate backdoors, or any severe design flaws that will make the software insecure in most instances.

That doesn't mean Truecrypt is perfect. The auditors did find a few glitches and some incautious programming -- leading to a couple of issues that could, in the right circumstances, cause Truecrypt to give less assurance than we'd like it to.

For example: the most significant issue in the Truecrypt report is a finding related to the Windows version of Truecrypt's random number generator (RNG), which is responsible for generating the keys that encrypt Truecrypt volumes. This is an important piece of code, since a predictable RNG can spell disaster for the security of everything else in the system.

The Truecrypt developers implemented their RNG based on a 1998 design by Peter Guttman that uses an entropy pool to collect 'unpredictable' values from various sources in the system, including the Windows Crypto API itself. A problem in Truecrypt is that in some extremely rare circumstances, the Crypto API can fail to properly initialize. When this happens, Truecrypt should barf and catch fire. Instead it silently accepts this failure and continues to generate keys.


This is not the end of the world, since the likelihood of such a failure is extremely low. Moreover, even if the Windows Crypto API does fail on your system, Truecrypt still collects entropy from sources such as system pointers and mouse movements. These alternatives are probably good enough to protect you. But it's a bad design and should certainly be fixed in any Truecrypt forks.

In addition to the RNG issues, the NCC auditors also noted some concerns about the resilience of Truecrypt's AES code to cache timing attacks. This is probably not a concern unless you're perform encryption and decryption on a shared machine, or in an environment where the attacker can run code on your system (e.g., in a sandbox, or potentially in the browser). Still, this points the way to future hardening of any projects that use Truecrypt as a base.

Optimus_Rhyme posted:

Progressive JPEG posted:

i'm the OHOST, someone else can be

Captain Foo posted:

yeah i'm p sure goog is in the right here

Jonad posted:

it's crazy because CCNIC is apparently a state-affiliated regulatory agency. maybe beijing's new censorship tactic is to make the country's network infrastructure so malware-laden and corrosive to the infrastructure of the internet that the whole country gets blacklisted lol

Jonad posted:

it's crazy because CCNIC is apparently a state-affiliated regulatory agency.

Rooney McNibnug posted:

barf and catch fire

uncurable mlady posted:

im R

Jonad posted:

it's crazy because CCNIC is apparently a state-affiliated regulatory agency. maybe beijing's new censorship tactic is to make the country's network infrastructure so malware-laden and corrosive to the infrastructure of the internet that the whole country gets blacklisted lol

Subjunctive posted:

everything in China is state-affiliated

Luigi Thirty posted:

type R!?

Optimus_Rhyme posted:

Wild EEPROM posted:

r kelly

Captain Foo posted:

badass

Captain Foo posted:

badass

Wild EEPROM posted:

r kelly

Rufus Ping posted:

lol

Jonad posted:

lol

http://kamil.hism.ru/posts/about-vrg-and-delete-any-youtube-video-issue.html posted:

In YouTube Creator Studio I investigated how live_events/broadcasting systems works. I wanted to find there some CSRF or XSS issues, but unexpectedly discovered a logical bug that let me to delete any video on YouTube with just one following request:

code:

POST [url]https://www.youtube.com/live_events_edit_status_ajax?action_delete_live_event=1[/url]

event_id: ANY_VIDEO_ID
session_token: YOUR_TOKEN

In response I got:

code:

{
  "success": 1
}

And the video got deleted!

anthonypants posted:

anthonypants posted: