|
OSI bean dip posted:Isn't there a limit to the number AD users and groups? not really. you don't want any one object enrolled in too many groups because you can have problems with the tokens becoming too large but at the end of the day its just a database and you can scale that thing like crazy just throw more hardware at it
|
# ? Jan 23, 2017 20:07 |
|
|
# ? May 17, 2024 18:44 |
|
spankmeister posted:Also while Azure AD would be a decent choice, price concerns notwithstanding, Australian citizens might object to hosting their PII in the US or on systems possibly controlled by a US company under the Patriot Act. MS has gotten pretty good about being able to make guarantees that your tenant will only be hosted out of the geographic area you specify and considering the relatively small amount of bandwidth going in and out of that country I would have to imagine there's already a substantial datacenter presence in the country. higher ed does similar things with guarantees that they're tenant will only be hosted inside the continental US
|
# ? Jan 23, 2017 20:10 |
|
BangersInMyKnickers posted:MS has gotten pretty good about being able to make guarantees that your tenant will only be hosted out of the geographic area you specify and considering the relatively small amount of bandwidth going in and out of that country I would have to imagine there's already a substantial datacenter presence in the country. higher ed does similar things with guarantees that they're tenant will only be hosted inside the continental US
|
# ? Jan 23, 2017 20:40 |
|
For a while I think the top limit was like 2 billion RIDs ever issued but most large companies who even have to consider planning for that sort of thing have moved past AD 2003 or whatever.
|
# ? Jan 23, 2017 20:46 |
|
There were probably hacks to increase it though even back then.
|
# ? Jan 23, 2017 20:47 |
|
anthonypants posted:plus if microsoft can get them to build a datacenter in aus, or get the government to give them huge waivers on taxes/whatever for that datacenter, it will be a win for microsoft would also be a great way to pivot into getting way higher priority on any future government contracts
|
# ? Jan 23, 2017 21:00 |
|
Same
|
# ? Jan 23, 2017 21:21 |
|
Subjunctive posted:https://www.extremetech.com/internet/243202-symantec-caught-improperly-issuing-illegitimate-https-certificates test korea best korea
|
# ? Jan 23, 2017 22:03 |
|
eta to *.webex.com xss: https://bugs.chromium.org/p/project-zero/issues/detail?id=1096
|
# ? Jan 23, 2017 22:24 |
|
Wiggly Wayne DDS posted:eta to *.webex.com xss: https://bugs.chromium.org/p/project-zero/issues/detail?id=1096 quote:the user must click OK for code execution to happen oh that's fine then
|
# ? Jan 23, 2017 22:35 |
|
Subjunctive posted:oh that's fine then I mean what kind of idiot would just click ok on whatever box popped up?
|
# ? Jan 23, 2017 23:03 |
|
mod saas posted:test korea best korea
|
# ? Jan 23, 2017 23:07 |
|
mod saas posted:test korea best korea
|
# ? Jan 23, 2017 23:10 |
|
Subjunctive posted:oh that's fine then
|
# ? Jan 23, 2017 23:29 |
|
Wiggly Wayne DDS posted:an argument's brewing over there
|
# ? Jan 24, 2017 00:24 |
|
Wiggly Wayne DDS posted:an argument's brewing over there if someone's arguing that one-click exploit deployment is ok, I'm not sure I want to read it
|
# ? Jan 24, 2017 00:34 |
|
I look forward to reading more about how this plays out in the webex thread
|
# ? Jan 24, 2017 00:37 |
|
it fizzled out, no one's saying that yet
|
# ? Jan 24, 2017 00:38 |
|
Pretty sure no-one thinks this is a good fix for the issue, but if the developer thinks they've addressed it sufficiently then it makes sense to release the details so everyone else can make up their mind about it. I mean, what's the alternative? Say "we don't think your fix is good enough" followed by ... releasing the details after 90 days because the developer is happy with their solution and hasn't done anything more?
|
# ? Jan 24, 2017 00:47 |
|
lmao it doesn't even warn you that it might not be starting a meeting. the correct solution is to sign and verify whatever the meeting package is so you don't have some goofy url based filtering at all.
|
# ? Jan 24, 2017 00:51 |
|
Jabor posted:Pretty sure no-one thinks this is a good fix for the issue, but if the developer thinks they've addressed it sufficiently then it makes sense to release the details so everyone else can make up their mind about it. This is correct.
|
# ? Jan 24, 2017 00:53 |
|
it looked from the bug that Tavis just said "good work Cisco, that was fast" rather than "uh, no, that's still bad", so we don't know what Cisco would have done with the remaining 75+ days in the disclosure window
|
# ? Jan 24, 2017 00:57 |
|
did cisco say that it was a temporary fix until they came out with a real one? cause if that's what happened then it would make sense to give them the full timeline since their intention is a real fix.
|
# ? Jan 24, 2017 00:58 |
|
why do I keep raving about eyepyramid's string encryption? because you see, it's actually quite interesting. let's take the typical encrypted string:C# code:
C# code:
C# code:
and remember, you heard it first here: it's a Dead Gay Forums Exclusive™ - Where Your Count hackbunny fucked around with this message at 05:19 on Jan 24, 2017 |
# ? Jan 24, 2017 03:02 |
|
hackbunny posted:a Dead Gay Forums Exclusive Never stop please, these are always interesting
|
# ? Jan 24, 2017 03:23 |
|
fuckin cool
|
# ? Jan 24, 2017 03:24 |
|
yeah these posts are really interesting hackbunny, and clearly enough explained that even a security know-nothing like me can follow
|
# ? Jan 24, 2017 03:39 |
|
big scary monsters posted:yeah these posts are really interesting hackbunny, and clearly enough explained that even a security know-nothing like me can follow
|
# ? Jan 24, 2017 04:18 |
|
Volmarias posted:Never stop please, these are always interesting
|
# ? Jan 24, 2017 04:22 |
|
huh it was quick, I wonder what I was getting wrong the first time. as I mentioned, the "carrier" type of agent uses a different master key to decrypt its sensitive strings. since the master key is derived from a number of runtime checks, and only one set of outcomes is the correct one (i.e. it allows the decryption of strings that allow the malware to work), we can deduce a little bit more about the purpose and operation of the malware. specifically, the master key is derived from an array of booleans, filled thus:C# code:
|
# ? Jan 24, 2017 04:40 |
|
Volmarias posted:Never stop please, these are always interesting
|
# ? Jan 24, 2017 04:52 |
|
|
# ? Jan 24, 2017 04:54 |
|
Volmarias posted:Never stop please, these are always interesting
|
# ? Jan 24, 2017 05:03 |
|
the licensed mail library is so loving weird
|
# ? Jan 24, 2017 05:11 |
|
hackbunny posted:[*]IsBuildOlderThan20150211: false. what a weird check! it compares two static dates: the build timestamp encoded in the version number, and february 11th, 2015 (the next day). always evaluates to false, regardless of when, where and how the code is executed. very confusing Bhodi fucked around with this message at 05:24 on Jan 24, 2017 |
# ? Jan 24, 2017 05:21 |
|
hackbunny posted:
makes it harder to change the date just to see how the behavior changes or get the date-based behavior you want? why the autorun checks? do analysis tools like to just use windows autorun to start the malware in the VM? seems like a bad idea if its so easy to spot but I guess most investigators won't think to sit there and twiddle their thumbs just in case so eh
|
# ? Jan 24, 2017 06:02 |
|
Munkeymon posted:why the autorun checks? do analysis tools like to just use windows autorun to start the malware in the VM? seems like a bad idea if its so easy to spot but I guess most investigators won't think to sit there and twiddle their thumbs just in case so eh Sounds like the opposite; starting it manually to see what it does would result in nothing if "true" was the expected value here.
|
# ? Jan 24, 2017 06:45 |
|
Bhodi posted:I suspect this is a check to short-circuit similar to RunningInVMAndApplicationOlderThan5Days to prevent 'dev' builds (built after the hard-coded feb 2015 date) executing automatically. It's a way to pin auto-execution to only code that has (presumably) been tested to work in the build-test vm framework and prevent auto-execution for newer code, though it's a really wacky way it do it. I could see doing it this way if you have some sort of framework that you use for both development of new features and testing of the operation of mature ones, and your build system inserts that date into the code based on last tested-good configuration (or you alter it manually). Same. With the auto incrementing build numbers, this smells of someone being too clever by half.
|
# ? Jan 24, 2017 06:48 |
|
hackbunny posted:and remember, you heard it first here: it's a Dead Gay Forums Exclusive™ - Where Your Count
|
# ? Jan 24, 2017 08:13 |
|
|
# ? May 17, 2024 18:44 |
|
This analysis is wonderful, thanks for posting it. The use of a paid for library implies for me that more than one person was developing this, and the second less experienced person probably just picked up a library for sending mail that they had used in a previous legitimate project without realising it was tied to their personal details. It seems impossible to believe that someone who was so deep into illegal activity wouldn't simply pirate a copy of the library (or if it was the more experienced developer, I'm sure they would be capable of interacting with the email protocol directly or at least using an open source alternative) I guess there wasn't any information released about how long ago the license for the mail library was purchased vs when the malware first included it? I expect the dates will be some time apart. Bhodi posted:I suspect this is a check to short-circuit similar to RunningInVMAndApplicationOlderThan5Days to prevent 'dev' builds (built after the hard-coded feb 2015 date) executing automatically. It's a way to pin auto-execution to only code that has (presumably) been tested to work in the build-test vm framework and prevent auto-execution for newer code, though it's a really wacky way it do it. I could see doing it this way if you have some sort of framework that you use for both development of new features and testing of the operation of mature ones, and your build system inserts that date into the code based on last tested-good configuration (or you alter it manually). I guess if you hit F5 accidentally in visual studio and the code runs, this will prevent any damage unless you've just set the hardcoded date to the following day in order to finalise the build. Things like this make me laugh because they almost certainly mean they accidentally did this once then added this weird check to prevent it from happening again. Chalks fucked around with this message at 09:54 on Jan 24, 2017 |
# ? Jan 24, 2017 09:50 |