forked from tlsnotary/pagesigner-oracles
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathINSTALL.oracles
164 lines (136 loc) · 7.22 KB
/
INSTALL.oracles
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
-------------------------------------------------------------------------------
HOW TO CREATE A TLSNOTARY ORACLE EBS SNAPSHOT.
-------------------------------------------------------------------------------
In N.Virginia region create a volume from snap-f70deff0 (used by Ubuntu Server 14.04 LTS ami-fce3c696).
Attach the volume to any running instance as e.g. /dev/sdf.
From within the instance:
<bash>
sudo -s
apt-get -y install git
git clone https://github.com/tlsnotary/pagesigner-oracles
cd pagesigner-oracles
mkdir /mnt/disk
mount /dev/xvdf1 /mnt/disk
DISK=/mnt/disk
rm $DISK/etc/init.d/ssh
rm $DISK/usr/sbin/sshd
sed -i '122s/.*/linux \/boot\/vmlinuz-3.13.0-74-generic root=\/dev\/xvda1 ro console=tty1 console=ttyS0/' $DISK/boot/grub/grub.cfg sed -i 's/- bootcmd//' $DISK/etc/cloud/cloud.cfg
sed -i 's/- runcmd//' $DISK/etc/cloud/cloud.cfg
sed -i 's/- rightscale_userdata//' $DISK/etc/cloud/cloud.cfg
sed -i 's/- scripts-user//' $DISK/etc/cloud/cloud.cfg
cp -R notary $DISK/root
cp notary/rc.local $DISK/etc/rc.local
chmod 755 $DISK/etc/rc.local && chown root:root $DISK/etc/rc.local
cp -R signing_server $DISK/root
umount /dev/xvdf1
</bash>
In AWS console:
Detach the volume,
Create a public snapshot,
Create an Image from the snapshot, making sure that:
Virtualization type is Hardware-assisted virtualization
Root device name is /dev/xvda
Note the AMI ID and make the AMI public.
-------------------------------------------------------------------------------
HOW TO LAUNCH AN ORACLE INSTANCE FROM THE PUBLIC SNAPSHOT.
-------------------------------------------------------------------------------
Launch the AMI you created from AWS management console. Choose "Proceed without a key pair".
Make sure that:
Instance's "launchTime" and volume's "attachTime" happened on the same minute with no more than 3 seconds between the events.
Console Output (right-click an instance ->Instance Settings -> Get System Log) is available (after ~5 mins), since it was observed that sometimes an instance may not have any.
Internal use only:
in order to tranform the pubkey from Console Output into an array of numbers for PageSigner:
openssl rsa -pubin -inform PEM -text -noout < pubkey.pem
intstr = ''
for h in ''.join(raw.split()).split(':')[1:]:
intstr += str(int(h,16))+','
-------------------------------------------------------------------------------
HOW CAN YOU PROVE TO THE WORLD THAT A CERTAIN IP ADDRESS IS RUNNING THE ORACLE INSTANCE
-------------------------------------------------------------------------------
Use aws_query.py to create and publish URLs for requests
DescribeInstances
DescribeInstanceAttribute
DescribeVolumes
GetUser
GetConsoleOutput
-------------------------------------------------------------------------------
FOR VERIFIERS: HOW TO CHECK THAT THE SNAPSHOT CONTENTS WAS NOT MALICIOUSLY MODIFIED.
-------------------------------------------------------------------------------
Repeat all the steps described in "HOW TO CREATE AN ORACLE EBS SNAPSHOT" but don't create a public snapshot.
Attach the resulting volume (volX) to a running instance as /dev/sdg
Create a volume from the snapshot (volY) you are verifying and attach it to /dev/sdh
After that, run from within the instance
<bash>
sudo -s
fsck /dev/xvdg1
fsck /dev/xvdh1
#fsck must show that there were no errors
mkdir /mnt/disk1
mkdir /mnt/disk2
mount /dev/xvdg1 /mnt/disk1
mount /dev/xvdh1 /mnt/disk2
</bash>
Compare the hashes of volX and volY.
First hash file/directory/symlink paths, ownership, permissions, and symlink targets.
Then hash the contents of all regular files.
The outputs must match.
Also make sure that MBR and boot sector raw disk data match up to the point where filesystem starts.
Note: we do not check ext4 filesystem headers because they are not deterministic.
fdisk -l /dev/xvdg should show you that you only have 1 partition which starts at sector 16065
<bash>
cd /mnt/disk1
find . -printf '%h %f %U %G %m %l\n' | sort -t \n | sha256sum
find . -type f -print0 | sort -z | xargs -0 sha256sum | sha256sum
dd if=/dev/xvdg ibs=512 count=16066 | sha256sum
cd /mnt/disk2
find . -printf '%h %f %U %G %m %l\n' | sort -t \n | sha256sum
find . -type f -print0 | sort -z | xargs -0 sha256sum | sha256sum
dd if=/dev/xvdh ibs=512 count=16066 | sha256sum
</bash>
-------------------------------------------------------------------------------
FOR VERIFIERS: HOW TO DETERMINE THAT THE RUNNING ORACLE INSTANCE IS LEGIT
-------------------------------------------------------------------------------
The published URLs must conform to the checks performed in functions starting with check* in content/oracles.js.
-------------------------------------------------------------------------------
POSSIBLE ATTACKS AND HOW THEY WILL BE MITIGATED
-------------------------------------------------------------------------------
(or in other words, what prevents the AWS account owner from modifying the oracle instance code)
Attack1.
Launch the AMI with a rogue snapshot on /dev/xvda
Mitigation:
AWS doesn't allow replacing the snapshotID on the root device.
Testing:
ec2-run-instances -O id -W key ami-12345678 -b /dev/xvda=snap-12345678:::: -t t2.micro
Returns:
Client.InvalidBlockDeviceMapping: snapshotId cannot be modified on root device
Attack2.
Launch the AMI with a rogue snapshot on /dev/xvdb hoping that the AMI will boot it instead of /dev/xvda
Mitgation:
In grub.cfg we changed to root=/dev/xvda1.
Testing:
ec2-run-instances -O id -W key ami-12345678 -b /dev/xvdb=snap-12345678:::: -t t2.micro
After a few minuted check in the System Log that xvda volume was booted.
Attack3.
Launch the AMI with /dev/xvda=none and a rogue snapshot on /dev/xvdb. The AMI in absence of xvda will boot xvdb.
Attach the oracle snapshot as xvda and modify it. Then reboot and detach xvdb.
Upon reboot the modified xvda will be chosen by the kernel as the root device.
Mitigation:
AWS will not allow attaching a volume to /dev/xvda. Even if it did, the attachment time of xvda would differ from the time when AMI was launched.
Testing:
ec2-run-instances -O id -W key ami-12345678 -b /dev/xvda=none -b /dev/xvdb=snap-12345678:::: -t t2.micro
ec2-attach-volume -O id -W key vol-1234567 -i i-12345678 -d /dev/xvda
Returns:
Client.InvalidParameterValue: Invalid value '/dev/xvda' for unixDevice. Attachment point /dev/xvda is already in use
Attack4.
Launch AMI with user data passed in.
Mitigation:
AWS doesn't allow to modify user data while the instance is running, so DescribeInstanceAttribute userData API call will reveal that data was passed in at launch.
On top of that, we removed the bootcmd module from AMI's cloud-init. This module is responsible for handling the user Data.
Testing:
//FIXME --user-data doesnt work, instead use Management Console to launch the instance and pass user data
Run stock AMI with user data passed in
ec2-run-instances -O id -W key ami-fce3c696 -t t2.nano --user-data '!#/bin/bash echo "HELLO FROM USER DATA"'
Open Instance's System Log and ascertain that the string is visible.
Run oracle AMI with user data passed in
ec2-run-instances -O id -W key ami-15192302 -t t2.nano --user-data '!#/bin/bash echo "HELLO FROM USER DATA"'
The user data MUST NOT be visible in System Log.