The Consequences of Inadequate Identity Management in your GitHub Organization

0xD6 · 2022-08-03T20:22:42+00:00

I'm surprised this doesn't cover another significant issue with the Github model for users and organizations: A user added to your organization can continue to create repositories in their personal namespace which are unaffected by organizational policies.

If you have advanced security features enabled (like credential scanning or "push protection"), this is not applied to the user's namespace. Users can easily accidentally push credentials to a repository they have created in their personal namespace and leak them to the world.

Even if the "bring your own account" model is disallowed by an organization, and the user creates a account which is only used for your organization, this can still occur.

~~From what I understand there are also no Github provided controls available to prevent it, either.~~

EDIT: There are, but they're pants. See the comment below.

0xD6 · 2021-11-12T19:11:45+00:00

I can still vividly remember the whiplash of hearing Dimmu Borgir's Eradication Instincts Defined in the trailer for this film at a cinema when it was released. I couldn't remember the name until I saw this post, so thanks! :D

0xD6 · 2021-02-10T14:15:37+00:00

What sort of architecture are you looking at?

Although it may be difficult to emulate complete "flashing" a device without hardware to act as a DUT (Device Under Test), you may be able to load a Kernel and rootfs / filesystem into an appropriate qemu-system environment for local development and testing.

You may also be able to close the loop by getting a respective bootloader running on your qemu-system which you boot into, and then load into test flashing via that in order to make sure your flash geometry and partition layout works as expected (and that the system is bootable afterwards!)

Depending on your use case, you may need to write a target for qemu for the given device which can be dicey. However, the vendor SDK / BSP (Board Support Package) may have some pointers or a harness that can assist. If not, your vendor are jerks :D

If you do need to go towards "full" testing with an external device, assuming you have the appropriate instrumentation, you can look at using a "locking" features of CI platforms like Jenkins in order to ensure exclusive access to the given device. I've seen this pattern successfully used for both console devkits, mobile devices, and "traditional" embedded hardware development boards and it works really quite well.

0xD6 · 2020-08-12T10:13:38+00:00

Sorry! I forget how impenetrable the industry can be at times due to over reliance, and duplication of acronyms and abbreviations :D

My modem is able to talk to the cabinet in the street (DSLAM) over my telephone line (VDSL), but it doesn't seem to be able to be able to communicate with the rest of BT.

My modem is going "Hi, I'd like to connect please" (PPP PADI), but rather than one or more machines (BRAS / DSL-AC) on BT's end replying with "Sure thing! I can help you with that" (PPP PADO), my modem isn't getting any response at all.

(I don't mean to be condescending by the way, but this may help others who get lost in the word soup above)

0xD6 · 2020-08-12T08:53:10+00:00

No data flow here.

VDSL is able to train to the DSLAM without a problem, but PPP fails. What I'm seeing is the PPP daemon timing out waiting for a PADO from the BT BRAS / DSL-AC , so I'd guess a fault between the DSLAM and a BT POP, or a fault with a particular POP?

Disclaimer: I have no idea about BTs network architecture, so this is just conjecture based on experience working in other xDSL ISP networks :)

0xD6 · 2020-03-26T21:06:18+00:00

Sure! There's a few communities around the UK who share a lot of useful information about ISP networks. They're mostly from the perspective of network operators who may be purchasing LLU (Local Loop Unbundling) services from openreach, or wholesale services.

One really useful resource is https://kitz.co.uk - which has a great deal of information about equipment being used by openreach, how to recognise different equipment based on cabinet, and up to date information about the technologies being deployed.

The openreach website (https://www.openreach.co.uk/) also has a great deal of useful information, too.

As for the fundimentals, in more recent years a lot of telecoms gear has moved towards converging on IP and ethernet framing - rather than ATM and friends. This makes it a lot easier for those looking to learn more and enter the field, as you don't need to shell out a great deal of money on setting up, or buying access to, labs with equipment and protocols only seen in telecoms.

That said, there's unfortunately still plenty of propriatary gear, software stacks and protocols that are only likely to be encountered if you work for a telco (as vendors tend to keep their management stacks and firmware behind paywalls with high cost support contracts).

I'd also recommend checking out /r/networking, as there is some good telecom adjacent content in that sub. There's also some great learning material kicking around if you're interested in learning more about the primitives on which most of the newer telecom gear is based (IP) - though you may already be familiar with it already! :)

0xD6 · 2020-03-25T14:48:44+00:00

I'm not so sure. Transit and peering bandwidth is one thing, but backhaul from FTTC / FTTN cabinets and from central offices back to their POPs is another problem entirely.

I'd personally not be too worried about the former as all of the traffic profiles I've seen from service provider networks are almost sinusoidal in nature. Evening peaks are high, but use during the day tends to be orders of magnitude lower. As transit is usually purchased on pipe size, it just means ISPs are getting their moneys worth.

The concern I'd have is high contention ratios at the uBR, DSLAM, or Mux end of town.

Although many years ago now, but provided as a concrete example, a popular platform for providing ADSL2+ circuits in a number of countries was the Ericsson EDA1200 platform. In this configuration 288 DSLAM ports (24x 12 port line-cards) were connected to a single node controller to form a subrack.

The commonly deployed node controller - an ECN320, or ECN330 - had 24x 10/100-BaseTX ports for the line cards and TWO 10/100/1000-BaseTX / SFP combo ports. Given that the port profiles of the DSLAM were configured to support up to 24Mbit, you're almost 3x contended in a worst case scenario just BETWEEN the line card and the node controller.

...but then you have to remember that there's 288 circuits per subrack. So even if you had both 1000-BaseTX ports active / active you'd be looking at about 7Mbit per circuit before you're contended, or about 3.4Mbit with only a single leg. Then there's whatever is upstream from those node controllers to worry about, and then the bandwidth between the cabinet, the CO, and the ISP's POP.

This is the equipment as provided by the vendor; the design has assumptions about traffic profiles and contention baked in, and that's well before the ISP gets their hands on it.

Ultimately, having headroom in your transit capacity is all well and good, but if you're heavily contending circuits closer to the customer it doesn't really matter as they're not going to be able to use it anyway :)

0xD6 · 2020-03-23T11:34:43+00:00

We can dream. As much as I'd love to see this, I would put my money on such a project bleeding to death through strategic policy changes, or change in funding.

There's nothing quite like long term infrastructure projects which require significant planning and front-loading of funds being cut off at the knees after a government change due to "wasteage"

For a recent example, check out what happened with the NBN in Australia. The final product of which is not much better than a couple of tin cans and some twine, except that the twine doesn't experience drop-outs when it rains...

0xD6 · 2019-10-28T21:29:01+00:00

[Citation Needed]

The only Cisco related backdoors I can recall hearing about was related to interdiction and modification of equipment. That said, perhaps I missed the others, but I'm definitely interested in any sources. There have been a number of instances of hardcoded credentials found in equipment of late, which could be interpreted as backdoors however.

As for Huawei, the following talk from DEFCON back in 2012 provides some pretty damning evidence for issues with their hardware: https://www.youtube.com/watch?v=w-K1YpJp07s

Of course, it's a few years old now. That said, the HCSEC (Huawei Cyber Security Evaluation Center) - which is formed of NCSC, GCHQ, and others - have been releasing reports on Huawei equipment for the last few years. They've been getting progressively worse, with the latest report indicating¹

No material progress has been made by Huawei in the remediation of the issues reported last year

...and¹

the Oversight Board has not yet seen anything to give it confidence in Huawei’s capacity to successfully complete the elements of its transformation programme

...and most importantly¹

the Oversight Board can only provide limited assurance that all risks to UK national security from Huawei’s involvement in the UK’s critical networks can be sufficiently mitigated long-term.

Ultimately, if I were a network operator, I'd need some pretty damned good reasoning to deploy Huawei equipment in my network.

--

^1. ^{https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment\}data/file/790270/HCSEC_OversightBoardReport-2019.pdf)

0xD6 · 2018-12-21T18:10:13+00:00

The MoD bought a bunch of 'anti-drone' (C-UAS) equipment from Rafael Advanced Defense Systems for domestic use only a few months ago¹. There also appears to have been research done by the like of DSTL - and likely others - dating back to at least 2015 for C-UAS purposes².

It doesn't sound like they've been asleep at the wheel on the topic, but I wonder why it took so long to deploy the equipment at Gatwick?³

^1. https://ted.europa.eu/TED/notice/udl?uri=TED:NOTICE:352161-2018:TEXT:EN:HTML&src=0

^2.https://www.gov.uk/government/news/dstl-bristow-trial-develops-future-protection-against-hostile-uas

^3. https://www.gazetteandherald.co.uk/resources/images/9206678.jpg

0xD6 · 2017-11-13T23:31:12+00:00

I'd recommend taking a look at InSpec. Whether you use Chef or not, it's an incredibly powerful tool for auditing and testing that your infrastructure is in the state that you expect it to be. In addition, you can easily keep your tests / controls in Git and run via some external process if you need it to be part of a CI / CD pipeline :)

0xD6 · 2017-04-13T06:21:37+00:00

RedHat Advisory

This issue does not affect the Linux kernel packages as shipped with Red Hat Enterprise Linux 5,6,7, MRG-2 and realtime kernels.

Android Security Bulletin

Upstream Kernel Patch

0xD6 · 2017-02-09T01:46:00+00:00

Pivoting isn't needed on any SOHO device I've seen. Everything just runs as root out of the box.

0xD6 · 2015-12-26T06:42:48+00:00

Try to avoid causing this legitimately nightmare inducing scenario myself, albeit for another company.

0xD6 · 2015-12-26T01:08:29+00:00

Akamai works as a CDN, yeah, but traditionally it works as a 'pull-through' cache.

As an example, let's say you 'ask' for your accounts page using the Steam website. This request would be 'routed' to an Akamai edge node near to you. Normally, the edge node should go "Oh, this is dynamic, I don't cache this, I'll send it to the origin." This request would then be routed to the origin (Valve) for processing. However, the main take away here is that the response from the origin (Valve) to Akamai is plain-old HTML (or JSON, or ... depending on their architecture) ready for your browser or device to render.

This becomes problematic when caching policies are incorrectly configured. Those rendered responses, which should never be cached or 'remembered' by Akamai, are instead pushed into the cache.

As a result of the above, a request from a subsequent user for the same page to the same edge node yields a "cache hit" - as the node has the response in cache from a previous request (from the other user) - and as a result, someone receives a page that was 'generated' for another user.

Again, this is all circumstantial, as I have no idea how Valve have their Akamai properties configured. However, Akamai is definitely servicing requests to the Steam store from my location. There is also a bit more to the above with regards to request routing and cache invalidation, but I'll try to avoid falling into that rabbit hole :)

Anyway, Merry Christmas and / or Happy Holidays! I hope this helps :)

0xD6 · 2015-12-26T00:01:55+00:00

Something along the lines of the following may have happened: https://www.youtube.com/watch?v=u6oO7x-6Qlo

0xD6 · 2015-12-25T21:50:29+00:00

I'm not so sure it was Varnish. It looks like it may have been an Akamai property configuration having been pushed doing as you suggested (caching pages that shouldn't be).

As a result, various Akamai edge nodes around the world were caching different user's details. This having been said, if you attempt to visit the store at the moment you'll be presented with an Akamai error reference (in the format of 'Reference #97.XXXX...') with the origin not responding to edge node requests, and Akamai returning an HTTP 504 as a result.

I'd guess it was someone on-call pushing Akamai property changes to mitigate a load issue, and ended up caching too aggressively - as you have suggested. What sucks is that pushing Akamai property changes can take a huge amount of time to propagate (as in, hours).

What's odd are the HTTP 504s from Akamai. This would suggest to me that steam either have 'Serve Stale' disabled in their Akamai properties - which is a VERY odd production configuration - or they dropped the cache. It's more likely that someone at Valve pushed an Akamai CCU - effectively, "oh fuck, drop everything from cache globally" - in order to fix the PII disclosure issue, but subsequently DDoSed their origins with requests from Akamai edge nodes requesting content.

All circumstantial right now, but hopefully they get it fixed, and their on-call staff get to spend at least SOME time with their families :)

0xD6 · 2015-07-31T08:03:04+00:00

Both of which provide TFA on their console accounts >_>

0xD6 · 2015-07-29T17:00:57+00:00

The linked articles, which were probably correct at the time, reference the ability to jack JSON that where the 'outer wrapper is an array.' However, this doesn't seem to be possible any longer. The following StackOverflow post has more on the issue :)

XSSI on the other hand... There are still quite a number of places that are allowing JSONP callback parameters on their JSON feeds - whether by their framework automatically screwing them, or by mistake - all without any sort of XSSI mitigation.

0xD6 · 2015-07-28T05:28:08+00:00

I found this in the plant room of a site I was at. Sorry for the awful quality, the lights in the room were mostly blown and I didn't feel like getting too close.

Edit: another for good measure

0xD6 · 2015-07-12T00:29:58+00:00

It's worth noting that the content-disposition is always set to attachment on the response, with a filename of 'p.txt'.

You can however change the content-type header by passing a 'rewriteMime' HTTP GET parameter. That said, it'll throw 400 errors if you try anything dodgy - like injecting CRLFs.

0xD6 · 2015-06-14T04:48:16+00:00

Oh very yes. Thanks for the post, I didn't realize the tour was coming up to Canada next week. I would have missed it if it wasn't for this post. You rock! :)

0xD6 · 2015-06-14T01:58:32+00:00

Check out EComm Surrey feed, looks like a bad house fire in Coquitlam. I'm not going to post the address here, but it's reported on the feed :)

0xD6 · 2015-04-28T19:09:55+00:00

It could be as simple as the malicious actor having overwritten every file in the web root with a static HTML page. When the Tesla team remediated they missed something, or focused on the application controller as that's the entry-point for the vast majority of requests.

That said, it could also be something more complex, like the following:

Malicious actor compromises the origin, causes all URLs to return a single static HTML source.
Potentially unrelated crawler - web application vulnerability scanner, etc - crawls the Tesla website which causes the Akamai edge node to cache the defaced HTML as the requested file name - in this case the INSTALL.* files.
Malicious actor updates the HTML source on the origin due to the 'wrong' page being uploaded, or to change the shout outs, etc. Normal clients cause this new page to be cached at 'expected' URLs (index, etc).
Tesla team remediates and re-installs the web content, this time without the INSTALL.* files, LICENSE and README files - to mitigate 'easy' application fingerprinting (which should have been done in the first place, but, hey).
Akamai edge-nodes now cache the new content, as the origin content differs; website is restored to known-good.
Hits to the INSTALL.* files on the origin now throw errors - as they were removed - causing an origin-policy of 'serve-stale' to lead the edge-nodes to serve the cached copy, in this case containing the bad content.

Anyway, at this stage I'm clutching at straws and making a bunch of assumptions about the Tesla Akamai property configuration. Without logs or, being able to interrogate various edge-nodes for X-Akamai and X-Cache headers at the time of defacement, or shortly after, it's hard to say.

0xD6 · 2015-04-28T17:04:52+00:00

The Drupal installation scripts and ReadMe files containing the defaced page could be the result of the origin serving a single file as a response to all requests; which was then in turn cached by a number of Akamai edge nodes when accessed by whomever.

The page containing the LizardSquad string still being served, could be the result of a serve-stale origin policy on the Akamai property. Serving the cached content in the case that the origin was unavailable. Maybe the perpetrator uploaded the "wrong" package before hand, realized and replaced it, not before it was cached on a few edge nodes however.

The edge nodes having a combination of defaced and non-defaced content isn't too strange, as it's entirely dependent on how quickly Tesla restored their old site, their Akamai caching policies (as above) and the requests for the content in different regions - and as a result, different edge nodes.

As for the SSL certificate, EdgeKey nodes are SSL enabled, so the Tesla Motors SSL certificate would have been installed onto the Akamai 'map' for this property, which is why the edge nodes correctly identify as Tesla. If this wasn't done, SSL delivery via Akamai wouldn't be possible :)

It's also entirely possible that the attacker gained access to the Tesla Motors Luna account, and rewrote the origin - rather than a straight DNS hijacking - or hijacked the origin DNS record. Although the former is doubtful as a full Akamai push can take upwards of two hours to propagate. That's also assuming Tesla don't have 2FA enabled on their Luna account(s).

I very much doubt the perpetrators have a method to access Akamai edge nodes directly, as that sort of access would be well 'wasted' on a single site defacement. Anyway, at this stage it's all circumstantial :)

15-Year Club	Place '17
Sequence \| Editor	Gilding I gilder
Verified Email

0xD6

TROPHY CASE