Hi, ive been testing Ai to inflict attacks to my OpenWRT Router and it came up with the following:
Shellshock attack (CVE-2014-6271)
POODLE attack (CVE-2014-3566)
Also mentions about: glibc - though no detail about this.
Can this be looked into, and if these vulnerabilities exist, can this be corrected asap.
Currently running:
Powered by LuCI openwrt-22.03 branch (git-23.039.29681-007c243)
What does your Ai do... search Google for openwrt vulnerabilities.
Those two are from 2014, That's 9 years ago and are of no concern now since they were patched a week or two after discovery.
Maybe todays code does not take into account the full implications of these CVE detections.
Even though this has been detected years ago, code changes, and people forget to include.
All im asking is if these two CVE`s be re-tested against the latest build of OpenWRT.
As for my Ai Model ive created, this is part of the test to see if its incorrect in its findings.
Just to add, my Ai Model does not use Google to find answers.
Though it does use Google for the known CVE`s.
My Ai is in constant training Mode. The way it does that, im not willing to share.
Though i will raise concerns.
That would be up to you to re-test these if you so wish.
Enough said.
I am not fully competent with OpenWRT
This would be down to the Dev-Ops of OpenWRT to peform these tests and rectify accordingly, maybe my Ai may be incorrect, though would you want your Router to be secure and this be ruled out, and my Ai wrong.
If so, i can make my Ai Model aware of this and make adjustments to test further to protect the OpenWRT OS.
Sounds easy enough, Just teach the Ai that once it finds a CVE that it has to find out if the problem was solved and I don't think it will find the answer to that just searching the cve data base.
It was obvious to me that your AI used Google because I know for a fact it was not alive 9 years ago.
Edit: I have never played around with an Ai ... Good luck and hope you learn and have fun along the way
What are its findings?
A) it found these two 9-year old CVEs and it created an attack test against current OpenWrt, and it succeeded?
Or
B) it found the ancient CVEs and you are wondering.
If B), it sounds like just a weak search result, without much intelligence.
If A), then it is more alarming, as the upstream fix implementations in the upstream components (bash, SSL libraries) would have disappeared during the years. (OpenWrt just bakes in the upstream libraries.)
Note that neither of these CVEs was native to OpenWrt, so you should actually target the AI to specific upstream projects.
Ps. Note that shellshock specifically concerned the "bash" shell, which OpenWrt does not use.
It is amusing to see shellshock, that was fixed when it was first raised and never impacted busybox.
Similarly, poodle is an old ssl3 attack vector, patched in the upstream libraries when first announced and made obsolete when ssl3 was sunsetted.
Neither of these impact openwrt.
Not installed by default (OpenWrt uses musl). Something seems odd about this statement.
What happens when you run an official, current release?
I'm not the OpenWRT project and don't play them on a popular daytime soap opera, however I confidently assert that the project is very welcoming of vulnerability reports despite the lack of security.txt or use of the canonical email address with a published PGP key.
While details may vary among software publishers, the general expectation is that the researcher does sufficient work to demonstrate a vulnerability of versions of the software and attempt to report it in good faith via the preferred channels. Ideally a safely tested demonstration of the exploit or vulnerability is included. For well known vulnerabilities such as Shellshock and POODLE, this should not be too much to expect.
For new vulnerability researchers just getting started, it's easy to become disappointed when you have a secret magic testing method and make a vague report of the findings in a support forum, but get nothing better than a response like this telling you to try harder, starting with learning how to create and submit vulnerability reports. Please rest assured that users of the software such as myself appreciate the effort which goes into finding and sometimes helping fix vulnerabilities in the software on which we rely.
Perfectly worded, though disappointing, i will try harder; grammatically correct of course.
I will add; when a very old exploit has been tested, and solved, the manipulation of exploits still exist.
Microsoft and Apple still patch today old vulnerabilities, which was corrected at the time of detection.
This might fall inline: "complacency of security"
Upper case the first person singular. A comma would work better than a semicolon, though that is more a matter of style than grammar. You need an adverb, not an adjective, since it applies to a verb, not a noun.
With that most important matter out of the way, testing Luci on one of my devices running OpenWrt 22.03.3 r20028-43d71ad93e / LuCI openwrt-22.03 branch git-22.361.69894-438c598 with testssl 3.2rc2:
$ testssl --wide --vulnerable ap2
...
Testing vulnerabilities
Heartbleed (CVE-2014-0160) not vulnerable (OK), no heartbeat extension
CCS (CVE-2014-0224) not vulnerable (OK)
Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK), reply empty
ROBOT Server does not support any cipher suites that use RSA key transport
Secure Renegotiation (RFC 5746) supported (OK)
Secure Client-Initiated Renegotiation not vulnerable (OK)
CRIME, TLS (CVE-2012-4929) not vulnerable (OK)
BREACH (CVE-2013-3587) no gzip/deflate/compress/br HTTP compression (OK) - only supplied "/" tested
POODLE, SSL (CVE-2014-3566) not vulnerable (OK)
TLS_FALLBACK_SCSV (RFC 7507) No fallback possible (OK), no protocol below TLS 1.2 offered
SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK)
FREAK (CVE-2015-0204) not vulnerable (OK)
DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK)
no RSA certificate, thus certificate can't be used with SSLv2 elsewhere
LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
BEAST (CVE-2011-3389) not vulnerable (OK), no SSL3 or TLS1
LUCKY13 (CVE-2013-0169), experimental not vulnerable (OK)
Winshock (CVE-2014-6321), experimental not vulnerable (OK)
RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK)
Testing the device with the Greenbone Enterprise (known) vulnerability scanner, Dropbear is identified but there are no vulnerabilities in it detected.
You are quite right insofar as old vulnerabilities resurface for a variety of reasons such as code regression, incomplete fixes, or introduction of new vulnerable code; some remain unfixed in certain products due to irresponsibility and occasionally new exploits are found for "fixed" vulnerabilities.
We rely mostly on others such as yourself to keep testing and reporting vulnerabilities.
That's all fine, but reporting security issues is only of interest, if the security issues actually exist or at least can be reasonably expected to exist (e.g. because a known vulnerable package version is used by OpenWrt, without any relevant patches being applied). In case of the issues you reported, something is -very- off, as neither of those can exist (OpenWrt not using glibc by default, and when built against glibc in a custom build, only in combination with much newer versions than the affected ones, SSL3 support isn't even available anymore, nor is bash installed by default (and if manually installed, in a much newer version than anything vulnerable).
So far, your AI has been more of a test of the patience of these readers here, than hinting at any real security issues - and false alerts do harm everyone just as much as security issues would. Please, do report issues, but please also pay at least a minimum of attention to actually confirm that these exist, before reporting.
To add to slh's points:
If your AI finds some issues, you need to do some basic sanity checks on the alleged CVE itself.
For instance, ShellShock has been fixed in bash since 4.4 at least, and OpenWrt 22.03 is at bash 5.2.15, so a cursory analysis of the CVE metadata from cve.mitre.org or nvd.nist.gov should tell you that your AI has hit a "false positive".
You should make this verification a part of your basic AI model - you need to have up-to-date metadata for all CVEs, which shows what versions fix which ones, and compare the actual version detected against that.
Unless your AI happens to have an actual repro test that it can execute against the image, you need to believe the actual versions over whatever your AI might otherwise conclude from its other rules and knowledge.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.