Unfortunately, RTX did not respond to our vulnerability report. The account was disabled.
Some sort of acknowledgement of the report certainly would have been good here, but at least they did disable the account. I presume the reported vulnerability no longer exists.
Not worked in aerospace only enterprise but sometimes I worry I'm too cynical and then I remember the things I've seen and think I'm not cynical enough.
That said nothing I work on is aerospace level critical, could cost a lot of money if it's out but no one would ever have died.
They're not in the US. I'm not familiar with German law enforcement practices but I wouldn't be surprised if they had a process that was a little less door-kicky.
No door-kicking, just corrupt prosecutors, judges and police that do the regime's bidding without much spectacle.
State media goons with Nazi-tourette celebrating Kirk's murder and calling for murdering dissenters or arming the terrorist Lina Engel, no worries, the regime got them covered.
Call a minister of the regime a moron or quote them and you better have your bath robe ready when their henchmen break in the next morning.
Just google Norbert Bolz, Trusted Flaggers™, Mario Sixtus, Böhmermann, Schwachkopf Habeck and Hammerbande.
Looks like the PDF is just to show what the messaging interface looks like, and what they've found as a publicly available screenshot is from the crash report involving that plane.
If they logged in, took a screenshot, and published that (even if lots of things are blurred), there's probably more attack surface for some three-letter-agency to bust down their doors and disappear them...
Well, this is just standard Aerospace grade software. I would be surprised if you could find a single controller in an airplane without some trivial login credentials.
Exposing software like that to the internet is of course a completely insane step.
> Well, this is just standard Aerospace grade software
Can't be further from the truth. DOD software is given huge budgets where it's not surprising to see 3 separate teams performing QA for one software milestone. It's one of the few sectors that still plan software upfront waterfall style and implement strict procedures for traceability, change management, etc. Who else is using formal methods or safety critical stacks like ADA/Spark?
> Who else is using formal methods or safety critical stacks like ADA/Spark?
This is not actually as common as many people seem to believe. The mandate died almost two decades ago. DOD aircraft fly on Fortran, JOVIAL, C, and C++ more than Ada. And DOD IT systems are a clusterfuck.
> It's one of the few sectors that still plan software upfront waterfall style
That's not the good thing you seem to think it is.
Also, why do you call it ADA? It's not an acronym. Amusingly, SPARK is, or was, and you write it as "Spark". It originally stood for "SPADE Ada Kernel" and the language continues to be stylized as SPARK.
Pedantics aside, not much reasoning against quality. Perhaps I've lucked out, but I've worked in many sectors and do not at all agree with sentiment here about DOD software quality. There is significant formal investment/research in DOD to improve operations, including taking the best of practices in commercial. In my experience, the worst of software is written by teams with little experience improvising under Agile and taking on tech debt with no time/resources to get things done the right way.
Can you point to a successful Waterfall project? A multi-million or billion dollar, 3+ year software development effort where a team figured out all the requirements correctly before writing a single line of code. Where they wrote every line of code correctly before testing it. And where testing was so spectacularly successful that they didn't have to go back and renegotiate the project requirements or dates to get extensions or reduced project scope.
If you can do this, then I might believe you about Waterfall being the best approach out there.
Right now your counter example is "teams with little experience" which is not much of an argument. Teams with little experience fail all the time, because they are inexperienced. Give them a $100 million Waterfall project to plan and execute over 3+ years and their failure would be even more spectacular.
You have to be kidding! Have you worked on any of these projects?
I wrote DO-178 Software, literally every single project I ever worked on has trivial login credentials.
>DOD software is given huge budgets where it's not surprising to see 3 separate teams performing QA for one software milestone. It's one of the few sectors that still plan software upfront waterfall style and implement strict procedures for traceability, change management, etc. Who else is using formal methods or safety critical stacks like ADA/Spark?
None of this matters or contradicts what I said. You will be able to get into it with user:root password:root or some variation. In all likelihood you will even find a requirement for this, which is of course verified.
If you apply the methodology practiced to a web application, the OP is exactly what you will get.
As someone who lives the DoD software delivery process on a day-to-day basis, it's too on the nose to not be satire. Everything is _exactly_ wrong, even the waterfall part (everything's "agile" now!).
Edit: Never mind! I just saw their other comment and it seems more like they are blissfully ignorant of the reality on the ground.
> Well, this is just standard Aerospace grade software.
This is a groundside problem, and perhaps it is insane to have it exposed to the open internet but it's not on the aircraft. It needs to be exposed to some network because the intent is that fleet controllers (airlines, or in this case Navy) use it to reach out to their aircraft wherever they may be.
That said, it absolutely fits the quality I've come to expect from IT systems developed by aerospace and defense companies.
No, this seems to be quite recent. At least the discovery, disclosure, and post are recent, as always, who knows how long the vulnerability has existed... I'll admit I was also confused because their "screenshots" is an old official document containing screenshots of the application in question, but it's just used to illustrate what the application is and does.
> RTX did not respond to our vulnerability report
I guess they mean you should sell the vulnerability to highest bidder instead of reporting? Weird choice.
Unfortunately, RTX did not respond to our vulnerability report. The account was disabled.
Some sort of acknowledgement of the report certainly would have been good here, but at least they did disable the account. I presume the reported vulnerability no longer exists.
> but at least they did disable the account.
Probably added test2:test2.
Not worked in aerospace only enterprise but sometimes I worry I'm too cynical and then I remember the things I've seen and think I'm not cynical enough.
That said nothing I work on is aerospace level critical, could cost a lot of money if it's out but no one would ever have died.
They will respond after a year or two with a lawsuit and SWAT busting doors.
They're not in the US. I'm not familiar with German law enforcement practices but I wouldn't be surprised if they had a process that was a little less door-kicky.
In germany linux dev get swated while live streaming.
https://news.ycombinator.com/item?id=41532098
Cybercrime is pretty door-kicky in germany and they usually keep all your gear for two years even if you are found not guilty...
According to my German friends, it's worse over there.
No door-kicking, just corrupt prosecutors, judges and police that do the regime's bidding without much spectacle.
State media goons with Nazi-tourette celebrating Kirk's murder and calling for murdering dissenters or arming the terrorist Lina Engel, no worries, the regime got them covered.
Call a minister of the regime a moron or quote them and you better have your bath robe ready when their henchmen break in the next morning.
Just google Norbert Bolz, Trusted Flaggers™, Mario Sixtus, Böhmermann, Schwachkopf Habeck and Hammerbande.
Collins Aerospace, the same company responsible days of outages at airport check-in kiosks https://www.bbc.co.uk/news/articles/c3drpgv33pxo
Interesting choice of tail number and date... https://www.faa.gov/lessons_learned/transport_airplane/accid...
Looks like the PDF is just to show what the messaging interface looks like, and what they've found as a publicly available screenshot is from the crash report involving that plane.
If they logged in, took a screenshot, and published that (even if lots of things are blurred), there's probably more attack surface for some three-letter-agency to bust down their doors and disappear them...
I'll take "things that happen in movies a lot more than in real life" for $600 please.
I would guess it limits their ability to be accused of anythign to pick a plane, flight, and time that meets at least three criteria:
1) no passengers on board - you can't be accussed of endangering passengers
2) long past - you can't be accused of anything that happened recently
3) the plan literally no longer exists - you can't be accussed of damaging a plane
Well, this is just standard Aerospace grade software. I would be surprised if you could find a single controller in an airplane without some trivial login credentials.
Exposing software like that to the internet is of course a completely insane step.
> Well, this is just standard Aerospace grade software
Can't be further from the truth. DOD software is given huge budgets where it's not surprising to see 3 separate teams performing QA for one software milestone. It's one of the few sectors that still plan software upfront waterfall style and implement strict procedures for traceability, change management, etc. Who else is using formal methods or safety critical stacks like ADA/Spark?
> Who else is using formal methods or safety critical stacks like ADA/Spark?
This is not actually as common as many people seem to believe. The mandate died almost two decades ago. DOD aircraft fly on Fortran, JOVIAL, C, and C++ more than Ada. And DOD IT systems are a clusterfuck.
> It's one of the few sectors that still plan software upfront waterfall style
That's not the good thing you seem to think it is.
Also, why do you call it ADA? It's not an acronym. Amusingly, SPARK is, or was, and you write it as "Spark". It originally stood for "SPADE Ada Kernel" and the language continues to be stylized as SPARK.
Pedantics aside, not much reasoning against quality. Perhaps I've lucked out, but I've worked in many sectors and do not at all agree with sentiment here about DOD software quality. There is significant formal investment/research in DOD to improve operations, including taking the best of practices in commercial. In my experience, the worst of software is written by teams with little experience improvising under Agile and taking on tech debt with no time/resources to get things done the right way.
Can you point to a successful Waterfall project? A multi-million or billion dollar, 3+ year software development effort where a team figured out all the requirements correctly before writing a single line of code. Where they wrote every line of code correctly before testing it. And where testing was so spectacularly successful that they didn't have to go back and renegotiate the project requirements or dates to get extensions or reduced project scope.
If you can do this, then I might believe you about Waterfall being the best approach out there.
Right now your counter example is "teams with little experience" which is not much of an argument. Teams with little experience fail all the time, because they are inexperienced. Give them a $100 million Waterfall project to plan and execute over 3+ years and their failure would be even more spectacular.
You have to be kidding! Have you worked on any of these projects?
I wrote DO-178 Software, literally every single project I ever worked on has trivial login credentials.
>DOD software is given huge budgets where it's not surprising to see 3 separate teams performing QA for one software milestone. It's one of the few sectors that still plan software upfront waterfall style and implement strict procedures for traceability, change management, etc. Who else is using formal methods or safety critical stacks like ADA/Spark?
None of this matters or contradicts what I said. You will be able to get into it with user:root password:root or some variation. In all likelihood you will even find a requirement for this, which is of course verified.
If you apply the methodology practiced to a web application, the OP is exactly what you will get.
LOL
You know, maybe you're right. It's possible that entire comment was meant as a joke. Poe's Law strikes again?
As someone who lives the DoD software delivery process on a day-to-day basis, it's too on the nose to not be satire. Everything is _exactly_ wrong, even the waterfall part (everything's "agile" now!).
Edit: Never mind! I just saw their other comment and it seems more like they are blissfully ignorant of the reality on the ground.
> Well, this is just standard Aerospace grade software.
This is a groundside problem, and perhaps it is insane to have it exposed to the open internet but it's not on the aircraft. It needs to be exposed to some network because the intent is that fleet controllers (airlines, or in this case Navy) use it to reach out to their aircraft wherever they may be.
That said, it absolutely fits the quality I've come to expect from IT systems developed by aerospace and defense companies.
It meets all requirements! /s
Aerospace have been dealing with /safety/ for a long time, /security/ is another matter...
Nowadays it's actually hard to not connect anything to internet. Better (and easier) to assume it's connected.
root:root
(2009)
No, this seems to be quite recent. At least the discovery, disclosure, and post are recent, as always, who knows how long the vulnerability has existed... I'll admit I was also confused because their "screenshots" is an old official document containing screenshots of the application in question, but it's just used to illustrate what the application is and does.