Using Your Photocopier to Share Data…

Via Charles Arthur’s Overspill, an interesting story about Digital Photocopiers Loaded With Secrets, telling a tale of how you can buy scrapped photocopiers for their hard drives and then trawl them for data, as you might do with old office computers, or phones…

A quick skim of the Xerox website turns up a photocopier product line listing that includes details of whether a photocopier includes a hard drive, along with some general guidance information:

Security Features

Jobs may be written to nonvolatile memory (e.g. to a hard drive) during processing. Generally, when a job finishes, this data is deleted, but may still be recoverable using forensic tools. Image overwrite is effective at eliminating this job data from the hard drive once the data is no longer needed. Xerox also scrambles the data with the user data encryption feature.

This further protects data at rest from unauthorized access. Xerox recommends that the following features be enabled.

Fortunately, countermeasures are built into products to reduce this risk.

• Immediate Job Overwrite or Immediate Image Overwrite is a feature that deletes and overwrites (with a specific data pattern) disk sectors that temporarily contained electronic image data. Products that use hard disk drives to store job data initiate this process at the completion of each job. … This should be enabled (and is by default on many products).
• On Demand Image Overwrite is a manually initiated (can also be scheduled) feature that deletes and overwrites (with a specific data pattern) every sector of any partitions of the hard drive that may contain customer job data. The device will be offline for a period of 20 minutes to one hour while this completes. [Makes me think of coffee machine self-clean cycles, –Ed.]
• Disk or User Data Encryption is a feature which encrypts all partitions of the hard drive that may contain customer job data with AES encryption. This should be enabled (and is by default on many products). Encryption can be used in combination with either overwrite feature.

Hard Disk Drive Retention Offering

If the security features built into Xerox products do not meet your security requirements, Xerox offers another alternative.
Hard Drive Retention Offering is a service that can be requested by a customer who wants to retain a hard drive for security reasons. A Xerox technician will remove the hard drive and leave it with the customer.

Things to Remember
• Not all products have hard disk drives.
• Some products have hard disk drives, but do not use the hard disk drive to save document images.
• If a Xerox product is powered off before an Overwrite operation completes, there may be remnants of data left on the drive. A persistent message will appear on the device indicating the incomplete overwrite operation. In this event, it is recommended that an On Demand Image Overwrite be performed.
• Image overwrite features are available for hard drive equipped devices only. Currently it is not possible to overwrite images on solid-state nonvolatile memory.

• NOTE: Xerox strongly recommends the default Administrator password be changed on all devices to prevent unauthorized access to configuration settings.

Xerox does not offer sanitization or cleansing services for returned disk drives.

Many photocopiers nowadays are intended to be accessed over a network (they double up as network printers), and may incorporate a webserver to facilitate that. Which means they may also be a network security hazard. Which is why photocopiers should be regarded as part of the IT estate so that IT can be responsible for regularly checking a vendor’s photocopier security bulletin. (As computers, photocopiers are also susceptible to hardware/processor vulnerabilities.)

PS think also connected vending machines ?!

Does Transfer Learning with Pretrained Models Lead to a Transferable Attack?

Reading a post just now on Logo detection using Apache MXNet, a handy tutorial on how to train an image classifier to detect brand logos using Apache MXNet, a deeplearning package for Python, I noted a reference to the MXNet Model Zoo.

The Model Zoo is an ongoing project to collect complete models [from the literature], with python scripts, pre-trained weights as well as instructions on how to build and fine tune these models. The logo detection tutorial shows how training your own network with a small number of training images is a bit rubbish, but you can make the most of transfer learning to take a prebuilt model that has been well trained and “top it up” with your own training samples. The guess the main idea is: the lower layers of the original model will be well trained to recognise primitive image features, and can be reused, and the final model tweaked to reweight these lower level features in the upper layers so the overall model works with your particular dataset.

So given the ability to generate adversarial examples that trick a model into seeing something that’s not there,  how susceptible will models built using transfer learning on top of pretrained models be to well honed attacks developed on that pretrained model? To what extent will the attacks work out of the can (and/or to what extent) or how easily will they be transferred?

To read:


Simple Authenticated Access to VM Services Using NGINX and Vagrant Port Forwarding

Tinkering with the OU TM351 VM, looking at putting together an Amazon AWS AMI version, I started to wonder about how I could add a simple authentication layer to mediate public web access so students don’t fire up an image on their dollar and then find other folk using it.

So… h/t to Adam McGreggor for pointing me to nginx. Using this and a smattering of other cribs, I soon got to this (

#!/usr/bin/env bash

#Install nginx
#apache2-utils contains htpassword command to configure password used to restrict access to target ports
sudo apt-get update && sudo apt-get install -y nginx apache2-utils

#Create a password (test) for user tm351
#Optionally set password via environment variable - TMP_PASS - from Vagrantfile
#If TMP_PASS not set, use default password: test
sudo htpasswd -b -c /etc/nginx/.htpasswd tm351 "${TMP_PASS-test}"

Now we need to create a config file for nginx. Define each service separately, on the top level path (/) for each service (which is referenced relative to its own port).

#Jupyter notebook running on port 8888 inside the VM
upstream notebooks {

#OpenRefine running on port 3333 inside the VM
upstream refine {

#Create a simple (unauthenticated) server on port 80
#The served files should be placed in /var/www/html/*
server {
  listen 80;
  location / {
    root /var/www/html ;
    index index.html;

server {
  #Configure the server to listen on internal port 35180 as an authenticated proxy for internal 8888
  listen 35180;

  auth_basic "Protected...";
  auth_basic_user_file /etc/nginx/.htpasswd;

  location / {
    proxy_pass http://notebooks;
    proxy_redirect off;

server {
  #Configure the server to listen on internal port 35181 as an authenticated proxy for internal 8888
  listen 35181;
  auth_basic "Protected...";
  auth_basic_user_file /etc/nginx/.htpasswd;
  location / {
    proxy_pass http://refine;
    proxy_redirect off;
sudo echo "$config" > /etc/nginx/sites-available/default

#if that doesn't work, eg wrt permissions, try a workaround:
#sudo echo "$config" > default
#sudo mv default /etc/nginx/sites-available/default
#sudo chmod 0644 /etc/nginx/sites-available/default
#sudo chown root /etc/nginx/sites-available/default
#sudo chown :root /etc/nginx/sites-available/default

#Restart nginx with the new configuration
sudo service nginx reload

The password (set on the command line vagrant is called from using export TMP_PASS="NEW PASSWORD") can be passed in from the Vagrantfile for use by as follows:

config.vm.provision :shell, :env => {"TMP_PASS" => ENV["TMP_PASS"]}, :inline => <<-SH
  	source /vagrant/build/

Setting up port forwarding in my Vagrantfile then looks like this:

config.vm.provider :virtualbox do |virtualbox|

	#jupyter authenticated - expose internal port 35180 on localhost:35180 :forwarded_port, guest: 35180, host: 35180, auto_correct: true

	#refine authenticated - expose internal port 35181 on localhost:35181 :forwarded_port, guest: 35181, host: 35181, auto_correct: true


Running the vagrant provisioner, I now have simple authenticated access to the notebook and OpenRefine servers:

Could be a handy quick recipe, that…

See also: Course Apps in the the Cloud – Experimenting With Open Refine on Digital Ocean, Linode and AWS / Amazon EC2 Web Services

PS Only of course it doesn’t quite work like that – because the I’d originally defined the services to be listening over all network ranges on… instead they need to listen on…