[HN Gopher] Abusing the Chromium Devtools Scope Pane
___________________________________________________________________
Abusing the Chromium Devtools Scope Pane
Author : kiyanwang
Score : 194 points
Date : 2021-09-05 09:34 UTC (13 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| aaaaaaaaaaab wrote:
| I don't get the thing with the ID attribute. Why doesn't the
| browser engine query it as soon as the div is created in the DOM
| tree? Otherwise getElementById wouldn't work.
| Sebb767 wrote:
| The HTML engine probably has an internal list of ids to quickly
| look them up. The dev tools, however, access it externally.
| It's quite likely they simple use `treeNode->getId()` without
| being aware that this call respects JS overwrites.
|
| It might even be a feature; the C# debugger, for example, will
| call your custom `toString()` function in order to give a nice
| representation in the debug window. The problem here is, of
| course, that the debugger is running against untrusted code.
| bsdubernerd wrote:
| This sounds problematic from a debugger perspective if the
| function does any sort of side effect, and I'd consider this
| a bug as well.
|
| In fact, I'd probably argue that causing user-code to run at
| debug time is not a good idea even if the function is
| guaranteed to be side-effect free.
| Etheryte wrote:
| As with every frontend nuisance, such as blocking the right
| click, showing alerts etc, this can be sidestepped easily [0].
| While this technique may deter some people, just like the above
| annoyances, at the end of the day the old adage still holds -- if
| it's in the frontend, the end user can do anything and everything
| they want. That said, this is still cool in the technically
| interesting sense, haven't seen someone do this before.
|
| [0] https://stackoverflow.com/a/13372025/1470607
| true_religion wrote:
| This technique is already being used in commercially available
| pop up scripts... everywhere.
|
| It's been done since at least 2 years ago, and probably longer.
|
| Currently, if you ever pop up dev tools and see the console is
| constantly being cleared, the reason is to obscure that the anti
| debugging software is in effect.
|
| Once the script detects dev tools is open, it will definitely not
| follow the normal path of pop up creation but instead default to
| a Rube Goldberg machine obfuscating the entire operations.
| rasz wrote:
| uBlockOrigin has defusers killing this very easily, no-
| setInterval-if no-setTimeout-if
|
| example https://github.com/uBlockOrigin/uAssets/issues/8128
| loeg wrote:
| > Currently, if you ever pop up dev tools and see the console
| is constantly being cleared, the reason is to obscure that the
| anti debugging software is in effect.
|
| The article notes that the technique does not require logging
| to the console.
| somehnacct3757 wrote:
| This reminds me of anti-memhack techniques in game dev. If you
| store the players money or health in a variable, there are tools
| to help you find it in memory. These tools work by scanning the
| memory for the value you give it, changing the value in game
| (take damage, earn money, etc) and scanning the first scan's
| results for the new value.
|
| To defeat this you just need to XOR the value with some bits. It
| doesn't stop a dedicated person at all, but 99% of cheaters are
| deterred. So it's good enough.
| rightbyte wrote:
| What is the point? To prevent single player cheats? Seems
| unnessecary.
| kalium-xyz wrote:
| Depending on how commercially minded the company is it might
| range from protecting "DLC" or something else that the user
| should[0] pay for, anti piracy, or to extend the grace period
| in which certain content remains undocumented online.
|
| [0] not my view
| TechBro8615 wrote:
| I wonder what would be required to escalate this to executing in
| the Devtools thread?
| azalemeth wrote:
| Anti-debugging, as a field, is just one of those things that I
| think is inherently _distasteful_. As in, the _sole_ point of
| doing it isn 't to _make_ or fix something, like so much else in
| programming, it 's to _break_ something, and deny a feature. That
| just...feels like making a giant "screw you" to somebody else,
| which is very unpleasant.
|
| As an aside, I was very glad to see that if you browse to the
| example sites with firefox you get an angry "This only works in
| Chromium based browsers" popup.
| bellyfullofbac wrote:
| On the topic of distasteful, the author sounds obnoxiously
| proud of his accomplishments...
| bstar77 wrote:
| Read the whole article, his tone changes.
| ylyn wrote:
| Well, if we're not aware of it and we don't take steps to stop
| these techniques, malicious people will use it to their
| advantage.
| Sebb767 wrote:
| > malicious people will use it to their advantage.
|
| There's a good chance they already are. Your average
| ransomware shop probably won't pull this off, but the three
| letter agencies around the world with insanely good staff and
| a lot of budget to search for flaws in some of the most used
| software? You bet they already have this in their toolbelt.
| hutzlibu wrote:
| Erm, the three letter agencies target their exploits
| usually a bit deeper in the system - and these light anti
| debugging exploits are indeed for ransomware, trackers,
| adware and obfuscation, to protect IP and malicious
| behavior. Afaik in the realm of web, mainly to conceil
| shaddy behavior. Tracking, data mining, ...
| matheusmoreira wrote:
| Yeah, distasteful is putting it lightly. Its entire purpose is
| to deny us our computing freedom. To protect their code from us
| like we're some adversary in their threat model. To prevent us
| from understanding what our system is executing.
| bayindirh wrote:
| This is at least as ugly as binaries which embed themselves
| into VMs to prevent and detect reversing. I don't condone
| either one but can understand first one up to a point.
| Rigging a website... That's really some next level ugliness.
| matheusmoreira wrote:
| Yeah. Those video game obfuscation schemes work like that.
| Denuvo and its friends. It's a virtual machine with a
| instruction set designed for maximum obfuscation. Some of
| game's code is compiled for it in order to make reverse
| engineering and cracking ridiculously hard. These
| technologies are known for killing the game's framerate and
| responsible for cracked versions being superior to genuine
| ones.
| guy4261 wrote:
| > it's to break something
|
| One of my university professors told me, during intro. to
| algorithms class, "some people understand things by building
| them, some by breaking them, and you are of the latter type".
| Nothing wrong about that, the way I see it!
| Tarks wrote:
| That implies you'd dislike this more than most because it
| prevents "breaking" things efficiently by intentionally
| crippling tools and throwing out red herrings.
| madars wrote:
| I think there is a distinction we can make here. What sets
| anti-debugging apart is not denying something -- after all, the
| point of cryptography is to make things impossible for
| adversaries -- but whom does it serve. In the case of anti-
| debugging it serves the manufacturer and third parties first,
| and user only gets secondary or tertiary benefits. Whereas
| things like full-disk encryption or encrypted messaging serve
| the user first. (Of course, not all crypto serves the user:
| imagine using MPC to bypass the Fourth Amendment protections.)
| nine_k wrote:
| I see your point, but I think this distinction is incidental.
|
| Technologies are fundamentally devoid of ethics, as are laws
| of nature. A technology only works well for "good guys" if it
| works equally well for "bad guys".
|
| The intent of development does initially play a role, but
| anything deep enough will eventually find both bad and good
| uses, no matter how we see the initial intent.
|
| (But for a specific application, the intent, of course, plays
| a major role.)
| randomscreemz wrote:
| I strongly disagree with this. Taken to its extreme, A
| machine where you can push a button and kill everybody
| everywhere is a fundamentally immoral technology.
|
| The laws of nature are not devoid of ethics either. Screw
| nature. Plague came from nature.
| nine_k wrote:
| A technology that can affect all people on Earth is
| rarely strongly limited to killing people. Look at
| explosives. They can be used to kill and maim people at
| scale, and also to build roads and tunnels in mountains.
| Look at viruses, think of all the diseases they cause.
| Now also look at viral vectors that deliver medicines
| into patient cells, including some of the modern anti-
| COVID vaccines. Look at cryptography.
|
| If laws of nature are not devoid of ethics, take any
| fundamental law, say, Newton's laws, or classical
| electrodynamics, or general relativity, anything from
| mathematics, and try to put it anywhere in the alignment
| matrix but the "true neutral" cell. Explain your answer
| -- I will gladly listen! (Not ironically.)
|
| And pray don't screw nature. There were numerous
| attempts, all ended badly, just look around. You are a
| part of nature, by screwing nature, you also screw
| yourself (which is of course your inalienable right),
| and, sadly, others around you.
| 1vuio0pswjnm7 wrote:
| s/make it impossible/make it prohibitively expensive/
| [deleted]
| chii wrote:
| it's exactly the same idea as DRM. I think society should
| outlaw DRM as a mechanism to enforce intellectual property
| rights.
| LocalH wrote:
| I agree, because DRM has potential to outlive copyright law.
| Sure, many DRMs are broken, but there are many that are not.
| As the arms race escalates, DRM will become harder and harder
| to crack (I can think of a few offhand that AFAIK have never
| been cracked publicly, like the encryption used on cable
| systems in the US). The people in control of the various DRM
| systems are not even thinking about future noninfringing use,
| because they're not even thinking about _current fair use_ in
| developing these systems. These are largely people who do not
| think copyright should expire that are driving these anti-
| public efforts.
| vegetablepotpie wrote:
| You're right, I never thought about the long term effects
| of DRM. But we're really just talking about its effects on
| our grand children. To be fair we'll all be dead by the
| time works made today will go into the public domain.
| yissp wrote:
| Also, think about what a waste of talented peoples' time
| this represents. Probably many person-hours are spent
| implementing these increasingly sophisticated DRM systems,
| and then many more trying to crack them, rendering all of
| it completely pointless.
| danShumway wrote:
| Important to clarify here that in describing the exploit, the
| author of this article is _not_ doing anything wrong -- they
| 're raising awareness of an issue with the Chromium dev tools
| that people absolutely should be made aware of. It's very much
| in the same vein as some of the "login interceptor" extensions
| that got published back when the tech community was trying to
| encourage sites like Facebook to switch to HTTPS. The full text
| of the article makes the author's intentions pretty clear, and
| I think it's _good_ that they published this article.
|
| Otherwise, agreed. Users have a fundamental right to inspect
| code that is running on their devices
| (https://anewdigitalmanifesto.com/#right-to-modify), and anti-
| debugging techniques (including invasive systems like DRM) are
| distasteful because they try to deny users that right.
|
| I'm also pleased to see the Firefox alert, but there's no
| specific mention I can find about why it doesn't work in
| Firefox. I'd love to see some more information about that.
| Santosh83 wrote:
| How is this different from closed source software, which
| constitutes the overwhelming majority of the industry?
| matheusmoreira wrote:
| It's possible to reverse engineer closed source software. I
| have done it.
|
| Anti-debugging is a whole new level of obnoxiousness. Imagine
| a proprietary executable that scans your memory for debuggers
| and similar tools and then kills them or kills itself to make
| it harder for you. They use your own computer to subvert you.
| ipaddr wrote:
| Been around for awhile they are called viruses.
| matheusmoreira wrote:
| Yeah but that's malware. It's expected in those cases. We
| should not tolerate these hostile actions from normal
| software.
| hobs wrote:
| Video game DRM also does this, so we see it in commercial
| software.
| vlovich123 wrote:
| Skype does it too (or did for a long time - not sure
| about the current state).
| Ladlehoe wrote:
| "Closed source" is a pretty poor analogy, since regular
| executables can be disassembled or even decompiled. Reversing
| is a big field. DRM and obfuscation to prevent that reversing
| is a better analogy.
|
| How is it different from that? It isn't, really.
| _the_inflator wrote:
| If it can be done in JavaScript, it will be done in JavaScript.
| ;)
|
| This is good to improve JavaScript and Web security. After all
| this input simply adds to the arm's race.
|
| From a hacker perspective I also enjoyed it.
| nomdep wrote:
| The "security" angle is pure BS. This will only help scammers
| tclancy wrote:
| I don't buy that. That's only true if the author is the only
| person to ever discover this. Instead, he had brought to
| light what others may know and probably do, to judge by his
| prior article. This means we are now aware and the Chromium
| devs may implement changes.
| nomdep wrote:
| You are right. However, for the author the "attacker" is
| whoever wants to debug, not the other way around.
| fairytale wrote:
| While this can be seen as somewhat useful, nothing stops you from
| deactivating breakpoints inside of the "Sources" section in
| devtools.
|
| I also believe that the same anti-debugging technique is used by
| obfuscator.io, and is just a feature you can enable for when
| obfuscating your code on there. It's called "Debug Protection".
| It does about the same thing you shown in your blog post, making
| good use of the debugger statement.
| meibo wrote:
| This seems like a bug, even a security relevant one?
|
| The article doesn't talk about it, but I probably would have at
| least tried to report this to Google - maybe the Author did as
| such and just didn't write about it.
| kevingadd wrote:
| One scenario where you have to do something similar to this is as
| an extension author, because some websites are hostile to the
| user. A couple examples from my past:
|
| A non-profit built an extension that would scrape data on
| advertisements from users' facebook feeds (opt-in). Facebook
| decided they weren't a fan of this so they introduced some
| special mouse event handlers designed to identify mouse events
| generated by extensions (and unfortunately, accessibility tools).
| I worked with the extension author to introduce a very elaborate
| set of tricks to forge the 'event not generated from user input'
| flag so that it would keep working.
|
| Another scenario was that I maintained an accessibility extension
| (keyboard shortcuts, tooltips, etc) for a browser game. The
| developers became increasingly hostile to extensions in general
| because some people used extensions to cheat. Over time I had to
| do things like forge properties, mask events, hide DOM elements,
| forge property/method names and toString values, forge stack
| traces, and automatically shut off functionality in response to
| anti-cheat code changes (using a custom structural hashing
| algorithm for JS I created). They still eventually found ways to
| detect this unfortunately and used that to aggressively harass
| and then ban users of my extension, but I kept the arms race up
| for a year or two. Chrome is very bad at protecting extension
| users from hostile pages - there are various ways to detect
| whether a user has an extension installed/enabled and it's very
| difficult to stop that. Most extensions also need to inject
| scripts into the page to work due to the poor design of
| WebExtensions and that is also sadly detectable :(
|
| Oddly one far more robust approach to work around these issues is
| by writing a custom Chrome debugger using their debugging
| protocol. Custom debuggers can forge real input events, block
| script execution, filter stack traces, silence exceptions, etc. I
| eventually prototyped a replacement using this approach and got
| it working but it really wasn't worth the hassle.
| josephcsible wrote:
| > (and unfortunately, accessibility tools)
|
| Why did this problem need a technical solution then? Wouldn't
| an ADA lawsuit have both solved it plus given Facebook a very
| strong financial incentive to never do such a thing again?
| _old_dude_ wrote:
| Am i the only one to think that the 'id' trick is a plain Chrome
| devtool bug ?
|
| Either the ids should be queried without side effect or not
| queried at all without a user action.
|
| The second idea, using 'toString()' is well know and also works
| in other OO languages, Java, C#, etc.
| missblit wrote:
| Naturally this sort of issue has been reported in the past:
| https://bugs.chromium.org/p/chromium/issues/detail?id=672625
|
| From the comments on that bug there's other ways to detect
| devtools (including timing attacks), and it wouldn't be
| worthwhile to track down every possible case.
|
| As someone who uses devtools debugging a lot I think that
| answer is reasonable, these kinds of shenanigans mostly only
| slow down and amuse expert debuggers.
| josephcsible wrote:
| > it wouldn't be worthwhile to track down every possible
| case.
|
| I disagree with this conclusion. I think websites being able
| to detect or interfere with devtools should be considered a
| security bug. Do we give up on stopping XSS and memory
| corruption because it's too hard to detect every possible
| case of them too?
| iaml wrote:
| You could fix it by doing Object.getOwnPropertyDescriptor(div,
| 'id') to check if there's a getter instead of plain value, not
| sure about performance impact though.
| graderjs wrote:
| But a work around might be being able to craft a Proxy target
| that looks like a HTMLDivElement but has a handler that
| captures the get('id') operation, and does the same thing as
| the example. In that case it may not be so easily
| inspectable...
| hoten wrote:
| No need to do any of this when you control V8. Chrome
| DevTools can decide to run code iff there are no side
| effects (by executing it and bailing on any writes/native
| functions like alert marked as having side effects).
| Presumably it costs some overhead to do that and that is
| why logging elements to the console does not enable the "no
| side effects" flag.
| 1vuio0pswjnm7 wrote:
| "This trick can of course be very helpful not only to attackers
| but to other entities as well (such as big companies who want to
| alter their code when it is being investigated by researchers for
| example)."
|
| Two people are having a conversation.
|
| Person #1: How do I know the difference between an "attacker" and
| "other entities". Could a "big company" be an attacker.
|
| Person #2: An attacker is trying to do something bad and does not
| want you to see what its doing. A big company is doing something
| good and does not you to see what its doing.
|
| Person #1: Wait, how do I know if what its doing is bad or good
| if I am prevented from knowing what its doing.
| michael-ax wrote:
| the links you want: https://weizman.github.io/?javascript-anti-
| debugging-some-ne... https://github.com/weizman/awesome-
| javascript-anti-debugging
| is_true wrote:
| thank you
| thrdbndndn wrote:
| Rookie question: how do you disable pause on "debugger" keyword
| in Chrome devtool (without disabling other breakpoints, which
| Ctrl+F8 does)?
| jenscow wrote:
| Right click on the line number (of the debugger statement), and
| select "Never pause here". You'll need to do that for each
| statement.
| rasz wrote:
| The trick is you never know where debugger was really called
| from, try it https://9anime.to/watch/a-certain-magical-index-
| dub.l1kn/ep-...
|
| You can bypass this by killing setintervals altogether.
| thrdbndndn wrote:
| I actually managed to bypass this without destroying
| `setInterval()`.
|
| After a few times clicking "continue", Chrome showed me
| where the debugger line is in a VM script. And then I can
| disable it as OP said.
| thrdbndndn wrote:
| Wow, never knew this. Thanks!
| rasz wrote:
| You cant. Just getting a list of defined setintervals and
| settimeouts would help a lot, like you can access Event
| Listeners. Afaik devtools has no facility to do that :(
___________________________________________________________________
(page generated 2021-09-05 23:01 UTC)