Storing a salted hash would be nice, but scopes without ntp or internal wall clocks are the norm, so not sure what to salt with. And a plain hash is pretty easy to beat right? As far as getting the hash, these are people who are using oscopes, it doesn't seem unlikely they could jtag it out without some decent safeguards in place. Worrying about physical security on an oscope seems like a bad risk management trade.
Scopes have massive amounts of true random data at their disposal. :P
This isn't a nonce where you might need some kind of special timing properties.
We hash so that people can't grab your password and use it elsewhere. We add some salt to make the hash more robust to memory and precomputation attacks.
I don't think it's strncmp itself that's the problem. They fucked up and are only checking that the provided password matches a prefix of the stored password. And obviously an empty string is a matching prefix.
The (decompiled) code looks very amateurish in general. Like, who writes something like system("echo >... or system("sync"). Looks like something written by a very green engineer/intern and not reviewed by anyone else.
Sadly this looks like "industry standard" to me. I have seen many embedded Linux devices using mostly C applications and a lot of usage of the system() function with no or very poor input validation before. When you want to exploit embedded Linux devices always look for calls to system() first.
The "strncmp(saved_pwd,pass0,strlen(pass0))" looks equally bad. Probably someone did not understood the advice "always check the length first" and just did it everywhere.
Many of these faults are simply the consequence of never reading the manpage of a function but making assumptions about implementation details of an imaginary version of a function with the same name.
"The strncmp() function is similar, except it compares only the first (at most) n bytes of s1 and s2."
Possibly it's years of string wrangling in C that sets me up here for being biased towards the compact way in which the C manpages state what the function will do, but 'early termination' because of zero length strings for comparisions returns 0 just as sure as comparing "" and "" would. And that 0 indicates a match...
Of course an experienced developer would have thought about edge cases, but I can see a thought process like: ok, I'm comparing two strings. "" != "123" in languages with built-in string types.
I'm definitely not arguing that C shouldn't be used and everybody should be using <insert-the-currently-trendy-systems-programming-language>: just thinking out loud if improved documentation could prevent at least some of the common footguns.
Embedded Linux engineers in general are not incompetent. Many of us do care about quality of the software we write. Although you are right that there is a lot of dodgy embedded software around, that isn't a reason to accept mediocrity like this in newly written user facing APIs.
I have never seen firmware from any vendor in any industry that doesn't use these patterns. There's a lot to unpack culturally around "hardware company engineers" vs "software company engineers," but I don't think this is "amateurish" so far as it is "industry standard from another industry."
I’m sorry, but your comment came right after the comment thread about a guy printing gay porn and I thought you were making a joke and I was giggling about the firmware and hardware thing and then I realized you were making a serious point.
I wonder who goes around thinking "I'm going to expose an oscilloscope to the WAN!". Something you have to do on purpose, taking lots of extra steps, because of CG-NAT. Kinda asking for it.
Many universities give everyone on their network a fully routed IP address, at least this was the case ten-ish years ago for me in Germany. Was ideal if you were developing something and showing it off to someone at the other end of the campus while being on the phone or Teamspeak - just give the other person your IP address and spin up a server at 8080, that's it.
Besides, if I were on a red team, I'd enumerate all devices on the LAN as well. Simply to look for all that old cruft someone set up years ago and never updated... that's where you get persistence. No one goes and checks 'scopes, network gear or printers for indicators of compromise in their firmware, because no one thinks of them if the admin isn't looking for outgoing Internet traffic.
> Many universities give everyone on their network a fully routed IP address, at least this was the case ten-ish years ago for me in Germany
Times have changed a lot in the past decade. No reasonable network admin would be giving public IPs to everything that connects to the network any more.
IPv4 addresses are also scarce relative to a decade ago.
Sadly, to my current understanding, my alma mater still does this. At the time it was extremely convenient - we had labs full of Solaris and Linux boxes, which could be remotely accessed from home without any issue. And I also seem to remember that basically nothing on IT's part had to be done during the Xbox 360 / Xbox Live craze, unlike my peers at other schools.
Even then, though, the downsides of consumer network security (mostly) relying on NAT were obvious. Common ports (80, 25, etc) were blocked inbound; the school's printers basically had to be on their own network, or get spammed all day.
Most of the staff/admins in the universities that I've worked in have relatively modern sensibilities when it comes to this stuff. However, their constituents, particularly on the academic sides of the house ... less so. I've heard a modest firewall policy argued against on the grounds of Academic Freedom, let alone private IP addresses.
There are so many devices on a campus network with nebulous ownership set up by clever but still-learning grad students and even undergrads, trying to secure the perimeter seems pointless. Someone internal will find a way to get hacked, or even themselves could be malicious (what are we going to do, background check every student?), so all the nodes on the network need to themselves be secured.
I talked to the security person at a German university a few years ago and suggested that they put some restrictive firewall rules in place to increase security. He agreed with me in principle, but lamented the fact that the grey beards in the university's network administrator team follow a philosophy which says that networks need (or want?) to be free.
Trust me, it's not the case. I sell electronic instruments for laboratories, and in the large majority of the cases they are simply attacched to the local network. And such network has simply internet access. I once made a blogpost to advise our customers how to create a local instruments network for higher performances and security, but I don't know how much impact it had
You are forgetting that many universities (at least in the US) are sitting on enormous allocations of address space due to being early users of the technology from DARPA.
Coupled with "NAT isn't a firewall", assigning actual IPs to your end devices isn't all that silly if you happen to have a few million to spare.
IPv4 exhaustion isn't nearly the issue for universities that it is elsewhere. Most unis grabbed a large allocation early on, before it was an issue. Many have multiple class B allocations; quite a few have As.
This is still the case I think, though admins now restrict the access for sensitive equipment. My work laptop's ethernet has a fully public ip4, for example.
In the era of IPv6 you can't assume that your device is implicitly firewalled for incoming connections. My smartphone currently has a public IPv6 address from my relative's home wifi network.
IPv6 is intended to always use public addresses. If you have an ipv6 address, it's probably public. But that doesn't necessarily mean there's no firewall.
I tried the online scan that you linked with my IPv6 address.
At the end it said
Nmap done: 0 IP addresses (0 hosts up) scanned in 2.20 seconds
Even though it claims to support IPv6
Also the site spent a whole lot of time showing progress bars and stuff.
Whereas when I run Nmap from one of my servers on the internet against my public home IPv6 address
% nmap -6 -A -T4 2a0c:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
I get:
Starting Nmap 7.94 ( https://nmap.org ) at 2023-07-16 17:43 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 2.23 seconds
So in conclusion yeah, that site you linked was not able to scan IPv6
I think better than that online version of Nmap is to run Nmap from another computer on another IPv6 enabled network against your own public home IPv6 address. Assuming you have additional computers like a server or a VPS, etc. Same way I did.
Another possible alternative is to use shodan.io and check what they have found in their past scans for your IP address. Seems that shodan requires creating an account now in order to use it. Not sure if it did before. I remember testing shodan.io a few years ago but don’t remember if I had to create an account then.
Nmap done: 0 IP addresses (0 hosts up) scanned in 2.20 seconds
And mine:
Nmap done: 1 IP address (0 hosts up) scanned in 2.23 seconds
And note that 0 IP addresses scanned is exactly what you get if you run nmap with an IPv6 address as target but without the -6 flag. They probably are doing just that; running nmap without the -6 flag.
But let's try something else.
% host google.com
google.com has address 142.250.184.14
google.com has IPv6 address 2a00:1450:4003:808::200e
google.com mail is handled by 10 smtp.google.com.
% nmap -6 -A -T4 2a00:1450:4003:808::200e
Starting Nmap 7.80 ( https://nmap.org ) at 2023-07-16 16:53 BST
Nmap scan report for mad06s10-in-x0e.1e100.net (2a00:1450:4003:808::200e)
Host is up (0.032s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE VERSION
80/tcp open http gws
[...]
Nmap done: 1 IP address (1 host up) scanned in 76.10 seconds
And now try putting 2a00:1450:4003:808::200e into their web tool and see what they report.
At the moment their website will get 0 addresses scanned for that as well.
Nmap done: 0 IP addresses (0 hosts up) scanned in 1.58 seconds
The site is actually spinning up a VM to run the nmap so those progress bars are real. Thanks for checking. I reached out to the creator and he will update it to work with IPv6.
Agree nmap from another machine is best but that's not always an option. I'm thinking like if I am on hotel wifi or something. I might not have easy access to another box.
But have you actually tested connecting to it from outside the network? Just because something has a public IPv6 address doesn't mean there isn't a firewall somewhere in between. It just means there's no NAT.
I wish we lived "in the era of ipv6". Unfortunately one of the biggest mobile providers in my country (and the only one available to me at reasonable speed) has no ipv6 setup. Also, they NAT their entire network.
So, to have any way to connect back to my home network I have to run a permanent vpn to a server in aws and connect to that.
If you're going to do SOHO routing safely/correctly, you'll need to do some sort of connection tracking. You'll need to allow packets on new and existing outbound connections, but only allow incoming packets on existing connections. SOHO routers generally won't support this in hardware, so you have to route on the CPU anyway.
NAT on IPv4 vs stateful routing on IPv6 is a wash in terms of performance.
> low end home routers have built-in NAT on the chip
Low end home routers have tiny connection tracking tables and fall back to software routing when that table overflows. IMO if you don't notice the massive drop in performance when this happens, you have very low standards/expectations for internet latency. In had to upgrade to a prosumer router just to get acceptable perf on IPv4
I'm thinking maybe they meant performance impact on peer-to-peer protocols like WebRTC, where if both sides are behind NAT, you might end up routing traffic between two local devices with a NAT gateway between them through a remote TURN server to establish connectivity.
There's no performance penalty for NAT that I'm aware of, I'd like to hear more about this. IPv6 OTOH has enough privacy busting concerns that I personally will never use it on my home systems. Trying to use only IPv4 on a smart phone though causes various connectivity issues, I've tried it. Google does own Android and wants to make sure they know as much about what we do on our phones as possible.
It looks like they never replied to him for months so he just published it. This would also fit with the HN title (conclusion in the post). I think if it was patched it would be "I found a bug".
> RIGOL says they would reply in 2-3 days, 1/28/23
> Full disclosure, 2/8/23
Those should be January 28 2023 and February 8 2023, which is the date of the post. It's only 13 days after the last communication from RIGOL, not months.
By the way, could at least us developers use ISO dates instead of whatever our local conventions are?
Usually when people say ISO8601, they mean "2023-07-12T09:20:00Z". But the actual spec, which no one reads because it costs money to access, allows dozens of other variations. (Too many IMHO.)
RFC3339 is compatible with "the good parts" of ISO8601 and it's also free.
I prefer to use dd/mmm/yyyy with mmm like jan/feb/mar etc that takes care of all confusion and seems to be understood the world over. This saves me from having to adopt some local convention depending on who I'm invoicing.
I don't think anybody reading my invoices will have trouble interpreting them, and if they need to sort then they're welcome to add their own version of the date. But at least there will be no ambiguity about when I sent the invoice.
Yeah, I agree that 13 days from the last contact was maybe a bit too fast. But they haven't replied to this day and I reported the vuln two months earlier without response!
P.S. sorry for the american time dates, I don't know what I was thinking lol.
Rigol is pretty famous for not really caring a single bit about security. It's helpful in one particular area, in that they sell the device in the OP for anywhere between $900 and $2900 depending on which features are enabled, except all of those features are software locked with the same attention to security as they do everything else.
The result is that you can get a hell of a lot of scope for very little money, but don't expect it to offer things like "robust security".
Sure, no judgement, but not openly so, except after this - and his was literally printing out the home pages of sites so it just showed thumbnails of the vids.. obv.
So I assume he was closeted (he was like 60 or so) and I assume he used the pages for fap material without an accidental phone copy - this was also the Treo and flip phone era - 2006 so IPhone hadn’t come out yet
>*No one in my office knows of my sexual past and what gets me hard*
Yep - its nobody's business - it was just that it was not even in the zeitgeist until he printed those - but luckily for him, it was lit btwn me (IT head), HR and whomever else was on his team/mgmt struct...
But I bet that guy suffered from cringe-thoughts-on-mistake for a few years to come.
As we all do. (ever cringe toss and turn over a stupid comment you made 20+ years ago?) (No? many people dont, but some people do... I am one of the some people)
Not the kind of disclosure you want to make on a website where there are a ton of people who are able to narrow this down to a handful of individuals. Not everybody on HN is nice. Also quite unprofessional.
The timeline of this vulnerability might just be the best argument I've ever seen for full disclosure:
2019-09-26 Reported to vendor with POC
2020-01-14 Followed up with vendor
2022-01-24 Publicly disclosed (still no fix over 2 years later!)
2022-01-28 Fix released by vendor
I wonder if the same will happen with this RIGOL oscilloscope vulnerability.
I agree. Life's too short for fiddling with the OS and i would have wiped PopOs from my Laptop a long time ago if it wouldn't work flawless, but it does (cheap Thinkpad L580).
FWIW I haven't had any hard tech issues with Linux across many different kinds of computers (laptops, desktops, servers, as well as some stuff never intended to run Linux at all such as Macs) and haven't had a serious hardware issue in more than 15 years. The biggest stumbling block was to get Linux installed on an early issue Macbook air just after it came out, other than that not a single glitch. Meanwhile, my family members have issues with their windows boxes every other week or so.
I'm sure there are plenty of people that never have a problem with Windows and that can't get Linux to work on their hardware but I'd be careful to generalize from personal experience.
For what is worth, last time I encountered compatibility problems wrt Linux on a laptop has been when I was using RedHat 6 or 7 on the cheapest+crappiest Asus laptop I could purchase at that time, and had to recompile kernel and gfx drivers at every update. That happened like 22 years ago, and was 100% the laptop's fault, not Linux, which also worked flawlessly on every laptop I installed later on.
> Since the driver part uses the driver code maintained by many chip manufacturers, we have no right to open it to users. We have tried to provide it to users in the form of ko, but we will always encounter many strange problems.
I think such devices anyway have anything lost in a companys LAN. Before such devices had a serial link to a PC. Now every device is in the office LAN. They can never be secure for the many years they are in service.
It has been like that since the 90s. At Stanford we had a sysadmin track down a warez site to our HP logic analyzer. Everything at Stanford in the 90s had a public IP address (at least in EE).
Probably an HP 16600/16700[1]. The control processor is basically a repackaged HP-PA workstation running a full version of HP/UX. Used X11 for remote access. The earlier 16500 had an optional, separate equivalent processor.
I have a 16702A, which includes a front panel LCD and keyboard console. It's a beast.
Maybe easy fix would be some certification requirement for routers that by default ports to device are closed even from same network?
Some time ago there was issue with default passwords and it got solved with default passwords unique to device.
Such is life with CVEs, unfortunately. While there are some great central repositories of information there is often very little in the way of consistent information on the disclosure process itself.
It's pretty clear to work out what happened from the timeline listed: RIGOL didn’t do shit.
The style the author chose to list the timeline is IMHO the most faithful, honest, and polite way of communicating it without adding wrong or legally problematic reasoning to the situation, from their perspective.
This is RIGOL we are talking about. In a year, they will release a firmware that solves the RCE but opens two more and also breaks cursors (or some other very basic thing). A year after that, they will release a second firmware that fixes the cursors but breaks the calibration and still has the two new RCEs.
Instruments like this normally boot from a read only image, so even if you have root access to the box you can't do anything bad to it, well, nothing that won't disappear on reboot.
On my Siglent scope (an SDS2104X plus) you can easily hack it to enable telnet access. This requires physical access to the device to add a USB stick with a file on it to achieve this, but it's then very open (described here https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus...)
It was actually one of the things that attracted me to this scope, that it was to some extent hackable. Compared to other scopes like the old Tektronix ones running VxWorks it's nice to have something familiar behind the scenes.
Exactly! A curl 1-liner to get root access to the Linux shell running on my Rigol scope (an older 1074Z-S...do I even have a webserver?)
Think of all the awesome things I could do!
This security vulnerability does not make me worried, it makes me happy. Rigols have always been somewhat hackable, this is an even easier way to do it.
I have no qualms with "acting your wage." This goes below the minimum bar in my opinion. Real engineers don't get away with fuckups with real consequences because of their salary.
I'm not giving you a justification, I'm telling you how it is.
> Real engineers don't get away with fuckups with real consequences because of their salary.
I mean they absolutely do.
What is a "real" engineer anyway? I am a licensed engineer (electrical) because I used to work independently as an engineering firm. I understand the various definitions.
The overwhelming majority of those with a title of electrical or computer engineer do not have any kind of professional licensure or certification - at best they may have an accredited 4 year degree.
None of these people are going to be personally liable for fuckups of any kind in their careers.
You've probably heard of useless use of cat, but this is a useless use of echo. Given that the code even opens the file in question several lines above, I'm surprised that the author didn't know about fprintf.
It seems the device embeds a conventional ARM Linux. If I were developing embedded software for a device like that, I would have used asp.net core runtime.
It’s much easier to create secure web apps using C#, compared to cgi-bin written in C for lighthttpd web server.
Most test equipments, ancient or recent, are not expecting their programming interfaces, let it be an analog voltage, GPIB, RS232, USB or LAN, exposed to the public internet and it would be a extremely stupid thing to do so. The maker of them assume that if one is able to operate them, one should know where they should plug the cables in.
These equipments are simply assuming that anyone can access the interface is not hostile. This is a pretty good assumption in most lab settings that I know, unless the operator is so ignorant. This assumption certainly have made my life much easier in the lab, of course, where every LXI test equipments are connected to a isolated LAN. I would say a lot more f*k in the lab if I have to authenticate myself before sending a SCPI command. I'm happy that most test equipment makers do agree with me.
For example, modern Rohde&Schwartz gears running Windows or Linux (FSV, FSW, FSVA, FSUP, SMA, SMC, ZNL, etc.) have VNC or Windows RDP enabled by default, and have a weak default password shared among the series. Keysight ones too (E5071C, DSOX3000T, maybe not on by default but with a supported way). A hostile user can even screw up a LAN connected, damn simple VxWorks based multimeter like Agilent 34410A badly by sending the calibration commands at the wrong time or some backdoor commands (DIAG:xxxx, haven't tried but looks possible).
Slightly off topic, some Chinese test equipment makers are making hackability as a feature, look at Siglent or Rigol scopes. They can (and they are competent enough to) lock down the system with secure boot like some Tektronix ones. However they don't, so that people with less budget can buy a cheaper model and hack for the bandwidth.
People don't buy a fridge because they want a secure device either, that doesn't mean the manufacturer doesn't have a legal duty of care when releasing software with security vulnerabilities.
My issue with these "they don't need to worry about security" issues is that this issue is at its core still an obvious bug. If your password generator puts a ; in your password your attempt to set it will break.
I went through a similar argument with an intranet product that "didn't need to worry about SQL because it's on a trusted network" crashed when Bob O'Reilly tried to make an account.
Then it simply should not have a password. If everyone who can access it is benign by definition, simply remove the access control.
Having a password implies that it provides some meaningful security. A bad lock is worse than no lock, because it will lead people to put the instrument in inappropriate places.
Having a password makes it less likely that the script that your co-worker got in their email and ran behind your firewall will destroy your stuff as a side effect of scanning your network for things it can destroy.
I agree to some extent, that's why no one put a password to the telnet based LXI SCPI command interface.
But a weak password maybe useful sometimes, to prevent your coworker accidentally connect to the wrong equipment and mess up one's experiment.
Here it's never meant to deter a hostile coworker, in that case one reports to one's superior rather than rely on the password which is always stickered to the scope itself (in my lab).
Lots of these tools have truly awful software engineering. Even companies that are top, premium brands have some really questionable decisions like embedding backdoor passwords in the firmware.
Never connect these things to the internet or any untrusted network. Last thing you need is a 10k instrument bricking itself.
As most have already written here, this is no suprise. These devices are made to do one job. The whole IoT thing is just cause it something that was hyped. They did try to lock down the scope _a little_. E.g. they removed the incoming RX resistor so you couldn't use the console. They disabled SSH etc. But the scope is very hackable, both in terms of the mentioned unlock ability, but also in terms of accessling Linux. The fact that this is about a RCE, is 'troublesome' but also 'meh'.
I'm mostly disappointment that the author didn't do any research. While I get the cool-factor of trying to hack the firmware from scratch, a simple search would have found the author the EEVblog [0] for starters. But i admit, it is 104 pages atm. And the biggest dissapointment, an obviously shameless plug, is that this 'reversing' of the firmware, was done more then 5 years ago [1] where I wrote scripts to extract the whole firmware automatically.
There's even rumor that the entire source code has leaked onto the internet already.
I would expect some research would have made this 'discovery' less of an 'omg there's an RCE!'
Hey! Congrats on the reverse engineering work and all the time you put in your research. As you and many other people have already said, RIGOL scopes are not exactly a security fortress, so this exploit I've found isn't impressive at all.
After finding the vuln, I checked online if someone else had already found the vuln, and I admit I have come across the EEVblog, but I didn't find the exact vuln I found (I also must admit I didn't read all the posts there).
I am sorry if I have in some way disrespected your work, but it wasn't my intention at all!
139 comments
[ 4.2 ms ] story [ 186 ms ] threadBypassing strncmp was particularly insightful.
Scopes have massive amounts of true random data at their disposal. :P
This isn't a nonce where you might need some kind of special timing properties.
We hash so that people can't grab your password and use it elsewhere. We add some salt to make the hash more robust to memory and precomputation attacks.
The "strncmp(saved_pwd,pass0,strlen(pass0))" looks equally bad. Probably someone did not understood the advice "always check the length first" and just did it everywhere.
Intel AMT checked the password in a similar way some time ago: https://www.tenable.com/blog/rediscovering-the-intel-amt-vul...
I often remember my PHP days in horror, but mysqli_query manpage does warn you about SQL-injections now.
"The strncmp() function is similar, except it compares only the first (at most) n bytes of s1 and s2."
Possibly it's years of string wrangling in C that sets me up here for being biased towards the compact way in which the C manpages state what the function will do, but 'early termination' because of zero length strings for comparisions returns 0 just as sure as comparing "" and "" would. And that 0 indicates a match...
I'm definitely not arguing that C shouldn't be used and everybody should be using <insert-the-currently-trendy-systems-programming-language>: just thinking out loud if improved documentation could prevent at least some of the common footguns.
Besides, if I were on a red team, I'd enumerate all devices on the LAN as well. Simply to look for all that old cruft someone set up years ago and never updated... that's where you get persistence. No one goes and checks 'scopes, network gear or printers for indicators of compromise in their firmware, because no one thinks of them if the admin isn't looking for outgoing Internet traffic.
Times have changed a lot in the past decade. No reasonable network admin would be giving public IPs to everything that connects to the network any more.
IPv4 addresses are also scarce relative to a decade ago.
Even then, though, the downsides of consumer network security (mostly) relying on NAT were obvious. Common ports (80, 25, etc) were blocked inbound; the school's printers basically had to be on their own network, or get spammed all day.
You are speaking about academia. It's not mutually exclusive, but it's different then out there in the wild.
It is indeed a different environment.
Instead, you should put a default-deny rule on your firewall for all incoming traffic to user devices (which is generally the default setting anyway).
Coupled with "NAT isn't a firewall", assigning actual IPs to your end devices isn't all that silly if you happen to have a few million to spare.
Here is a service that will show you both your public IPv4 and your public IPv6 address.
https://whatismyipaddress.com/
Still, that's the only nmap-in-a-website I'm aware of. There are probably others.
Does the nmap scan work on IPv6? That site might actually only be IPv4...
At the end it said
Nmap done: 0 IP addresses (0 hosts up) scanned in 2.20 seconds
Even though it claims to support IPv6
Also the site spent a whole lot of time showing progress bars and stuff.
Whereas when I run Nmap from one of my servers on the internet against my public home IPv6 address
I get: So in conclusion yeah, that site you linked was not able to scan IPv6I think better than that online version of Nmap is to run Nmap from another computer on another IPv6 enabled network against your own public home IPv6 address. Assuming you have additional computers like a server or a VPS, etc. Same way I did.
Another possible alternative is to use shodan.io and check what they have found in their past scans for your IP address. Seems that shodan requires creating an account now in order to use it. Not sure if it did before. I remember testing shodan.io a few years ago but don’t remember if I had to create an account then.
Also I'd be extremely surprised if Shodan had anything on your IPv6 address.
Nmap done: 0 IP addresses (0 hosts up) scanned in 2.20 seconds
And mine:
Nmap done: 1 IP address (0 hosts up) scanned in 2.23 seconds
And note that 0 IP addresses scanned is exactly what you get if you run nmap with an IPv6 address as target but without the -6 flag. They probably are doing just that; running nmap without the -6 flag.
But let's try something else.
And now try putting 2a00:1450:4003:808::200e into their web tool and see what they report.At the moment their website will get 0 addresses scanned for that as well.
Nmap done: 0 IP addresses (0 hosts up) scanned in 1.58 seconds
Agree nmap from another machine is best but that's not always an option. I'm thinking like if I am on hotel wifi or something. I might not have easy access to another box.
Shodan is a great suggestion.
In the network path. On the device. They control what packets get allowed or denied.
So, to have any way to connect back to my home network I have to run a permanent vpn to a server in aws and connect to that.
NAT on IPv4 vs stateful routing on IPv6 is a wash in terms of performance.
Low end home routers have tiny connection tracking tables and fall back to software routing when that table overflows. IMO if you don't notice the massive drop in performance when this happens, you have very low standards/expectations for internet latency. In had to upgrade to a prosumer router just to get acceptable perf on IPv4
Rigol made their own ADC chip that beats most off the shelf stuff yet they have some of the jankiest software and English translation known to man.
> RIGOL says they would reply in 2-3 days, 1/28/23
> Full disclosure, 2/8/23
Those should be January 28 2023 and February 8 2023, which is the date of the post. It's only 13 days after the last communication from RIGOL, not months.
By the way, could at least us developers use ISO dates instead of whatever our local conventions are?
3 months of total stalling without a real reply to him. The last communication was only that they'd provide more details in a few days.
The fact that he asked again before the disclosure timeframe and they were like "uh, just give us a minute" doesn't change anything.
2023-28 and 2023-39 aren't any more readable.
RFC3339 is compatible with "the good parts" of ISO8601 and it's also free.
https://www.rfc-editor.org/rfc/rfc3339
P.S. sorry for the american time dates, I don't know what I was thinking lol.
The result is that you can get a hell of a lot of scope for very little money, but don't expect it to offer things like "robust security".
Maybe he's bi.
So I assume he was closeted (he was like 60 or so) and I assume he used the pages for fap material without an accidental phone copy - this was also the Treo and flip phone era - 2006 so IPhone hadn’t come out yet
But what does it mean to be openly bi as a married man?
No one in my office knows of my sexual past and what gets me hard, they might know I have a girlfriend.
I'd be more concerned if someone the office was aware of his sexuality in detail. Usually means there has been sexual harassment.
Yep - its nobody's business - it was just that it was not even in the zeitgeist until he printed those - but luckily for him, it was lit btwn me (IT head), HR and whomever else was on his team/mgmt struct...
But I bet that guy suffered from cringe-thoughts-on-mistake for a few years to come.
As we all do. (ever cringe toss and turn over a stupid comment you made 20+ years ago?) (No? many people dont, but some people do... I am one of the some people)
CVE-2022-23968: https://neosmart.net/blog/xerox-vulnerability-allows-unauthe...
No, this is not Linux zealotry, I also advocate against using Linux as a daily driver on a modern laptop.
The right tool for the right job: OpenWRT on routers, Windows + WSL on laptops.
But, you are asking, how do you use your Windows laptop like this when away from home?
Easy: GL.iNet has tiny travel routers with OpenWRT supported out of the box.
If it works just as well and floats my boat, why change to windows?
I'm sure there are plenty of people that never have a problem with Windows and that can't get Linux to work on their hardware but I'd be careful to generalize from personal experience.
It supports modified OpenWRT with proprietary drivers, which are closed source. Still better than completely black-box travel routers but /shrug.
From https://github.com/gl-inet/glbuilder:
> Since the driver part uses the driver code maintained by many chip manufacturers, we have no right to open it to users. We have tried to provide it to users in the form of ko, but we will always encounter many strange problems.
Why would you do that?
I have a 16702A, which includes a front panel LCD and keyboard console. It's a beast.
[1] https://www.keysight.com/us/en/product/16700A/logic-analysis...
That's the kind of thing that makes this site special.
Vulnerability found, 2022-11-08
Sent detailed PoC, 2022-11-09
RIGOL says they would have contacted me with updates from R&D, 2022-11-09
Follow-up on the vulnerability, 2023-01-25
RIGOL says they would reply in 2-3 days, 2023-01-28
Full disclosure, 2023-02-08
The style the author chose to list the timeline is IMHO the most faithful, honest, and polite way of communicating it without adding wrong or legally problematic reasoning to the situation, from their perspective.
On my Siglent scope (an SDS2104X plus) you can easily hack it to enable telnet access. This requires physical access to the device to add a USB stick with a file on it to achieve this, but it's then very open (described here https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus...)
It was actually one of the things that attracted me to this scope, that it was to some extent hackable. Compared to other scopes like the old Tektronix ones running VxWorks it's nice to have something familiar behind the scenes.
Think of all the awesome things I could do!
This security vulnerability does not make me worried, it makes me happy. Rigols have always been somewhat hackable, this is an even easier way to do it.
Security vulns happen, but come on, this is the basics.
Unlike the games industry there isn’t nearly as many people drawn to writing the shitware on a consumer router or cut rate oscilloscope.
I'm not giving you a justification, I'm telling you how it is.
> Real engineers don't get away with fuckups with real consequences because of their salary.
I mean they absolutely do.
What is a "real" engineer anyway? I am a licensed engineer (electrical) because I used to work independently as an engineering firm. I understand the various definitions.
The overwhelming majority of those with a title of electrical or computer engineer do not have any kind of professional licensure or certification - at best they may have an accredited 4 year degree.
None of these people are going to be personally liable for fuckups of any kind in their careers.
Just last year I casually inspected and found an RCE in a decade old consumer product just sitting there in plain sight:
http://www.hydrogen18.com/blog/hacking-zyxel-ip-cameras-pt-1...
It’s much easier to create secure web apps using C#, compared to cgi-bin written in C for lighthttpd web server.
These equipments are simply assuming that anyone can access the interface is not hostile. This is a pretty good assumption in most lab settings that I know, unless the operator is so ignorant. This assumption certainly have made my life much easier in the lab, of course, where every LXI test equipments are connected to a isolated LAN. I would say a lot more f*k in the lab if I have to authenticate myself before sending a SCPI command. I'm happy that most test equipment makers do agree with me.
For example, modern Rohde&Schwartz gears running Windows or Linux (FSV, FSW, FSVA, FSUP, SMA, SMC, ZNL, etc.) have VNC or Windows RDP enabled by default, and have a weak default password shared among the series. Keysight ones too (E5071C, DSOX3000T, maybe not on by default but with a supported way). A hostile user can even screw up a LAN connected, damn simple VxWorks based multimeter like Agilent 34410A badly by sending the calibration commands at the wrong time or some backdoor commands (DIAG:xxxx, haven't tried but looks possible).
Slightly off topic, some Chinese test equipment makers are making hackability as a feature, look at Siglent or Rigol scopes. They can (and they are competent enough to) lock down the system with secure boot like some Tektronix ones. However they don't, so that people with less budget can buy a cheaper model and hack for the bandwidth.
I went through a similar argument with an intranet product that "didn't need to worry about SQL because it's on a trusted network" crashed when Bob O'Reilly tried to make an account.
Having a password implies that it provides some meaningful security. A bad lock is worse than no lock, because it will lead people to put the instrument in inappropriate places.
But a weak password maybe useful sometimes, to prevent your coworker accidentally connect to the wrong equipment and mess up one's experiment.
Here it's never meant to deter a hostile coworker, in that case one reports to one's superior rather than rely on the password which is always stickered to the scope itself (in my lab).
Never connect these things to the internet or any untrusted network. Last thing you need is a 10k instrument bricking itself.
I'm mostly disappointment that the author didn't do any research. While I get the cool-factor of trying to hack the firmware from scratch, a simple search would have found the author the EEVblog [0] for starters. But i admit, it is 104 pages atm. And the biggest dissapointment, an obviously shameless plug, is that this 'reversing' of the firmware, was done more then 5 years ago [1] where I wrote scripts to extract the whole firmware automatically.
There's even rumor that the entire source code has leaked onto the internet already.
I would expect some research would have made this 'discovery' less of an 'omg there's an RCE!'
[0]: https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso... [1]: https://gitlab.com/riglol/rigolee/firmware/
After finding the vuln, I checked online if someone else had already found the vuln, and I admit I have come across the EEVblog, but I didn't find the exact vuln I found (I also must admit I didn't read all the posts there).
I am sorry if I have in some way disrespected your work, but it wasn't my intention at all!