1. Are you a software engineer?
2. How many "security" tickets have you been assigned in your career?
3. Has your employer ever paid for security training for you? (and I'm not talking about annoying powerpoint websites that teach you how to identify phishing emails)
4. Has your organization ever run a blue team / red team exercise?
5. Who is in charge of APPLICATION SECURITY at your company? (Not network security, or database security, but actual APPLICATION level vulns)
6. Does your organization scan for outdated dependencies? (Do you uncover CVEs in your software on your own, or do you check how bad things are when the news tells you something big happened and might be in your stack?)
7. Are you running a web application, and have you implemented ANY security headers?
8. Did your business unit mandate that "we support all browsers", so they still have you running on TLS v1.1? (who tf knows, or cares, am I right?)
9. Do you use the software you built? (Is your personal information in the database, along with legitimate usage stats, and possibly sensitive information you'd like to protect, or do you just write the code and deploy into the void?)
10. Do you have access to the production systems or database? (Most likely the answer is NO, so you wouldn't know about brute-force attacks, invalid requests, corrupted data, or other anomalies the developers should have their eyes on).
My diagnosis; the profession of software development is a victim of a hostile takeover from product managers, while pushing engineers out of control of their domain.
My recommendation; use the least amount of software you can get by with, and assume it's compromised.
I'm in SecEng and was laid off when my company's regional office went under. It's become pretty obvious to me that there's a huge need for security minded engineers, and most applicants companies get for "Application Security Engineer" roles don't have any experience or background as SWEs.
I'm of the opinion that the industry needs to do a few things to help get traction on the problem:
1. Open up career paths that allow SWEs to move from product develop to technical security 2. Have companies better advertise their need for skilled technical security talent 3. Have InfoSec teams perform more cross team exercises. I've never met an engineer who wasn't all for participating in a red/blue team exercise. It's a fantastic way to cross-train and raise awareness.
I've run into many stupid security mistakes, and continue to do so :(. Even though security can be very hard, as an industry we'd be way better off if more understood at least the basics. Those with interest/expertise can then dive in and find the more tricky things. Those without, can at least understand WHY these things are important.
Cross team working is important, but I think it's also important to try and embed security "people" into the day to day development flow on a regular basis. It ought to help the developers through learning by osmosis.
Definitely think companies need to better signal the demand for deep technical skills in security though - too many seem to actual want generic risk management experience but no particular technical knowledge. To my mind, anyone in a security role should really be able to break their way into a typical corporate internal webapp in a few minutes, just out of their own residual talent and ability to show stakeholders the importance of their profession. It's amazing how quickly security gets a seat at the table when they show how they can pop the self service password reset portal with just a web browser (with appropriate permission of course) and are asking whose password to reset to show it works...
I wish. On the contrary, in my career I met more people that moved from security to development than the other way around.
In many organizations the priority is on churning out stuff and security comes later.
It is clearly proven by the small percentage of security people VS developers.
As a consequence, developers are paid and praised more. Security people end up fighting an endless uphill battle and sometime seen as "party poopers" by the developers.
The need for App Sec is there as far as I’m concerned the demand is non existent... even though most red teams could make them cry.
These should be as basic as not storing cleartext passwords.
Most newly CS students would know better then to do this or at least would know they have to properly look this up.
It's sometimes hard to believe major stupid things like this are done accidentally. (But I know very well how they happen accidentally, it starts with some bug somewhere with non-us-ASCII/to long and similar, then it's constrained "temporary" and put on a must fix list but that list never gets any priority ever, things like this are sadly supper common. As long as companies don't get legally hold responsible for negligence this won't ever go away.)
You would think that "not storing cleartext passwords" is a universal given today, but the corporate structure controlling software design today actively suppress anything that isn't a feature. It silos security responsibility to the point where nobody was probably in charge of making sure there was a coherent password policy, that it conformed to any type of standard, or that it was enforced in production against their multiple running systems.
This is every company today.
One thing that causes them to be prioritized where I work is that if they come up during a yearly review, you can't ship your app. Overriding that "stop-ship" order requires C-level approval. Because without a specific exploit, it might be hard to convince a PM to move those up in the backlog.
Sorry, calling BS on this one. You’re calling out an entire group when, like most things, it’s a subset of the broader group. Good PMs understand that a complete product is not just new fancy features but a combination of Features, tech debt work, security and more. At the end of the day if our customers aren’t secure, we’re in trouble.
I’ve been on both teams. Once watching a PM stand n the midst of my engineering team proclaiming “I don’t give an F about your technical debt, when will my features be done?” And now I lead a product management team. Great companies have Product and Engineering trusting each other and working together. They may disagree from time to time, but they deliver together and work together to balance what gets done.
Nearly every single project I've worked on directly or indirectly has had problems (involving security or otherwise) that could have been fixed by a more patient management.
The best thing to learn as an engineer at any level: "rushing makes messes."
Normally, you can pick one. If you are exceptionally lucky, 2. No project is ever all 3 at once, if anyone thinks so for a given project that is a sure sign of either delusion or inadequate ability to judge (after all, good is very subjective).
I have more then one time stumbled about some "wtf is this" thing in libraries which seem to be very good/well maintained/etc.
Things included:
- Setting socket options which are both unnecessary and cause bugs (like non blocking flag on a socket which is used as if in blocking mode without having non-blocking support in that library).
- Not properly clearing secrets while advertising to do so. (I.e. writing zeros without using volatile write or similar, not supper will known but authors of hashing libs can be expected to know better).
- Less obvious Memory leaks.
- Major logic flaws in the application logic which should easily have been cough by tests, except that the tests didn't really test anything. (Through ironically not security flaws.)
- Libraries pretending to support X but only correctly support that common special limited usage of X while having code for full X support but all buggy and 100% unusable outside of the common special case.
- EDIT: Fundamental design flaws in supposedly state of the art, supper fast, supper reliable web framework which makes it not so fast and not so reliable in many real work use-cases under load.
- etc.
It's sometimes really sad.
110% recommended.
I'm in finance, working on back-end systems used by banks. :-D
>My diagnosis; the profession of software development is a victim of a hostile takeover from product managers, while pushing engineers out of control of their domain.
Jop, that nails it. Software engineers are treated sometimes like children, sometimes like being crackbrained even, but almost never as the highly educated experts they are (or should be, if there wouldn't be so much botchers around also, which for sure causes to some degree the mentioned problem).
Engineering decisions can often be overridden by management no matter what. The result are the usual "catastrophes" repeating over and over everywhere. But as long as this "catastrophes" (like breaches with exfiltration of user data) "require" mostly only a "pardon blog-post" from some executive but don't have any really hurting (financial!) consequences this won't change I guess. If there are costs the insurance will cover them usually. And you need to have and pay the insurance anyway, so why care further? Product management doesn't optimize for security. They optimize costs.
Which as such is not wrong or so! If the incentives would be set by the market provider (the state) correctly the same mechanics could easily lead to improved security. I know many don't like to hear this but imho this industry needs stronger regulation. Without regulation nothing will change as on a free marked the "cheapest" product wins. And it will be (or is, as we can currently see) "cheap" in any dimension. "Worse is better" is a direct result of the fact that the "cheapest stuff" prevail in the long run.
>My recommendation; use the least amount of software you can get by with, and assume it's compromised.
Quite depressed recommendation and fatalistic viewpoint. But to be honest, after so many years in software this could have been my words. And as I see it: Without true political will this conclusion won't change on it's own.
I would be much more worried about security if the developers had access to the production environment than if they didn't.
So far, so good.
The issue was that the “sysadmins” knew almost nothing about how anything worked, so the procedure was that the devs would give them commands to type and they would just type them in to a terminal.
Of course, if anything went wrong, or was ambiguous, the dev would need to check on it, and would end up standing next to the “sysadmin”’s desk and just telling them which characters to type. I once had to explain what a pipe character was...
Anyway, the end result was that all of the devs had prod access, they just had a very slow interface to it.
PHB: "They need access to all the systems."
Me: "Well, um, what if one of them got disgruntled and just tossed some malicious JS in one of your many, many front end servers? Given the procedures here, it would be unlikely anyone would stumble across it, but they'd get a good amount of hits before the browsers block the entire site and traffic precipitously drops."
PHB: "Nobody would ever actually do that. Besides: we have to give them access. (looks at me as if he's explaining something to a five year old) We're a devops shop..."
Regarding users caring about security, there's three possibilities:
- Users should care about security but they don't because they're dumb/ignorant.
- Users don't care about security because it's not worth the cost/it doesn't affect them, so they're right in not caring (they have 'nothing to hide').
- Some combination of them.
%s/software/modern &/g
In 2020, you are an "engineer" writing "modern" software.
Don't forget the "updates"!
This is a good observation, it summarizes very well my feeling on what is wrong with the industry today.
In the 90s in many (most?) companies where the product was tech, engineering was in charge of engineering decisions. This meant that feature requests had to pass a sanity filter which would discard or transform ideas which would compromise the soundness of the security, stability, maintainability and other core architectural considerations.
Today, engineering is reduced to fungible user story jira ticket implementors with no decision making power so the more abstract (to PMs) work such as security will get no attention except as a crisis when it generates bad PR.
(source: working as a security-focused eng/architect since the 90s, on both product engineering and infosec sides.)
I do not agree, but I am biased. I'm a former engineer with a security focus that is now a product manager.
I think a more honest take is that security has never been a priority outside of some specialized use cases/industries and that didn't improve as software development moved from something esoteric to something which is business critical in every industry vertical. Even in industry verticals where security is theoretically a priority and a lot of money is spent on security, most of the "security" people don't actually know anything about security and most of the work is box-checking for compliance audits.
You can only do so much and if we're being real security will always compete with other development priorities and the ones which drive revenue always win in any for profit enterprise which creates software as a core competency and the ones which reduce cost always win in any for profit enterprise where software creation is not their core function. Tech is either a product/revenue driver, or it's a cost center, and in both cases security adds additional expense, overhead, and time to release timelines which doesn't pass the PHB smell test.
The other big issue is that security doesn't have strong advocates in most organizations because even the most technical people in most organizations are security illiterate, even in the tech industry vertical. As a SWE at most companies you're a "security genius" if you use a password manager and know how to generate a CSR with OpenSSL or configure Let's Encrypt.
Maybe I'm overly cynical, but I've largely given up on seeing most companies pursue security with the passion and commitment necessary and see policy as the proper way to address these concerns. I applaud things like HITRUST CSF, which is strongly prescriptive and helps drive security in industries where every single company is full of box-checkers who like to buy appliances. I've been fortunate enough to work at companies that take security seriously and appreciate my background and as a product manager I have always considered user security and privacy to be critical and core components of UX in my products. So, I wouldn't blame the PMs, I'd blame the realities of doing business combined with the lack of adequate security literacy across the board in every industry vertical and at every technical role level.
is there financial pain? Is zoom losing money over these security issues? or is paying to fix them going to cost more than the offset in losses they would've had?
https://www.psychologytoday.com/us/blog/some-assembly-requir...
So, developers shouldn’t shovel a bunch of third-party advertising SDK’s into their apps?
That’s just crazy talk.
/s
250 minutes to crack any password?
Meeting will be over before this happens.
I tested much higher rates for short bursts, and wasn't ever rate limited, but didn't want to risk blowing anything up. However, with a few AWS instances / lambdas it would have been possible to do it in a few mins.
Secondly, and more importantly, I found a variant (mentioned in the article) that allowed me to do this before meetings started, so you could have the password in advance.
Maximum password length of 10 chars, and auto-converting non-ASCII to '?' are both extremely egregious password practices.. Why does it not surprise me Zoom is doing both. I wonder it they also silently truncate passwords > 10 chars?
These are absolute basics. Let alone not rate limiting and the laundry list of other terrible (lack of) security practices.
I use 1Password and sometimes when it pastes in it works, sometimes the UI complains the password is longer than 32 characters.
I sent them a screen shot on Twitter [0] figuring their US support people would see it, but they didn't seem to care that much (got some generic response).
We just shouldn't be using them: https://zalberico.com/essay/2020/06/13/zoom-in-china.html
[0]: https://twitter.com/zachalberico/status/1257910514966908933
Is it possible to limit passwords to 10 characters and silently truncate them too?
> 16th April – Heard they were working on updated bug bounty program.
> 15th June – Requested update on BB program. No reply.
> 8th July – Asked again if I could submit this for bounty. No reply.
> 29th July – Disclosure.
That's disappointing that Zoom never got back to you regarding the bounty.
> Update edit: A few people have asked me or remarked about the lack of bounty. To be clear, I never actually submitted this bug via their bounty program (but was invited to do so), as was holding out for their new program (see post), and fell down the cracks a bit. Zoom didn’t decide against awarding a bounty – I never submitted for one, and disclosed here instead.
> 16th April – Heard they were working on updated bug bounty program.
> 15th June – Requested update on BB program. No reply
> 8th July – Asked again if I could submit this for bounty. No reply. (Point of clarity here – the bug is fixed, and they have new issues to deal with so this isn’t exactly a priority for them. I could have chosen to file the bug for a bounty at the time, but didn’t, and wasn’t promised anything if I waited).
If Zoom were serious about their BB program they would have encouraged him to submit it for a bug bounty.
Hope that helps set a bit of a benchmark!
I've reached the point of assuming the odds are stacked so heavily that, from a purely financial perspective, it's not worth the investment just to report an issue let alone find it.
I disagree. I think it shows that Zoom (at the time this was created) lacked the skill necessary to create a secure platform. But their prompt reaction and subsequent focus on security has given me hope.
> 16th April – Heard they were working on updated bug bounty program.
> 15th June – Requested update on BB program. No reply.
> 8th July – Asked again if I could submit this for bounty. No reply.
> 29th July – Disclosure.
Prompt?
> Maximum password length of 10
Increased focus on security?
We also tried self-hosting Jitsi, and while that kind of worked, we had some problems getting everyone to be able to connect to it and send/receive audio. It went on the backburner of things to look into more later.
Zoom has a lot of problems, clearly, but it solved THE most important issue: we can actually communicate successfully with it -- as in right now with minimal additional effort. That's why it won.
A not-so-subtle (and IMHO abusive) effort to get you to use Chrome instead? They've already done that with YouTube's new horrible redesign, it wouldn't surprise me if other Google app-sites were the same.
The state of web browsers is a mess but that's a rant for some other time...
When you drink a soda, minimal additional effort is to throw the can away, but if you think about consequences you'll probably make some additional effort and recycle it.
Some schools and states have banned Zoom. I think New York's educational system is one.
Where Facetime and G Suite (Meet) simply freeze, drop connectivity for 30 seconds at a time, etc... Zoom just chugs along at an extremely low bitrate but where you can still make out the audio and speak and be heard.
Other solutions are awesome when you've got dedicated bandwidth in your office. Zoom is awesome when your local ISP sucks, or the rest of your family is busy using the internet too and there's nothing you can do about it.
It would also catch cheats in video games, for example, since those are statistical outliers too.
Is there a name for this kind of program?
https://scikit-learn.org/stable/modules/outlier_detection.ht...
I am thinking of using Grafana with Prometheus. Love to find a nice resource with good ideas of rules/monitoring to have
In CSGO's case they test it against their existing system Overwatch which uses player moderators to detect cheats). With their other big title dota as far as I'm aware its fully automated.
1 - "GDC 2018: John McDonald (Valve) - Using Deep Learning to Combat Cheating in CSGO" - https://www.youtube.com/watch?v=ObhK8lUfIlc
We're now looking into an enterprise license for Krisp.ai just to remedy this. I am not sure how a trillion dollar company like Microsoft hasn't been able to figure this out yet. Maybe they'll buy a startup like Krisp just to fix it. But hey...at least it's more secure.
I do have sympathy for their team who were suddenly getting a wild amount more traffic, and scrutiny. They have scaled fast and kept the platform up and stable, which is impressive.
In all the calls I've attended this was always the case anyway, and there seemed to be an implicitly understood rule of "keep yourself muted unless you want to say something". Seeing someone's mute indicator turn off was a cue to pause and wait, as it indicated someone wanting to say something.
He kept getting filtered out randomly and we couldn't understand him because of the feature. It was (at the time) turning back on without his knowledge. We eventually got it consistently turned off with one of our zoom admins' help.
We get a lot of background noise from him but his voice is more valuable there.
It should have been there from day one. For the protection of their customers, and their own infrastructure. After the string of "zoombombings", it should have been a top priority and received ongoing attention from their CEO until implemented.
When I began using the platform, I assumed the randomly generated meeting numbers were buttressed by adequate account and connection attempt monitoring on their back end to make them "secure enough". After finding reason to suspect otherwise 5 months ago, I contacted Zoom about it twice and never received a response (from what I can tell support is overwhelmed and tickets even for serious issues like security breaches and billing errors can take months to hit human eyes).
The password-in-the-link approach felt to me like security theatre. Yes, it adds value, but really doesn't amount to anything more than a bit of additional URL obfuscation (particularly given the length and character limitations), unless you're distributing passwords separately - which can be onerous for attendees.
Hats off to this researcher for forcing the issue and finally incentivizing the company to work on cleaning up their act. But it makes me worry about where else in their platform they took shortcuts. They've really nailed the "frictionless" part (and I commend them for that) but I'm convinced you can achieve a friendly user experience while still maintaining a basic level of security.
Of course the password shouldn’t be 6 digits...but as long as the URL space is unsearchably massive, say 256 bits, and there’s some basic rate limiting, embedding a “password” or random token in a URL seems an acceptable way to frictionlessly share private content?
Appending a passcode is little different than if they were to just use longer meeting numbers in the first place (but with sometimes-worse entropy e.g. when the user changes it to "123456"). So they bought a few more bits (evidently still not enough to beat the bad guys) at the price of extra user hassle.
If they were more aggressive on the server side, they could probably get away just fine with the smaller, more convenient links and wouldn't need to push users so hard to turn on "frictiony" features like waiting rooms.
Private links work great as long as the team providing them understands the tradeoffs and appropriately mitigates risks. Zoom isn't the first service to be brute-forced [1], and there are more subtle ways for links to leak [2] (e.g. I think someone's tax returns once wound up on Google after the secret Dropbox URL was passed in a referrer header).
[1] https://www.theregister.com/2011/05/08/file_hosting_sites_un...
[2] https://softwareengineering.stackexchange.com/a/325821/79139
A proper secret is something that you can only give consciously, URLs are often shared without intent (via screensharing, screenshots, (often unencrypted) emails, server/proxy logs, etc).
Many services like the ones you quote do allow sharing via URLs for ease of use but should also have a option to turn off auth-in-url style authentication for things that are sensitive.
It's okay for things that have a low value but need to be shared easily, but should not be considered secure.
If they go for a longer and alphanumeric password as it seems they are doing, I am gonna dread having to enter that manually whenever joining a meeting, all because an hypothetically attacker might join in. Might as well switch back to webex for usability.
For example blackberry work (depending on configuration) on a private phone.
For what might probably be a millionth time, what are the best alternatives (preferably free or easily self-hostable or priced low) for occasional calls of the following types:
1. Video calls with some people (say about 10 people max.). The free Jitsi Meet seems good for this.
2. Webinar platform where there are clear distinctions between a presenter and participants, and the presenter chooses what's visible at any point in time (video feed from camera or some file/presentation/screen sharing) and has control over recording the session.
3. Same as #2 but with two presenters on camera (different physical locations) switching back and forth (either as the main view or with the active presenter on the main view and the other in a smaller corner window).
Well, that's unfortunate. I don't have a zoom account and have no interest in having one, but sometimes need to attend meetings I have no control over where they're held.
