Are these binding attacks applicable to Nettalk?

Tags: #<Tag:0x00007f224f785668> #<Tag:0x00007f224f7854b0>

This white paper highlights how scripting languages like Javascript can be used in a binding attack
xu:cooper.pdf (huhong789.github.io)

Abstract—Scripting languages like JavaScript are being integrated into commercial software to support easy file modification. For example, Adobe Acrobat accepts JavaScript to dynamically manipulate PDF files. To bridge the gap between the high-level scripts and the low-level languages (like C/C++) used to implement the software, a binding layer is necessary to transfer data and transform representations. However, due to the complexity of two sides, the binding code is prone to inconsistent semantics and security holes, which lead to severe vulnerabilities. Existing efforts for testing binding code merely focus on the script side, and thus miss bugs that require special program native inputs.

134 bugs, 59 vendor fixes, 33 CVE’s, 17 bug bounty pay outs totally $22k .

The focus is on the most popular programs like MS Word and the most popular PDF programs like Adobe Acrobat, Foxit Reader, IDA Pro for python.

Their testing tool dubbed COOPER with source can be found here GitHub - TCA-ISCAS/Cooper: A tool for effective testing the binding layer of scripting languages

I dont have a nettalk server to test, but I know a website where I can find alot of nettalk webservers, but I cant mention its name on here, my posts will get moderated. :crazy_face:

So no, these binding attacks are not applicable to NetTalk. While I haven’t read through the whole paper, the first line of the abstract precludes NetTalk;

Since NetTalk does not integrate JavaScript into the program, it’s outside the scope of this. (It serves site JavaScript (not user-injected JavaScript) and uses this pre-ordained JavaScript in the UI. But the JavaScript does not interact at the Exe level.

There’s no shortage of live NetTalk web servers. their existence is not a secret, and no security is gained from keeping them a secret. You are welcome to probe any site you like - and if you’d like to do something more formal (and potentially destructive) then let me know - I’d be happy to set up a test server for you.

As I mentioned in the other thread WebServer apps are constantly being probed an “attacked”. One thing newbie server owners notice almost immediately is that inside the first half-hour of a site being online it starts getting “random” requests, some of which are obviously trying to exploit some known vulnerability in some known server. I see these all day long, even in my test programs if they are running for more than a few minutes.

For a while we ran regular pen tests ourselves (100 000 test requests are not uncommon in these situations) and it’s a little anti-climactic to spend $1500 and get a report that says “all ok”. We got a professional security expert to do an assessment of one of our servers - he wasted 2 weeks of his life, and again the report had nothing to say. Every so often a user will run a pen test of their own against their own server and of course if anything is raised we deal with it. But it’s usually stuff like “the password for login is not strong” when they supply demo/demo for the pentest to try against.

An analogy is Hiking versus Rock Climbing. Hiking is a “safe” sport - you put on some shoes and go walking. When bad things happen you may be unprepared (since they seldom happen.) Rock Climbing though is dangerous (if done wrong) - so (not surprisingly) the safety protocols are very strict, and everything is checked, and double-checked. Consequently more people die hiking than climbing.

In the same way the NetTalk Webserver is exposed day and night to the whole world. Hence it has to be very secure. Security is built in from the ground up in every part of the system. By contrast, chances are an insecure desktop is fine just because the potential hacker list is tiny.

Of course, as you know, security is a process, not an event. Keeping servers reasonably up to date is important. (Not every build, but every year or two is a good idea.) Climbing with that 20 year old rope is not necessarily ideal…

Cheers
Bruce

So the word “integrate” doesnt give away much, and most websites/webserver use javascript but also other languages like CSS to control the webbrowser. Its possible to use CSS to fingerprint a webbrowser ( CSS Fingerprint (csstracking.dev) ) so the question becomes how much/far does the integration go?

I didnt know if you have some sort of table that matched up the limited javascript data types to the clarion (or whatever its written in) nettalk webserver data types, in much the same way the Clarion Data Type Conversion Rules exist (see Clarion Help Data Type Conversion Rules).

This tool called Cooper is based on another called Favocado favocado-ndss21.pdf (asu.edu)

In the Cooper paper this assertion is made

As commercial software is usually written in low-level languages like C/C++, a binding layer is necessary for transferring the arguments and transforming the representation for the high level scripting languages. However, since the software and the script are developed independently, the binding layer is prone to produce inconsistent representations or miss security checks, which lead to tons of severe security vulnerabilities

So when you make the point its different, and yet the paper is saying what it says above, how exactly is Nettalk precluded from this situation?
Can you do a ELI5? :crazy_face:

From a sales perspective, I think the best sales people are the one’s who lets others go try to beat its features, AFAIK even the likes of MS, Google, Apple, Apache, NgInx dont put webservers up for anyone to hack and yet, thats the best form of selling imo.

I dont think I would be the only one who might want to have a go, so I’d be happy if you set up a webserver, it can be invite only to avoid the DDOS and bandwidth burn and then see if any red teams can capture the flag so to speak.

It will give you something to talk about for your next devcon or clarion live meeting.

So what do you use for your pen test then? Here is one of Google’s fuzzer’s GitHub - googleprojectzero/domato: DOM fuzzer
so why not run this between your firewall and nettalk webserver or even internally on your own lan?

I assume you have instructions for clarion dev’s to help them setup fuzzer’s like the google one above to make sure they havent made a mistake somewhere before they deploy their website, at least that way internally testing on a lan will eliminate the $1500 affirmation.

Did he give you a certificate I just wondered if he is any good, maybe you’d want to post it on the nettalk website?

Its why fuzzer’s handle the low level fruit for testing webservers.

Edit.
I could refer you to this post Is it possible to store template symbols in a template so they can write out their value in the clw? which highlights what seems to be a new way of accessing the template symbols. I say new way, because I think I was clear in my post what I was trying to achieve but I am also aware American English, or South African English has different meanings in British English, I see this even within the UK like the Scottish version of Wikipedia Wikipedia:Spellin an grammar - Wikipedia
but its not exactly the same use of evaluate as the %Stripling function demonstrates in the shipping templates. And there does some to be some undocumented features in the clarion language and template part of the language, which is what fuzzer’s can be good at finding especially when error messages are not thrown.

We need to be clear about the terms here. WebServers don’t use JavaScript. WebSites aren’t a “thing” so let’s not use that word. Browsers are the thing that uses JavaScript to manipulate the DOM. In other words Browsers are the program that uses the JavaScript. So you could question whether this attack is applicable to Browsers (it’s not) which is why the article focuses on programs that execute JavaScript as part of their document format.

Again, NetTalk is not susceptible to this attack precisely because NetTalk does not execute any JavaScript code. In our context only the Browser is executing this code.

There is no table, because there is no JavaScript.

[Aside: We could have a separate conversation about Chrome Explorer - but that’s a different animal and outside the context of this thread.]

That’s a completely different topic again - and is the web site creator making use of server side tools to track browser clients. It’s not hacking, in the sense that the server and browser are performing exactly as intended, and specifically as the server is programmed.

NetTalk is not a scripting language. It has no scripting language. There is no binding. There are no arguments. There is no transforming. There is no representation. I’m not sure how to make this any clearer :slight_smile: NetTalk is not subject to this attack in the way that MS Paint is not subject to this attack.

I’ll provision a web server for you that you can hack against. There’s no problem doing that. (Won’t be today, since I’ve got things on the go, but I’ll post when it’s up.)

It won’t really :slight_smile: - it doesn’t take long to say “nothing happened” :slight_smile:

That’s outside the scope of what I do. for those that want to run pen tests there’s lots and lots of information and experts on the internet to make that happen. Certainly I’m not the ideal source for that information.

Certificates aren’t worth anything. He’s good enough that he heads up a network security for a large local bank (after being head-hunted from a big network security consultancy.) So I’m not saying he’s the best in the world, but he hacks servers and networks for a living. Apparently his employer thinks he’s good enough…

I’ll post the server when it’s up and you can feel free to give it a go, and see if you can do any better :slight_smile:

So what you are saying then is, there is no javascript engine/parser built into nettalk?
In otherwords any javascript served by nettalk is just output, not output and input?

So these fuzzers:
gramfuzz - A grammar-based fuzzing library — gramfuzz v1.4.0 documentation (d0c-s4vage.github.io)
GitHub - SoftSec-KAIST/CodeAlchemist: Semantics-aware Code Generation for Finding JS engine Vulnerabilities
GitHub - WSP-LAB/Montage: Montage: A Neural Network Language Model-Guided JavaScript Engine Fuzzer
GitHub - MozillaSecurity/funfuzz: A collection of fuzzers in a harness for testing the SpiderMonkey JavaScript engine.

can be used in a browsing environment along with other techniques and they shouldnt work on Nettalk.

but a remote code execution flaw still existed.
Paint 3D for Windows 10 had a Remote Code Execution flaw - MSPoweruser
CVE - CVE-2021-31946 (mitre.org)

Ok, obviously defining boundaries is useful.

No rush, I’ve got plenty to get on with here, but I think it would be a good exercise, even for learning how to setup the fuzzers as I’m sure some of them could be adapted to testing clarion apps. :wink:

Will anyone be able to have a go at the nettalk webserver, what will be the rules?

exactly.

Once you are in a browser environment you are testing the browser, not nettalk.

a) you’re talking about Pait3D, not Paint. And b) I’m not saying Paint has no flaws, I’m saying it’s not subject to a JavaScript binding attack, since it doesn’t include a JavaScript parser.

I’m not sure there will be any rules. I’ll set up a throw-away VM. I guess once the bandwidth exceeds some finite number of $ I’ll shut it down.

Cheers
Bruce

So a couple rules I think there should be, is all the facilities/functions across the example apps should be included because ideally we would want it to be a real world test, and most nettalk users will be using some of the facilities/functions.

The DLL’s used by nettalk server should be accessible for download & analysis ie zipped as anyone can buy nettalk and then use this info to craft an attack, ergo, to maintain its real world authenticity, unless you can account for every user and their computer security?

I dont know if anyone else wants to step in and make any suggestions. :grinning:

they’re welcome to buy NetTalk (and I presume Clarion?) if they want to read the classes, de-compile the DLL’s and so on :slight_smile:
In fact if they want the DLL’s they can jsut download a demo from our web site - that’s freely available.

I’ll put up one of the example apps, with some sample data, protected by say a login, and we’ll go from there. Sound about right?

I think so, I think it will be interesting to see what these fuzzer’s can do amongst other things but I got to get them translated first so I wont be looking at it for at least a week FYI. :grinning:

Node does but not in the way that this discussion is heading.

So whilst I’d heard of it before I’ve never looked into it, but it seems there are essentially two “engines” or runtimes.

So the webbrowser implementation is called V8 and is used in all Chromium web browsers, QT quick time, and other places originally developed by Google, its even capable of developing bytecode.
V8 (JavaScript engine) - Wikipedia
I suspect this has gained traction because many will remember that MS implemented their own version of javascript in Internet Explorer so web developers had to maintain different versions of their website for different browsers. Website javascript code should run consistently on all web browsers that implement V8. It also looks like it has some of the .net features with Just in Time compilation and Garbage collectors.

Node.js - Wikipedia
Was built on top of Googles V8 engine, but confined to the webserver, so perhaps it could be viewed as the other half of the javascript handshake with V8 being the first half.
Unlike PHP which blocks commands until complete, Node allows commands to run concurrently or in parallel and uses callbacks to signal outcomes and it introduces event driven programming to webservers.

There are alot of “packages” which interface with other languages including .net
Node.js - Wikipedia

To sum it up, its like the Clarion runtime was upto C5.5. In other words it doesnt support threading, its a concurrent “threading” model with an event loop.

And it also supports Web Assembly or WASM and WASI aka the Web Assembly System Interface which the latter is what gets you onto systems, hard drives and other components in plain sight! :wink:

However these binding attacks will probably work on Node & V8, in other words dont think only a webserver will come under attack but some websites can be malicious and will attack your web browser to get onto your computer that way.