SandyO art

SandyO

webview

Grow your business with new technology. Sandy, order today and we'll ship it for free.

HP PCs, printers and more

Chat with, email, or call the U.S. store for
assistance at 1-866-288-7519.

Need help? Contact us now 1-866-288-7519

Volume
discounts

Financing
options

Complete
customization

Support &
drivers

Log into your account | Unsubscribe | Privacy Statement

Offer valid while supplies last and is subject to change or cancellation at any time. See product page for details. Prices shown may include applicable instant savings. Contract and volume customers not eligible. Not valid with any other promotions and valid in U.S. only.

The content of this email is intended only for U.S. residents.

Please add 'HP@us.mail.hp.com' to your address book.

This mailing was sent to 'sandyohlson.larryo@blogger.com' because you signed up to receive email from 'HP.com.'

If you no longer want to receive this newsletter, please 'unsubscribe'. To unsubscribe from all HP marketing emails, please reply with "UNSUBSCRIBE" as the subject line.

HP shall not be liable for technical or editorial errors or omissions contained herein.

HP, 1501 Page Mill Road, Bldg. 6, Palo Alto, CA 94304

© Copyright 2020 HP Development Company, L.P. The information contained herein is subject to change without notice.

EmID:80473, Cn:Remarketing, Em:CBDB_Section_2_Comm, Dv:ISAC, St:GS, Sk:69ABF10B3C7F3A0C06FC515C3B582381, Rfc:0, audienceDE:All Subscribers, AOID:226317840, emVer:

SandyO

When we published our research on network printer security at the beginning of the year, one major point of criticism was that the tested printers models had been quite old. This is a legitimate argument. Most of the evaluated devices had been in use at our university for years and one may raise the question if new printers share the same weaknesses.

35 year old bugs features

The key point here is that we exploited PostScript and PJL interpreters. Both printer languages are ancient, de-facto standards and still supported by almost any laser printer out there. And as it seems, they are not going to disappear anytime soon. Recently, we got the chance to test a $2,799 HP PageWide Color Flow MFP 586 brand-new high-end printer. Like its various predecessors, the device was vulnerable to the following attacks:

Capture print jobs of other users if they used PostScript as a printer driver; This is done by first infecting the device with PostScript code
Manipulate printouts of other users (overlay graphics, introduce misspellings, etc.) by infecting the device with PostScript malware
List, read from and write to files on the printers file system with PostScript as well as PJL functions; limited to certain directories
Recover passwords for PostScript and PJL credentials; This is not an attack per se but the implementation makes brute-force rather easy
Launch denial of Service attacks of various kinds:
- PostScript based infinite loops
- PostScript showpage redefinition
- Disable jobmedia with proprietary PJL
- Set the device to offline mode with PJL

Now exploitable from the web

All attacks can be carried out by anyone who can print, which includes:

Web attacker:
- A malicious website that uses XSP
Network access:
- Via Jetdirect (port 9100/tcp)
- Via LPD (port 515/tcp)
- Via IPP (port 631/tcp)
Wireless access:
- Apple Air Print (enabled by default)
Cloud access:
- Google Cloud Print (disabled by default)
Physical access:
- Printing via USB cable or USB drive
- Potentially NFC printing (haven't tested)

Note that the product was tested in the default configuration. To be fair, one has to say that the HP PageWide Color Flow MFP 586 allows strong, Kerberos based user authentication. The permission to print, and therefore to attack the device, can be be limited to certain employees, if configured correctly. The attacks can be easily reproduced using our PRET software. We informed HP's Software Security Response Team (SSRT) in February.

Conclusion: Christian Slater is right

PostScript and PJL based security weaknesses have been present in laser printers for decades. Both languages make no clear distinction between page description and printer control functionality. Using the very same channel for data (to be printed) and code (to control the device) makes printers insecure by design. Manufacturers however are hard to blame. When the languages were invented, printers used to be connected to a computer's parallel or serial port. No one probably thought about taking over a printer from the web (actually the WWW did not even exist, when PostScript was invented back in 1982). So, what to do? Cutting support for established and reliable languages like PostScript from one day to the next would break compatibility with existing printer drivers. As long as we have legacy languages, we need workarounds to mitigate the risks. Otherwise, "The Wolf" like scenarios can get very real in your office…

More info

SandyO

1. Overview

Is an elf32 static and stripped binary, but the good news is that it was compiled with gcc and it will not have shitty runtimes and libs to fingerprint, just the libc ... and libprhrhead
This binary is writed by Ricardo J Rodrigez

When it's executed, it seems that is computing the flag:

But this process never ends .... let's see what strace say:

There is a thread deadlock, maybe the start point can be looking in IDA the xrefs of 0x403a85
Maybe we can think about an encrypted flag that is not decrypting because of the lock.

This can be solved in two ways:

static: understanding the cryptosystem and programming our own decryptor
dynamic: fixing the the binary and running it (hard: antidebug, futex, rands ...)

At first sight I thought that dynamic approach were quicker, but it turned more complex than the static approach.

2. Static approach

Crawling the xrefs to the futex, it is possible to locate the main:

With libc/libpthread function fingerprinting or a bit of manual work, we have the symbols, here is the main, where 255 threads are created and joined, when the threads end, the xor key is calculated and it calls the print_flag:

The code of the thread is passed to the libc_pthread_create, IDA recognize this area as data but can be selected as code and function.

This is the thread code decompiled, where we can observe two infinite loops for ptrace detection and preload (although is static) this antidebug/antihook are easy to detect at this point.

we have to observe the important thing, is the key random?? well, with the same seed the random sequence will be the same, then the key is "hidden" in the predictability of the random.

If the threads are not executed on the creation order, the key will be wrong because is xored with the th_id which is the identify of current thread.

The print_key function, do the xor between the key and the flag_cyphertext byte by byte.

And here we have the seed and the first bytes of the cypher-text:

With radare we can convert this to a c variable quickly:

And here is the flag cyphertext:

And with some radare magics, we have the c initialized array:

radare, is full featured :)

With a bit of rand() calibration here is the solution ...

The code:
https://github.com/NocONName/CTF_NcN2k15/blob/master/theAnswer/solution.c

3. The Dynamic Approach

First we have to patch the anti-debugs, on beginning of the thread there is two evident anti-debugs (well anti preload hook and anti ptrace debugging) the infinite loop also makes the anti-debug more evident:

There are also a third anti-debug, a bit more silent, if detects a debugger trough the first available descriptor, and here comes the fucking part, don't crash the execution, the execution continues but the seed is modified a bit, then the decryption key will not be ok.

Ok, the seed is incremented by one, this could be a normal program feature, but this is only triggered if the fileno(open("/","r")) > 3 this is a well known anti-debug, that also can be seen from a traced execution.

Ok, just one byte patch, seed+=1 to seed+=0, (add eax, 1 to add eax, 0)

before:

after:

To patch the two infinite loops, just nop the two bytes of each jmp $-0

Ok, but repairing this binary is harder than building a decryptor, we need to fix more things:

The sleep(randInt(1,3)) of the beginning of the thread to execute the threads in the correct order
Modify the pthread_cond_wait to avoid the futex()
We also need to calibrate de rand() to get the key (just patch the sleep and add other rand() before the pthread_create loop

Adding the extra rand() can be done with a patch because from gdb is not possible to make a call rand() in this binary.

With this modifications, the binary will print the key by itself.

Related posts

SandyO art

Monday, August 31, 2020

That tech has your name on it

Sunday, August 30, 2020

New Printers Vulnerable To Old Languages

35 year old bugs features

Now exploitable from the web

Conclusion: Christian Slater is right

More info

NcN 2015 CTF - theAnswer Writeup

Followers