cheese-cube posted:

same but only about 1 year ago. we're going to 2012 domain functional in a couple of weeks!

anthonypants posted:

update: we are not going to raise the forest/domain functional level tonight because it is end of month AND end of quarter so i won't be able to change anything at all on the servers for about three more weeks. oh well~

cheese-cube posted:

again, same. hazard a guess: you've got a SAP environment in-house?

anthonypants posted:

nope it's all oracle

cheese-cube posted:

edit: double if you're using middleware like primavera or whatever the garbagefires are called!

ymgve posted:

https://www.reddit.com/r/technology/comments/4q8ywp/til_that_someone_can_change_your_facebook_email/

tldr: facebook support will remove any protection on an account and give a hacker access as long as their fake ID is convincing enough

anthonypants posted:

no we're just using oracle. it's awful because the two other it people don't know anything about linux and actively try to do as little as possible with them, so they're all managed by the oracle contractors. we have about 50 linux servers doing various things but no one patches them and everyone logs on as root and there's gnome vnc sessions running as root and it's a huge garbage fire

wyoak posted:

The really dumb part is that 'convincing enough' is apparently just the name, birthday and stuff was wrong. Although I'm not sure how Facebook would know that stuff in the first place if you don't supply it to them ahead of time....I'm not sure how FB should handle something like this. Require proof of identity when opening a business page?

Perhaps not allowing requests like this from Pakistan for businesses in Michigan

cheese-cube posted:

1000xSAME. our DBAs are expected to support ODAs but only one of them knows linux. que me getting called in at 5AM one morning because the on-call DBA had been on the phone to oracle all night (it was a kvm fault, just needed restarting in correct order).

biggest sec-gently caress: our customer has been approving RHEL builds without maintaining entitlements. none of them are or can be patched. our senior secops guys asked me yesterday whether we can just patch from centos repos...

anthonypants posted:

we have a "production" dr server on rhel 5.10 in a xen vm when our actual production server, i think, is on centos 6.6 in a vmware vm. our server documentation is a excel spreadsheet that for linux servers says "linux" as the os and most of them have don't have a role defined. like there's a "PROD" and a "PROD (not in production yet)", and it's a nightmare

Blinkz0rz posted:

e: everything is behind a private subnet with restrictive security groups. it's more a question of how to federate access to secrets in such a way that they're not available to all apps, including those that might not need them. case in point, we have a service that needs cassandra credentials and one that needs mysql creds. there's no reason the app that needs c* creds should ever be able to get mysql creds.

anthonypants posted:

here's a sec fuckup: https://www.documentcloud.org/documents/2911707-18917316433.html

https://twitter.com/bradheath/status/747069342345465856

Powerful Two-Hander posted:

try having anything from 3 to 6 non prod environments per app with different names, 2 or 3 different platforms, different release schedules and different levels of support then watch the lols roll in when the project management division demands "complete end to end testing"

anthonypants posted:

we only have dev and test and prod environments and my boss thinks we're going to be able to wash our hands of the entire accounting side and shut down all those servers once they move to oracle's cloud platform and he's just going to insulate himself from the entire thing and farm it out to contractors and i'm going to sit here grinding my teeth

cheese-cube posted:

lol that's exactly what our AMS team said back when we only had DEV, UAT and PROD. look at us now

to contribute: each of the environments is increasingly a secfuck compared to the last. today im going to get our senior secops guy to configure qualys to just scan all poo poo including the "dev" and "test" subnets because lol i idgaf if your server is "UAT" its hitting my infra services kill yourself

spankmeister posted:

It's that time again...


Bekijk de Tweet van @taviso: https://twitter.com/taviso/status/747804671654264834?s=09

spankmeister posted:

It's that time again...


Bekijk de Tweet van @taviso: https://twitter.com/taviso/status/747804671654264834?s=09

wyoak posted:

The really dumb part is that 'convincing enough' is apparently just the name, birthday and stuff was wrong. Although I'm not sure how Facebook would know that stuff in the first place if you don't supply it to them ahead of time....I'm not sure how FB should handle something like this. Require proof of identity when opening a business page?

Perhaps not allowing requests like this from Pakistan for businesses in Michigan

Cocoa Crispies posted:

use PKI to allocate, rotate, and revoke per-instance client certificates; auth secrets don't move over the network, each client can be revoked or rotated independently, and your server config can be just validate clients are signed by the CA and acceptable by OCSP

Powercrazy posted:

Maybe not using facebook as an ecommerce page and "caveat emptor" those that are dumb enough to do so?

Powercrazy posted:

Maybe not using facebook as an ecommerce page and "caveat emptor" those that are dumb enough to do so?

Wiggly Wayne DDS posted:

yup:
Symantec: Heap overflow modifying MIME messages

quote:

Symantec attempts to clean or remove components from archives or other multipart containers that they detect as malicious. The code that they use to remove components from MIME encoded messages in CMIMEParser::UpdateHeader() assumes that filenames cannot be longer than 77 characters.

This assumption is obviously incorrect, names can be any length, resulting in a very clean heap overflow.

The heap overflow occurs because Symantec does the cleaning in multiple stages, first changing the Content-Type to "text/plain", then changing the filename to "DELETED.TXT". The problem is that during the first stage of this process, they maintain the existing name but use a buffer prepared for the final name.

Number19 posted:

wtf

Applebees posted:

They posted a writeup about some of the Symantec vulns

quote:

On Linux, Mac and other UNIX platforms, this results in a clean heap overflow as root in the Symantec or Norton process. On Windows, this results in kernel memory corruption.

Because Symantec uses a filter driver to intercept all system I/O, just emailing a file to a victim or sending them a link to an exploit is enough to trigger it - the victim does not need to open the file or interact with it in anyway. Because no interaction is necessary to exploit it, this is a wormable vulnerability with potentially devastating consequences to Norton and Symantec customers.

An attacker could easily compromise an entire enterprise fleet using a vulnerability like this. Network administrators should keep scenarios like this in mind when deciding to deploy Antivirus, it’s a significant tradeoff in terms of increasing attack surface.

COACHS SPORT BAR posted:

Lol this is older but I must have missed it. This was the sandbox escape ormandy discovered in bromium:

https://twitter.com/taviso/status/741063403985240064

wyoak posted:

I'm confused on how

Applebees posted:

They posted a writeup about some of the Symantec vulns

quote:

Symantec dropped the ball here. A quick look at the decomposer library shipped by Symantec showed that they were using code derived from open source libraries like libmspack and unrarsrc, but hadn’t updated them in at least 7 years.

invision posted:

anyone else wanna go with me to get tavis tattoos?

MiniFoo posted:

MiniFoo posted:

Wiggly Wayne DDS posted:

you missed the best part: first time a poc was sent to them it crashed their mail servers as they were actively scanning incoming attachments