[HN Gopher] Zoom Security Exploit: Cracking private meeting pass...
___________________________________________________________________
Zoom Security Exploit: Cracking private meeting passwords
Author : TomAnthony
Score : 227 points
Date : 2020-07-29 15:25 UTC (7 hours ago)
(HTM) web link (www.tomanthony.co.uk)
(TXT) w3m dump (www.tomanthony.co.uk)
| ziddoap wrote:
| >In other testing, I found that Zoom has a maximum password
| length of 10 characters, and whilst it accepts non-ASCII
| characters (such as u, EUR, a) it converts them all to ? after
| you save the password
|
| 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.
| fossuser wrote:
| They do silently truncate account passwords greater than 32
| characters, but what's (arguably?) worse is they only do it in
| some places and not others.
|
| 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
| hmhrex wrote:
| Thanks for linking that essay. It's a good read. I especially
| liked the Sarah/Exec conversation. Will definitely keep this
| one saved for later.
| tinus_hn wrote:
| Do Chinese people not use Chinese characters in their
| passwords?
| yorwba wrote:
| Entering Chinese characters requires using an input method
| engine that turns keyboard input into a list of candidate
| words from which the user picks the correct one. If you used
| that method to enter a password, shoulder surfing would be
| trivial. I think it's usually automatically disabled for
| password input fields.
| ladberg wrote:
| Additionally, there are other methods like Zhuyin that some
| people (typically the older generation that used computers
| before contextual dropdowns) use. I _believe_ those keys
| just map 1-1 with American keyboards so they would just
| type the keycodes for Chinese characters and ASCII is
| inputted into the password field, but correct me if I 'm
| wrong.
| techntoke wrote:
| Why public education continues to use Zoom is beyond me. Not only
| do they use Zoom, they spend upwards of $10/mo per student for
| it. For that price you get the entire G Suite platform.
| Figs wrote:
| We tried using Google Meet for work meetings at my university.
| The experience SUCKED compared to Zoom. There were serious
| problems like taking 30 seconds to a minute for the screen
| share widget to popup after clicking the button in Firefox! It
| was, frankly, unusable for us.
|
| 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.
| sm4rk0 wrote:
| Time to learn that _minimal additional effort_ != _best
| solution_.
|
| 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.
| reaperducer wrote:
| _Why public education continues to use Zoom is beyond me_
|
| Some schools and states have banned Zoom. I think New York's
| educational system is one.
| twostorytower wrote:
| My org was forced to switch from Zoom to Microsoft Teams and it's
| become quite apparent Microsoft has a long way to go to catch up.
| There are small things Zoom did that enhanced meetings that you
| never even knew or thought about as a user until switching to
| something else. For example, noise filtering. Zoom has active
| noise filtering which gets rid of small background noise (like
| typing or computer fans). Microsoft Teams does not have this, and
| every meeting with more than a couple people has unbearable
| background noise and everyone has to be on mute if they're not
| talking.
|
| 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.
| tech234a wrote:
| Discord actually just partnered with Krisp.ai to bring the
| feature to their app too.
| TomAnthony wrote:
| Yeah, Zoom works very well, and is so much better for video
| calls than most of the alternatives.
|
| 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.
| avh02 wrote:
| On the flipside (just an anecdote, not making any points), we
| had a hard time turning this noise filtering consistently off
| for a colleague of ours who speaks without a voice box.
|
| 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.
| user5994461 wrote:
| I really hope they just extend the password to 8 upper letters
| (200 billion combinations) or 10 digits.
|
| 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.
| coldcode wrote:
| My employer just switched to Zoom (yesterday was my first zoom
| meeting) and I wondered why we were switching to a company with
| such lame security.
| wolco wrote:
| checked 91k passwords in 25 minutes.
|
| 250 minutes to crack any password?
|
| Meeting will be over before this happens.
| dx87 wrote:
| You missed the part where he said that you could just throw
| more servers at the bruteforce and drastically cut the time
| required.
| andykx wrote:
| It won't necessarily take that long though. That is an upper
| limit.
| black3r wrote:
| On a single machine with 100 threads. But imagine what NSA (or
| any other relevant intelligence agency) can do for listening
| into some foreign government's meetings like the UK one in
| example. Or what huge corporates can do for corporate
| espionage.
| marksomnian wrote:
| That's on just one computer. Depending on how many servers
| (read: how much in AWS credits) you have access to, you could
| parallelise it nearly infinitely.
| eat_veggies wrote:
| This attack horizontally scales really well, and you don't have
| to try all 1 million passwords in the average case
| d4mi3n wrote:
| Don't forget that many recurring meetings reuse the same
| password.
| tinus_hn wrote:
| If you can choose the password, people will also use
| passwords they use for other things.
| d4mi3n wrote:
| I agree, but the point I'm trying to make is that the time
| to guess the password isn't too big of an issue for
| passwords that never change. Ideally, Zoom would generate a
| password for each instance of a meeting.
|
| Failing that, having some better factor for authentication
| (known email or number for a given company's Zoom setup)
| would make it harder to get in simply by guessing a short
| password.
| ptasker wrote:
| I would imagine using a GPU compute instance would bring this
| time down significantly.
| eat_veggies wrote:
| It's network bound, not compute bound. A GPU wouldn't really
| help in this case.
| TomAnthony wrote:
| OP here.
|
| 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.
| sillysaurusx wrote:
| It seems like one way to mitigate security vulnerabilities is to
| write software that looks for statistical anomalies. Attempting 1
| million passwords in 28 minutes is such an obvious outlier that
| it's strange we have to guard against it explicitly.
|
| 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?
| caiobegotti wrote:
| Even a really crude monitoring metric would trigger alerts
| after a bunch of recurring calls to an endpoint from a specific
| place. They simple don't care at all or are too dumb to come up
| with basic security checks.
| nitrogen wrote:
| Until it's a default in frameworks like Spring Boot and in
| ELK stack logging systems, in most places it's not happening.
| wdb wrote:
| Got any examples of such monitoring metric setup? Would love
| to get an idea what it's good to monitor :)
|
| I am thinking of using Grafana with Prometheus. Love to find
| a nice resource with good ideas of rules/monitoring to have
| caiobegotti wrote:
| That's exactly what I do (or would) use and it does plenty
| for many type of business and it scales up well. The
| metrics specifically depend on the rest of your stack
| though but these days any API gateway or ingress
| application or service mesh or proxy app can provide
| endpoints metrics for you nearly out-of-the-box.
| boarnoah wrote:
| Valve has an interesting talk about this with respect to VAC
| [1]. Which like you suggest relies heavily on statistical
| evidence from multiple replays in order to detect cheats.
|
| 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
| eat_veggies wrote:
| Yep, it's called novelty and outlier detection. The sklearn
| page is pretty informative:
|
| https://scikit-learn.org/stable/modules/outlier_detection.ht...
| black3r wrote:
| Rate limiting login attempts is a basic security principle that's
| both easy to implement and not overly intrusive. This once again
| confirms that Zoom just doesn't care about having a secure
| platform at all.
| mcherm wrote:
| > This once again confirms that Zoom just doesn't care about
| having a secure platform at all.
|
| 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.
| ziddoap wrote:
| > 9th April - Heard from the Zoom team that this was
| mitigated.
|
| > 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?
| hungryhobo wrote:
| not sure if you've actually read the article
| ziddoap wrote:
| Feel free to elaborate?
| pvtmert wrote:
| I think he meant that they somehow mitigated problem in
| 10 days wheras haven't paid (ghosted) author for
| months...
| cosmodisk wrote:
| I thin theyve been big enough long enough to have a guy or
| two who could look at the functionality or even the codebase
| and say: ' hold on a minute,how on earth we are doing this'.
| nitrogen wrote:
| It's pretty freaking hard to convince a PM to care about
| security. For that matter it's pretty hard to convince most
| engineers, let alone companies, even after a hack. Imagine
| yourself talking to the general counsel after an
| elasticsearch db gets hacked about ethical obligations to
| make customers whole. Then imagine that GC saying literally
| "ethics? It's not like we're building bridges here".
| ziddoap wrote:
| If a website stores passwords in cleartext instead of
| hashes, would you have the same response?
|
| This isn't fancy stuff. This doesn't require tens of
| thousands of dollars in code-audits or pentests to come
| to light. It's literally the absolute basics of password
| management. There should be no need to "convince a PM".
|
| Rate limiting, not silently truncating passwords, not
| setting an extremely low and arbitrary maximum on
| password length... All of this stuff is as basic as
| hashing a password.
| nitrogen wrote:
| I'm saying I've been in exactly that position in many
| companies. Spent all of my social capital to get password
| hashes fixed, or a hacked DB audited, or circuit
| breakers, or rate limits, alerts, admin and monitoring
| tools, etc. It's really easy to preach here on HN. Saying
| it's an uphill battle "out there" is a drastic
| understatement.
| ziddoap wrote:
| I get where you're coming from, I do these types of
| engagements often. I just wanted to highlight the
| difference between "Please spend $25,000 on this pentest
| engagement" and "Don't set a maximum password length of
| 10" or "Don't set the default password to be 6 digits".
|
| One is an investment and requires convincing a PM or
| C-Suite. The other two are some of the most basic
| concepts possible (literally first semester, if not first
| week of CS) in the design of anything that has to do with
| a password.
| nitrogen wrote:
| _The other two are some of the most basic concepts
| possible (literally first semester, if not first week of
| CS) in the design of anything that has to do with a
| password._
|
| There are still ways this can fail: e.g. tech lead on a
| team full of good but uninformed bootcamp devs with an
| absentee manager and a domineering PM, run as a democracy
| when only a minority have (formal or self-taught) CS
| education. If the PM doesn't like your recommendation
| they'll get one of the bootcampers to do a crappy job
| without telling you.
| black3r wrote:
| According to wikipedia Zoom was founded in 2011, has 2000+
| employees and had revenue of 600M last year. I somehow doubt
| that if they cared, it would be a problem for them to hire a
| security consultant (internal or external) and perform some
| pentests and I believe any professional pentester would find
| stuff like this AND their previous security mishaps (their
| definition of "end-to-end encryption", mac app backdoors,
| etc...)
| haecceity wrote:
| The history of computers seems tell us that people don't
| care about security until they're compelled to.
| unsignedchar wrote:
| Their success seems to demonstrate that they were right to
| prioritize functionality over security.
| markovbot wrote:
| No, it does not. It demonstrates that they were successful at
| getting a lot of people to install their dangerous software
| dopamean wrote:
| If you measure success by installs then they were
| successful.
| [deleted]
| xtracto wrote:
| Reminded me of the time when it was possible to brute-force a
| Hotmail password brute-forcing via the Windows Messenger client
| connections
| AnonHP wrote:
| I can't stand the thought of using Zoom after all the seemingly
| endless issues on security and privacy (and now this new issue
| with not paying a bug bounty).
|
| 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).
| Naac wrote:
| > 9th April - Heard from the Zoom team that this was mitigated.
|
| > 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.
| tito wrote:
| Gut check here on Zoom customer service. Has anyone heard from
| them in the last 2 months? I've been on a pro plan and 10-seat
| plan and had 2 issues about events sent to their customer
| service starting June 3rd. Have not heard back anything besides
| regular "we're moving slow because of COVID 19" template
| updates". They used to be responsive, even had a "chat" feature
| but now that's disabled.
| mystcb wrote:
| I am going to raise my hands and say I have heard from them.
| I logged a support request on March 24th (the day the UK went
| into lockdown, so I was already expecting a delay). I finally
| got a response back on July 20th. It is a shame they are
| slow, as they have been really responsive in the past.
|
| Hope that helps set a bit of a benchmark!
| cs02rm0 wrote:
| Bug bounties seem to be a complete wild west.
|
| 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.
| rkagerer wrote:
| It's unconscionable they still hadn't implemented any sort of
| rate limiting.
|
| 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.
| caiobegotti wrote:
| Reading the whole story it makes me believe Zoom has really poor
| securities practices all across their board. Even basic stuff.
| Incredible.
| netsectoday wrote:
| I believe Zoom's continued struggle represents the state of
| software development in 2020.
|
| 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.
| pwdisswordfish2 wrote:
| You forgot the key word: modern.
|
| %s/software/modern &/g
|
| In 2020, you are an "engineer" writing "modern" software.
|
| Don't forget the "updates"!
| Bnshsysjab wrote:
| 11. Do you audit third party libraries for security, malicious
| intent, and longevity?
| hinkley wrote:
| 11.a: Do you even know if the libraries you are shipping are
| the official versions?
| dathinab wrote:
| I try do so. But non properly, i.e. I at least skim third
| party libraries as long as viable.
|
| 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.
| Bnshsysjab wrote:
| I would love to see public code reviews of open source
| projects to highlight this kind of stuff but actually
| having a community driven effort requires a central vendor
| to support it cleanly. GitHub/gitlab: I'm looking at you.
| d4mi3n wrote:
| You touch on another important issue I don't see a lot of
| discussion about: There is a HUGE demand for application
| security engineers, or more broadly, security folks with
| software engineering backgrounds.
|
| 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.
| cmeacham98 wrote:
| > (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).
|
| I would be much more worried about security if the developers
| had access to the production environment than if they didn't.
| alasdair_ wrote:
| I once worked for a fortune 500 that blocked all but a few
| unix sysadmins from executing shell commands on prod servers.
|
| 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.
| pvtmert wrote:
| I'm system engineer in a decent company. I wish devs could
| access to prod systems so they have to get to cleanup their
| mess / get responsible for actions they do...
|
| They already have access to staging and preprod what they
| do is basically coming to me and saying 'it did run well on
| their macos machine'
|
| There are outliers, some few good people and some random
| people having no idea what they are doing.
|
| IMHO there should be random quiz/task/test each day you
| login. Something obvious but not trivial at the same time
| related with domain of the system. So you would get 24h
| access if you pass, get denied for 3 hours if fail. 3
| questions in each session...
|
| At least people might learn something out of requirement...
| henryfjordan wrote:
| > Anyway, the end result was that all of the devs had prod
| access, they just had a very slow interface to it.
|
| They also had a person who could see if the dev was
| stalking an ex-girlfriend or pilfering bank account info.
| Sounds perfect.
| caiobegotti wrote:
| HSBC production support used to be pretty much exactly like
| that during rollouts (no idea if that has changed in the
| last 5 years).
| ziddoap wrote:
| I fully agree with your sentiment, but the specific issues
| discussed here (having a maximum password length of 10,
| silently truncating passwords, silently replacing non-ASCII
| with '?', setting default passwords to 6 numbers, not rate-
| limiting password attempts) are not things that require a red
| team / blue team to figure out. They aren't things that require
| scanning dependencies, auditing source-code, etc.
|
| These should be as basic as not storing cleartext passwords.
| FabHK wrote:
| Agreed. Yes, the state of InfoSec is bad in most companies,
| but with Zoom it is really abysmal. World class super bad.
| dathinab wrote:
| > having a maximum password length of 10, silently truncating
| passwords, silently replacing non-ASCII with '?', setting
| default passwords to 6 numbers, not rate-limiting password
| attempts
|
| 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.)
| mac-chaffee wrote:
| I'm just imagining each of those individual issues sitting at
| the bottom of a Jira backlog.
|
| 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.
| dec0dedab0de wrote:
| 11. Do you think exploits are cool? Do you keep up to date on
| types of exploits, at least at a high level, just because you
| want to know about them?
| pnine wrote:
| I'm a front end engineer. I go to Defcon, i read CVEs and
| exploit news. It's a hobby but I feel like it also helps to
| bring a different perspective into the application world
| because my peers don't seem to care much.
___________________________________________________________________
(page generated 2020-07-29 23:00 UTC)