iViewed your API keys
wale.id.au
wale.id.au
The other stations have all since caught up, but ABC have a tremendous amount of quality children's content so it's a very popular service with families.
However, the current government is not a fan of funding the ABC and as such they've been operating with a very tight and reducing budget for most of the last decade. The edges of their products including interactive news pieces and election/pandemic coverage (and some of these API key issues) are a bit rough but the overall achievement is excellent.
It's not that you've done anything in the slightest bit wrong. It's that others with power can easily make it become wrong with little to no backlash in the current Australian climate.
I understand the desire for recognition, but certainly think twice and at the very least wait until after election season is over in June so tech-illiterate political opportunists don't pounce to martyr you for their own gain.
Would suggest looking into the fall of someone widely recognised like Dr Vanessa Teague, a professor who pointed out government failures in e-voting and claimed health anonymization measures to make up your own mind. One government department finally had enough and she was out, I'm sure it's a lot cheaper than actually fixing the problems raised.
Behind the laid back "beers and beaches" mirage, Australia is an authoritarian country with huge public support for iron fists, this is clear to many.
I can't believe what I just watched.
Apparently the SSNs were embedded in the pages html. The ad makes it sound like a huge reverse-engineering job.
On the other hand, Sky News (the current government’s right wing mouthpiece) would use this as an opportunity to discredit the ABC.
Which is of course a very expansive definition. Think you've found a leaked database credential and you test it before reporting, so as not to create a false alarm? That's illegal hacking. Almost any persistent XSS? That's illegal hacking. Access an admin panel by entering a default password? You guessed it, illegal hacking.
We might get the impression these laws don't exist, because they aren't enforced internationally or if the hacker can't be identified - so black-hat hacking, cryptolockers, tech support scams, giant data breaches and suchlike go completely unpunished. But a white-hat hacker who identifies themselves in hopes of getting their security report taken seriously might well get a visit from the cops.
Without permission to test the security of a system, you shouldn't be trying credentials you've stumbled upon or defaults.
If you randomly try my front door and find that it's unlocked, don't expect me to be thanking you.
Why? If someone tries my front door, doesn't go in but confirms that it is unlocked by opening it by an inch (=verifies the DB credentials but doesn't run any queries) without really peering into my private spaces, then privately reaches out with "hey, hey, your door is not locked - I haven't went in but I know it's unlocked, you may wanna look into this" then I imagine while that could be odd situation (e.g. depending on whenever one has a lawn), I would be grateful and not in the least bit offended.
Surely, I wouldn't be happy if I'd get an alarm that my door is suddenly open (IDS alert) and would react accordingly. But if my door is not locked and I'm not aware and someone responsibly discloses this - I don't see how that'd be an issue.
These arguments about computer crime law are always the same, and people with your view always shoot themselves in the foot with analogies like this. This is not a pre-existing social expectation. If someone comes to my front door, tells me that it’s unlocked, and tells me that they were trying peoples front doors for the intellectual thrill, there is a 0% chance that I’m an reacting positively. I challenge you to find any material proportion of well-adjusted non-nerds that don’t agree with me.
Of course, you have every right to be upset that someone tried to do that to you. But it's clear they don't have bad intentions at least, because they let you know.
Start trying door handles in your neighbourhood and I can guarantee you’ll either be assaulted by an unhappy resident or arrested pretty quickly. It’s not acceptable behaviour however altruistic you believe it to be.
Good luck with things, it was just a warning and hopefully not a dissuasion from continuing on.
https://www.theguardian.com/australia-news/2020/mar/08/melbo...
Tried my best to report (not publicly disclose) it, including asking the front desk for contact information for IT; no response.
I think we're (on HN) often in quite a bubble of being (or striving to be) hot on this sort of thing, or frankly far trickier to exploit sorts of things, when really the bar for a lot of ('IT is a cost centre') stuff out there is extremely low.
I don't think this sort of leak or vulnerability is anywhere near as rare (which isn't even that rare) as it seems - I think an awful lot must just get quietly exploited or go unnoticed. We're only hearing about this one because someone thought it was 'lolz', I didn't publicize the one I noticed (in my normal user behaviour of just trying to book a room!) nor did I see if I could connect to the database and book myself in for free or something. And I only noticed it because it a) experienced an error; b) dumped env vars in the event of an error - i.e. I didn't have to look for it. How many other sites have I used since with similar problems but which just didn't happen to serve it up on a silver platter for me?
No rate limiting on the endpoint, doesn't require auth, didn't block my VPN, doesn't even set cookies (very privacy conscious devs apparently). I could have mined the entire country's data. Insane.
This particular post doesn’t really seem to go into too much depth about what these keys are used for, or the damage that could be done, but I’m erring on the side of ‘meh’ until proven otherwise. It’s freely viewable content if you’re in Australia. They’ve obviously stuffed up on multiple fronts, and my money is on these issues being introduced by an integrator, rather than ABC employee.
Lastly, the ABC is a corporate entity that is fully owned by the commonwealth (and beloved by most Australians) - tue article describes it as ‘state media’, which has sinister propaganda connotations of broadcasters in some other countries.
I’d compare ABC to PBS in America. They both are state media. I think more liberal usage of accurate terms in this way is needed. Folks ought to know who funded and produced the reporting that they consume, especially when it’s those same folks doing the funding. It seems like you’re saying that calling it “state media” is something like spreading FUD, but to object to it being said in neutral terms entirely? I don’t see who benefits from leaving that info out either.
I think the larger issues is these terms being used as dog whistles for propaganda in the first place. Those who have the power to label others as propaganda are not themselves subject to such labeling. Curious.
That doesn't say much either way and isn't relevant - could just be that the propaganda is doing its job.
Is that really what the Australian people want? I'd guess they just don't care either way, but in that case why would the Australian politicians push for that? Canada has a pretty similar apathy towards politics but even then we don't see the government forcing Canadian citizens to implement backdoors or raiding the offices of a broadcaster. (Yes the recent C-36 and C-10 bills are pretty disastrous in that regard but they are very recent and face quite a bit of opposition)
It's such a peaceful country too, so the entire "hard on crime" policy does not make sense to me. Is it a partisan issue in Australia or is it something both parties agree on?
I'm not so sure about the relevance of the so-called "harsh environment" to political culture. Although, it may be said Australians have a more deferential view of certain aspects of politics than other Western countries.
They've been boiling the frog since 9/11. All anybody has to say is "national security" and the opposition party pretty much folds. Imagine the US without the Bill of Rights - that's the landscape.
If I found something like this on a site I don't think I would notify anyone. Too risky. Maybe over TOR if they have a contact page or something. But it is hard to be anonymous these days.
In terms of responding to criticism in the digital realm, you can get a pretty illustrative view of the situation by looking at how the Digital Transformation Office handled feedback to its pile of steaming shit of a coronavirus proximity alert app. Numerous researchers found serious flaws constantly from its first release. It took like 6 months for them to even recognise that any outside researchers had even been helpful, IIRC. Release notes were like "fixed bugs" and then the researchers decompile the .JAR again and say "nope, you absolutely did not fix this huge problem" and then find another one. Meanwhile the government sank millions more dollars into BCG consulting to review it, while these people were working for free and getting no credit. I think their campaign to cast doubt on the app's safety, efficacy and security was successful, and it did not get taken up, and then the report that was due to be published about the project was never released, and it was all swept under the rug. Overall I think it was about $10 million spent for in the vicinity of 5 covid cases identified, I don't remember exactly but I think all of them were also identified by phone interviews.
They did not, however, prosecute the researchers. So, ignorant and unkind, but mostly not like that journalist in the US who enraged a governor to the point of being criminally investigated for opening a webpage.
I've never been there but definitely romanticized the beers and beaches and kangaroos motif. Oh well.
How do you provide your secrets to your apps? Using an external service? That would still require another set of credentials. Using environment variables? A file only the user running the app has access too? Another way?
If you're using API keys to access stuff, you do it on your backend, there's no excuse for that stuff to make it to the frontend.
If your "client" needs access to sensitive API keys, you need to rethink your architecture.
As a (senior) backend software engineer, this reeks of a person/team who doesn't know how to architect and/or implement web applications/software.
However there are two real issues here: first, some bug in the code is causing all environment variables to be dumped into the JS bundle. You can see that in inane keys like PATH, HOME, PORT.
This issue wouldn't be such a huge problem by itself. The second problem is that during the build process for the frontend, there are environment variables that shouldn't be there, such as the secret ones. The CI or build machine should have been well isolated enough to prevent this problem from happening.
This is a problem in the CI coupled with a bad build process.
However the CI shouldn’t have backend-only private variables available to frontend builds… some separation here would be safer regardless of developer mistakes.
I'm honestly wondering who they hired for the job. Because this is one of the most fundamental failings in security I've ever seen.
let me guess: bootcamp graduates? whoever was the cheapest?
If a clients needs an API key I would think to route the requests through the server and add the key information at that point, but I am not a web developer and not sure if that always scales for any use case.
There is no excuse.
It is a well-solved problem to handle secrets; there are better and worse solutions. An environment variable for a server can get exposed if the server is hacked; a secret sent to a client is exposed the second the server goes live. One of these is much worse than the other.
There are also better solutions than environment variables. A competent team would be aware of many options. Whoever coded this is not competent, full stop. It's not that they didn't finish; these services should never have accessed from the client at all.
It sucks for a small team or for anyone who is trying to run a free tier, but terraform plus aws secrets manager or vault works really well. Using a db password as an example, for our app we generate a random password, store it in secrets manager, and our containers on fargate run with an iam role that allows access to that secret. Our state is stored in S3, and the infra is applied on commit to main with a terraform plan run on the merge request to main.
Our biggest security vector is always going to be someone using elevated credentials to access something, but this way there is no state on a developers machine at any point for any of our production infra.
A credential/key storage service, either on device/server or as a separate device, with IAM to control whether the user executing that process can use that secret or not. The user in this case for prod services should be a prod (non-human) user.
When all your services are like this, no person should have direct access. You generate key/secrets depending which services you want to allow to communicate with each other and the keys live in the key store. For secrets for external services, e.g. API keys, someone would have to enter them once, yes.
You also should try not to rely on secrets, rather invest in proper authentication/authorization logic.
The article talks about keys being published as part of the web page configuration.
That's far worse than "they could hack a server and gain its credentials!"
Instead of providing secrets directly to a server, you generate an ENVKEY token which is used to fetch and decrypt the app’s secrets/config and supply them as environment variables to the process.
The ENVKEY still needs to be protected, but you can limit which IPs can access it and if access is cut off, the process will be killed and secrets cleared immediately, so you do get some additional protection. All access attempts are also logged.
(Unless you're just trolling)
And the API might also expose data you don't want to expose to the public.
That's why you never put these on the client side. There are better options, for example a proxy that injects tokens into the header.
I guess you can proxy all that, but then what do you that the third party couldn't be doing for you? Can the user not accomplish the same thing through your proxy that they could through the key? It'll be easier to drop some requests than it is to revoke an API key I guess. You could use client-certificates, stuff along the lines of Cloudflare's API Shield etc but I would guess that only the top 5% of applications do this.
I've certainly done it/am doing it right now, which is likely why I'm writing such a defensive comment.
Honestly if an enterprising user/developer wants to do something like dump all data that is already accessible to them, more power to them.
E.g. Stripe has a publishable key and a secret key. The publishable key links the checkout session to a particular Stripe account, but you can't actually initiate a checkout session without setting a session ID from the server (which requires the secret key). If the 2 keys don't belong to the same account then the checkout session will fail.
Yes, with some services you can proxy requests via your own service. But how is this more secure? If anything you've just increased the potential attack surface.
The way to hide your keys would be to bounce the search through a proxy server that then does the API call on behalf of the user, but you're really not gaining anything by doing that, and now you're on the hook for traffic misuse mitigation.
Most APIs designed to be used this way also whitelist your token to your site domain, so they can't just steal your key and use it on their own site. Regardless, Algolia and services like it fully expect to be exposed to the full force of the internet at all times, so there's really nothing your API key can do that they're not already covering their bases for.
In general if a SaaS has a client-side SDK, they’ve designed around this and give you an API key just for the client bundle. It has only the permissions required for the client SDK, which - yes, could give a client the ability to run up your bill. But you could say the same about any usage based service. It’s up to you and the service to mitigate against that.
I’m not familiar with every variable in the screenshot from this blog post. Of those I’m familiar with, I don’t see any secrets in there.
It doesn't need to be anything like your real name, much like only needing a registered aus company to own a *.com.au
view-source here -> https://iview.abc.net.au/
Even if they do have software issues I wouldn't be publicly running attacks against them cause it would just give the government more reason to cut their funding more.
Likely the developers at the ABC are doing the best they can with the limited resources they have, and deserve our support rather than doing the Internet mob attack thing.