Re: [FD] Authentication Bypass in Xerox Printers – It is not a bug! It is a legacy feature ;-)
I can't provide an authoritative list of similarly affected printers, but I
can confirm that every printer firmware image I've actually bothered to
inspect (BROTHER, for example) is simply a PS document. (Or, in their case,
"BR-Script3", if there's really a difference...)
I've used the "print to upgrade" trick as far back as the HP LaserJet V, if
memory serves. I recall doing it on other Xerox printers in 2009, Samsung
("Dell") printers around 2010, on through my personal Brother laser (produced
ca. 2010, I think).
It's frequently available, if un-advertised, through any port that's valid to
print to, whether that's lpr, ftp, raw / JetDirect, or whatever. Best results
with raw / JD on 9100/tcp.
I mention this because I don't personally have a large stable of printers to
test and report on. However, my results over most of the past two decades
indicate that most print engines across the industry will accept firmware via
PS, PCL, or similar unless measures are taken at the management level to
prevent firmware images reaching the print engine--this is frequently
impossible, since virtually no production printers up through major workgroup
units have a concept of a "hostile" print job or "hostile content", and the
vast majority of office printers have no authentication required to submit
print jobs implemented unless someone has taken considerable pains to ensure
the only route to the printer is via a Windows print share or similar.
Anyone with wider access to printers can probably have a field day with this
problem.
My personal EPSON unit uses their own proprietary language ( https://
en.wikipedia.org/wiki/ESC/P ), which I believe is referenced in the Linux
drivers as the ESC/P2 variant, and is *technically* not vulnerable to this
problem, insofar as the attack might need to be adapted slightly to avoid the
more common PS/PCL and/or PJL vectors. Despite having a very fast and capable
management module and print interface, the printer doesn't appear to
understand PostScript, PCL, or even PJL. I haven't inspected their firmware
images to see if they're simply ESC/P2 command lists and a binary blob--but I
would assume so.
BROTHER printers in particular--or at least the ones I took the time to
examine--include a hardcoded, non-varying "admin" password embedded at the
beginning of the document (that is, firmware "image") that is required to
switch the printer from general jobs acceptance to "firmware download mode".
It must be included with all firmware images to succeed in upgrading, so of
course Brother include it with every official firmware image.
The embedded admin password cannot be removed or disabled short of rewriting
firmware, and presumably it can be accessed via any valid-appearing print job
with any type of content unless pains are taken to install some form of
specialized "PostScript firewall" (also PCL firewall, possibly XPS firewall,
etc.) in between all the enabled I/O interfaces and the rest of the world.
I reported all this to BROTHER years ago, persisted long enough to finally
talk to someone on their development team, and I was told, essentially, that
they would "look into" this. I didn't expect any further response at that
point, and I did not get one.
My point is that this specific vulnerability (possibly including hardcoded
backdoor credentials) probably applies to tens of thousands of models--or
more--across most or all of the printing industry. It's just a matter of
getting access to the printers to prove it.
I encourage more researchers to engage in finding and exposing these flaws and
shaming the industry into starting to fix the total-trust, zero-security model
they've used for management and print interfaces for decades.
On Friday, September 1, 2017 10:07:26 AM EDT Peter Weidenbach wrote:
> Document Title:
> ===
> Authentication Bypass in Xerox Printers – It is not a bug! It is a
> legacy feature ;-)
>
> Description:
>
> Xerox enforces authentication before updating a firmware or install a
> configuration file (clone file) in recent firmware versions. That seems
> quite reasonable. Nevertheless you can still simply “print” them via
> port 631 without authentication.
>
> Xerox says: “The issue that you discovered is a legacy feature intended
> for the convenience of our customers. […] Xerox has begun adding a
> separate disable for the specific issue you discovered to our most
> recent products.”
>
> However, what could possibly go wrong?
> Even if it is not possible to execute arbitrary code in clone files
> [1,2,3] any more, clone files include an iptables configuration file.
> Possible threats are:
> - Denial of Service: Close all network ports
> - Steal Information: Forward all Print jobs to somewhere else
>
> Affected Product(s):
>
> Confirmed:
> Xerox Phaser 6700:
> - 081.140.107.11800
> - 081.140.106.21800
>
> Not confirmed:
> (They share the same DLM clone/update technique)
Re: [FD] Critical Vulnerability in Ubiquiti UniFi
Tim conflates two products in his original report: Product: UniFi AP AC Lite Vendor: Ubiquiti Networks Inc. Internal reference: ? (Bug ID) Vulnerability type: Incorrect access control Vulnerable version: Unify 5.2.7 and possible other versions affected (not tested) [...] Both the UniFi appliance line and the AP management software are properly spelled 'UniFi'. https://www.ubnt.com/unifi/unifi-ap-ac-lite/ https://www.ubnt.com/download/unifi/ UniFi - the AP controller software - does not run on the UniFi AP AC Lite. It's intended as a low-cost replacement for a dedicated AP controller appliance, and it manages - does not run on - Ubiquiti's current AP product line. The current full release version of the UniFi AP controller is 5.2.9. It has a dedicated appliance in the form of the "Cloud Key" - https://www.ubnt.com/ unifi/unifi-cloud-key/ The Cloud Key is a cute little package with some integral flash, a micro SD slot, PoE or USB power, and a MediaTek MT7623 SoC - if the picture is accurate. Its sole purpose in life appears to be running the UniFi controller software. I don't have one to test; the Cloud Key may well configure MongoDB insecurely. I have access to a few other UniFi products, so I looked them over. The self- hosted UniFi controller appears to call MongoDB correctly, at least as of 5.2.9: john@malkovich ~ [0]# pgrep -a mongo 2850 bin/mongod --dbpath /usr/lib/unifi/data/db --port 27117 --logappend -- logpath logs/mongod.log --nohttpinterface --bind_ip 127.0.0.1 I also confirmed that this is the only port bound. However, installing the Debian package 'unifi' pulls in the default Debian MongoDB package, 'mongodb- server' john@malkovich ~ [0]# apt-cache depends unifi | grep mongo |Depends: mongodb-server |Depends: Depends: Unless it's disabled or configured, the mongodb-server package starts an insecure instance that binds the wildcard interface. UniFi doesn't communicate with this MongoDB instance. It may be that this packaging choice should be taken up with the distro maintainers... I don't have a UniFi AP AC Lite (UAP-AC-LITE) to test against. I was able to test UAP-AC-PROs. I can confirm that these do NOT expose MongoDB on the port number given, which is also the default MongoDB port. At time of writing, the latest firmware version is 3.7.17 - this is what the UAP-AC-PROs were running at time of testing. The UniFi-series APs do run sshd on 22/tcp, which is apparently the management interface used by the UniFi controller. It's possible for users with management credentials to get a remote shell here. john@malkovich ~ [0]$ ssh bruce@willis bruce@willis's password: BusyBox v1.11.2 (2016-07-15 14:51:44 PDT) built-in shell (ash) Enter 'help' for a list of built-in commands. BZ.v3.7.8# Port-scanning a UAP-AC-PRO takes a tediously long time, so I merely ran nmap against default TCP ports, plus 27117 and 1-1024. The only response was on 22/ tcp. I also didn't feel like expending the effort to downgrade the UAP-AC-PROs to a selection of earlier firmware releases to test whether they may have been vulnerable before Tim's report to Ubiquiti. I found no evidence that the UAP-AC-PRO runs or ever has run MongoDB. As a device with only 128MB RAM, I don't think that it was intended to. Tim's UAP model is older and was intended to be cheaper. It may well have even less RAM than the UAP-AC-PRO. The datasheet doesn't mention hardware except for radio types, Ethernet ports, power consumption etc. I hope this clears up the nature of the products being discussed, as well as the current state of some of Ubiquiti's AP products. Once again, I do not have access to the UAP-AC-LITE that Tim referred to originally, so I can only state that it's very unlikely that the AP itself was or ever has offered access to unauthenticated MongoDB sessions. It also seems possible that Tim mistook a default - OS - MongoDB instance running on a commodity server for the one started and used by the self-hosted UniFi controller app. Personally, I haven't been impressed with Ubiquiti support's response to security or other issues that I've raised via normal support channels. They do have a bug bounty program, although the amounts they offer seem to be very much on the low end of the range they quote. Still, you may get a faster, better response using that channel - https:// www.ubnt.com/support/security-rewards/about/ On Tuesday, October 4, 2016 10:10:02 PM EDT Rob Thomas wrote: > The impression I get from Tim Pham's emails is that the 'Unify Manager' is > doing some behind-the-scenes tunnelling, and bringing the Mongo interface > from the server to the client (Eg, Mac or Windows device) and you are then > able to connect to localhost (on the client) which tunnels through to the > server. > > However, after much searching, I am unable to locate this application. > Googling insinuates that it is this (unreleased) software - > https://www.ubnt.com/enterprise/software/
