Similar to infraxstructure: Mateusz Chrobok "Opowieść o ucieczce przed błędami typu 0day i wojną z błędnymi przeświadczeniami dotyczącymi chmur obliczeniowych."
Similar to infraxstructure: Mateusz Chrobok "Opowieść o ucieczce przed błędami typu 0day i wojną z błędnymi przeświadczeniami dotyczącymi chmur obliczeniowych." (20)
4. push SOS
Standardowe Odpowiedzi Słuchacza
#1
Było
10^n
razy
#2
Użyj
opcji
szukaj.
#3
Po
co
to
komu?
#4
A
kim
ty
w
ogóle
jesteś
by
się
wypowiadać?
#5
Najpierw
trzeba
je
zrozumieć
5. POP #5 Najpierw trzeba je
zrozumieć
@CloudExpo
Europe
2k13
Ian
Bird
(@CERN)
:
At
some
point
we
wanted
to
create
a
model
of
Internet.
We
never
ever
wasted
so
much
1me.*
*to
już
pare
lat
temu
stąd
nie
jest
to
dokładny
cytat.
6. POP #4 A kim ty w ogóle
jesteś by się wypowiadać?
• Ot
kolejny
geek,
nerd
śmieszek
• Chmury
to
zabawa
• Bezpieczeństwo
to
dla
mnie
hobb~^414141
...i
w
dodatku
płacą
mi
za
to^^
7. POP #3 Po co to komu?
-‐
dla
owocnej
dyskusji
-‐
zrozumienia,
-‐ rozszerzenia
horyzontów
-‐ przybicia
twarzodłoni,
-‐
zabawy.
9. Problem napotkanego wędrowca to:
• Wysoka
Δ-‐
różnorodność
obciążenia
• Można
przewidywać
skoki
zapotrzebowania
• Dane
nie
są
wrażliwe
(ha,
ha,
ha)
• Fizyczne
serwery
nie
dają
rady
• Inwestycja
w
adekwatny
h/w
nie
spina
się
biznesowo
11. I do Clouds as a Service...
or cloud services as a service
or support creation of cloud services as a
service
WHATEVER!
12.
13. Błędne przeświadczenia? Jak to...
• Przecież
wszyscy
to
robią!
(chmury)
• Będziemy
dynamicznie
kontrolować
OpEx
w
zależności
od
funkcji
celu
z
wagą
jakości.
• Zoptymalizujemy
CapEx
• Bo
ładnie
wygląda
w
CV
• Tato
ale
Gartner...
14.
15. Czy mgmt widzi/ wie jak działa IT?
source:
publiczny
raport
KPMG
–
pelne
zrodlo
na
koncu
prezentacji
17. Więcej utrudnień
• Marginesy
zysku
maleją
• Czas
na
dostarczenie
na
rynek
produktu
skraca
się
• Bycie
samotną
wyspą
to
powolna
śmierć
(jestem
zamknięty
bo
wiem
najlepiej)
vs
Open
Source
• Flexibility
to
za
duży
overhead
(systemy
zarządzające,
modele,
kontrolery
etc.
–
ja
chce
system
już!)
• Porównywanie
technologii
jest
trudne.
• Księgowi/Rada
nadzorcza
trzyma
mnie
za
[sS]*
18. Typowa komunikacja
międzygatunkowa w tematach
chmury
niedeterministyczne
zachowanie,
wirtualizacja,
OS,
hardware,
sieć,
bezpieczeństwo,
datacenter,
QoS,
whitebox.
Ten
śrubokręt
chce
mieć
śrubki
do
kręcenia.
TCO,
CAGR,
usługa/produkt,
raporty,
optymalizacja,
konsolidacja
Co?
Grrrrr......
19. Napotkane przeświadczenia
• Cloud
==
to
co
mamy
tylko
nie
u
nas
• Cloud
==
to
co
mamy
tylko
trzeba
komuś
zaufać
• Cloud
to
cel
markerngowy
–
logo
cloud
powered...
• Cloud
to
styl
życia
• Jak
chmury
to
tylko
publiczne.
Prywatne
nie
mają
sensu.
(lub
odwrotnie)
• „Nie
musisz
zmigrować
wszystkiego
ale
możesz”
(Miro
Burnejko
2k15
w
kontekście
przenosin
do
pub
clouda)
• Cloud
to
narzędzie
20. Dwie ścieżki oświecenia
Tańsza
Niebezpieczna
Szybka
Narażona
na
wpływ
czyjegoś
punktu
widzenia
Zaufanie
cudzemu
doświadczeniu.
21. Dwie ścieżki oświecenia
Droższa
pewniejsza
dłuższa
ograniczona
własną
percepcją
Własne
eksperymenty.
26. Jak poradzić sobie z szumem
by wybrać dobrą ścieżkę?
“Hiperkonwergentna
hybrydowa
chmura
z
homomorficznym
szyfrowaniem
kontrolera
SDN
dla
połączeń
z
obiektowym
SDS
spełniającym
FIPS
140
level
2
dla
interakcji
pomiędzy
VPC
a
VR
realizującymi
NFV.”
Bullshit
bingo!
27. Szum i filtrowanie
Czas
na
rozwój
(do
24h/dobę)
=
Σ
(Czas
na
odbiór(raporty/opinie),
czas
na
własne
badania,
czas
na
interakcje
z
innymi)
Każde
z
źródeł
posiada
swój
szum.
Czasem
celowy
i.e.
zysk
z
promocji.
Czasem
niezamierzomy
i.e.
ograniczenia
percepcji.
“Era
braku
informacji
minęła.
Teraz
trwa
era
wspomaganej
filtracji
informacji.”
/me
&&
pewnie
wielu
innych
Albo
je
odbieramy
co
wiąże
się
z
bańką
informacyjną
albo
je
wybieramy
co
wiąże
się
z
kosztem
28. Heuristics and Biases:
Framing
SLA
w
cloudzie
AWS
to
co
najmniej
99,95%
vs
Usługi
w
AWS
średnio
mogą
być
niedostępne
przez
4h
22m
w
roku.
-‐-‐-‐
h}ps://aws.amazon.com/ec2/sla/
h}ps://en.wikipedia.org/wiki/Framing_effect_(psychology)
29. Heuristics and Biases:
Framing (example details)
“Region
Unavailable”
and
“Region
Unavailability”
mean
that
more
than
one
Availability
Zone
in
which
you
are
running
an
instance,
within
the
same
Region,
is
“Unavailable”
to
you.
“Unavailable”
and
“Unavailability”
mean:
• For
Amazon
EC2,
when
all
of
your
running
instances
have
no
external
connecrvity.
• For
Amazon
EBS,
when
all
of
your
aNached
volumes
perform
zero
read
write
IO,
with
pending
IO
in
the
queue.
source
:
h}ps://aws.amazon.com/ec2/sla/
-‐-‐-‐-‐
A
gdy
już
się
przekroczy
SLA
no
to
cóż.
Dostaniesz
zniżkę/zwrot$
30. Heuristics and Biases: Sunk
Costs
“Tyle
już
zainwestowaliśmy
w
ten
samomonitorujący/
samonaprawiający
się
adaptacyjny
system
oparty
na
GCE.
Szkoda
przerywać
ten
eksperyment
i
zmarnować
pracę.”
vs
“Stworzenie
dedykowanego
dla
nas
PaaSu
pożera
za
dużo
zasobów.
Pora
zmienić
podejście/
technologię/
wymagania
(+fail
early
).”
h}ps://en.wikipedia.org/wiki/Escalaron_of_commitment
h}p://money.cnn.com/2015/03/18/technology/google-‐x-‐astro-‐teller-‐sxsw/
31. Heuristics and Biases:
Optimism and loss aversion
Wnioskujemy
na
podstawie
obecnie
działającego
in-‐house
klastra
CloudStackowego
z
Xenem
(bez
overbookingu),
iż
na
Azure
będziemy
potrzebować
12*A3
4*D4
i
2*D14.
Budżet,
migracja,
go
–
na
pewno
się
uda
i
będzie
tak
samo!
vs
Ciężko
określić
a
priori
wydajność
w
niedeterministycznym
środowisku
współdzielonym
jakim
jest
pub
cloud.
Jeżeli
jakość
musi
być
taka
sama
jak
w
środowisku
in-‐house
należy
wykonać
testy.
Mogą
istnieć
fenomeny,
których
nie
przewidzę
mając
doświadczenie
tylko
w
lokalnych
środowiskach
(+heterogeniczność).
32. Heuristics and Biases:
Availability
Dostępność
wniosków
wpływ
na
ocenę
prawdopodobieństwa
wystąpienia
zdarzenia.Przykład
z
perspektywy
hadoopowca:
“Gdy
name
node’y
nie
wytrzymują
i
czasem
nie
da
się
wylistować
plików
w
hdfs
–
spróbujmy
dorzucić
ramu.
To
zawsze
pomagało
w
lokalnym
środowisku
i
w
logach
było
mniej
faili.”
vs
“By
dobrze
zrozumieć
działanie
i
problemy
NN
w
cloudzie
należy
wykonać
analize
wydajności
IO/
RAM-‐u/CPU
w
kontekście
logów
i
stanu
środowiska.
Następnie
ocenić
wpływ
stanu
zaobserwowanego
na
decyzje
dotyczące
wielkości
maszyny
w
kontekście
oczekiwanej
wydajności.
Czy
ma
sens
zastosowanie
skalowania
wertykalnego?”
33. Proces poznawczy a kolory
skrzynek
Znamy
się
na
Analizujemy,
czytamy,
uczymy
się
zachowania.
Wprowadzamy
analogię
do
lub
poszukujemy
takiej
ponieważ
jest
to
wygodne
na
podstawie
części
informacji.
Na
obserwacji
zachowania
systemu
poszukujmy
analogii
do
znanych
technologii
w
przypadku
.
34. Jak to się ma do życia
codziennego?
AWS
korzysta
z
XEN-‐a
prawda?
Ciekawe
jak
daleko
są
od
#HEAD-‐a
obecnego
xen-‐a.
CVE
–
2016-‐3960
(Ling
Liu
and
Yihan
Lian)
aka
XSA-‐173
via
shadow
pagetables
HVM
-‐>host
crash.
PV
i.e.
while
migrated
(using
shadow
pagetables)
with
superpages
ON
can
crash
the
host
or
corrupt
hypervisor
memory.
small
element
–
control
hap
max
size
+/*
Max
physical
address
width
supported
within
HAP
guests
*/
+extern
unsigned
int
hap_paddr_bits;
sprawdzenia
flag
-‐
get_pte_flags(((1ull<<52)
-‐
1)
&
~((1ull<<paddr_bits)
-‐
1))
+
(_PAGE_INVALID_BIT
|
get_pte_flags(((1ull
<<
63)
-‐
1)
&
~(PAGE_SIZE
-‐
1)))
35. Sprawdzenie najwyższą formą
zaufania
• Czy
sprawdzisz
to
CVE
u
swojego
vendora?
• Sprawdzisz
to
w
swoim
środowisku?
• Czy
płacisz
za
święty
spokój?
• Czy
ufasz
ponieważ
ktoś
napisał
że
tak
jest?
• A
może
jesteś
zbyt
paranoiczny?
• A
co
jeżeli
to
CVE
jest
zmyślone?
36. Komu ufać?
Nikomu.
Mi
też!
Sprawdzać
wszystko
co
można.
Słynny
kompilator
Kena
Thompsona
://c2.com/cgi/wiki?TheKenThompsonHack
Słynny
DUAL_EC_DRBG
by
NSA
h}ps://en.wikipedia.org/wiki/Dual_EC_DRBG
Ciekawy
pomysł
na
propagację
pomysłu:
ZeroTrustInirarve
–
Paweł
Jakub
Dawidek
h}ps://www.youtube.com/watch?v=VNHYJAOMNmE
37. A gdy nie mogę sprawdzić?
Dlaczego
odebrałeś
sobie
kontrolę?
-‐ dla
pieniędzy?
(bo
taniej)
-‐
zasoby
-‐ dla
szybkiego
developmentu?
(bo
nie
wiemy
jak
inaczej
zaspokoić
tę
potrzebę)
–
czas
=>
zasoby
-‐ dla
spokoju
ducha?
(bo
vendor
to
zrobi
i
on
jest
odpowiedzialny)
–
relacje
-‐ Bo
taki
model
jest
dla
mnie
łatwiejszy
(paas,
dbaas,
XaaS)
–
zasoby
-‐ Bo
chcę
być
zgodny
z
regulacjami
i
zaufam
np.
Cloud
HSM
mimo,
że
jest
to
dla
mnie
czarną
skrzynką,
którą
steruję
ze
środowiska,
którego
w
pełni
nie
kontroluję.
–
naiwność
wymuszona
przez
legislacje.
38. Odpowiedzialność to przyjemność
aka „takie mamy prawo”
Wymagania:
HIPAA
na
cloudzie.
Co
implikuje
-‐>
NIST
-‐>
FIPS
140-‐2
Tu
piszą,
że
ta
chmura
jest
kompatybilna
h}ps://aws.amazon.com/
compliance/hipaa-‐compliance/
i
wszystko
jest
w
porządku
prawda?
39. Życie w standardzie bycia odpowiedzialnym
A
więc
dbamy
o
APP-‐>
LIB
-‐>
Kernel
-‐>
Virtualizacja
-‐>
Hardware,
ludzie
i
procedury,
crypto.
Legenda:
Pełna
kontrola
przy
open
source
Brak
kontroli
-‐
vendor
Częściowa
kontrola
41. Kogo i przed kim chcemy
ochronić
Użytkownicy
i
dane;
publiczne,
poufne,
tajne.
Rządy,
profesjonaliści,
script
kiddie.
Standardy,
dobre
praktyki,
błędy.
• FIPS
140-‐2
to
często
downgrade
crypto
• Cloud
to
świetny
model
ekonomiczny
w
którym
oddajesz
kontrolę
(i
dane)
• dh_export
to
słabe
krypto
w
dobrej
wierze
(ha,
ha)
42. Kiedy chmura dodaje nam
wrogów
Sąsiedzi,
side
channele
i
RSA
• h}ps://eprint.iacr.org/2015/898.pdf
“Seriously,
get
off
my
cloud”,
Mehmet
Sinan
˙Inci
et
al.
-‐
libgcrypt
rsa
2048
recovery
• h}ps://www.cs.unc.edu/~reiter/papers/2012/CCS.pdf
„Cross-‐vm
side
channels
and
their
use
to
extract
private
keys“,
-‐
obserwacja
szumu
jako
side
channel
do
wyciągnięcia
klucza
-‐>
libgcrypt
43. Kiedy jest chmura jest naszym
sprzymierzeńcem?
• Skala
• Analiza
porównawcza
• Efekt
długiego
ogona
#pdk
46. Ja i moja forteca/bagno
• Aplikacje
• System
operacyjny
• Biblioteki
• Jądro
• Stos
sieciowy
• syscalle
do
userspace
• Firmware
• Hardware
47. Aplikacje
• Nie
da
rady
sprawdzić
wszystkich
(nawet
w
OpenSource)
ze
względu
na
zasoby.
• Nie
można
im
ufać.
• Sandboxing
to
nie
zawsze
rozwiązanie.
• Należy
je
chronić
przed
niepowołanym
użyciem.
48. Dodajmy entropii do programu
i dlaczego ASLR ssie?
• 32
bit
aplikacje
w
x86
CVE-‐2016-‐3672
Usuwamy
limit
stosu
i
bum...
h}p://hmarco.org/bugs/CVE-‐2016-‐3672-‐
Unlimirng-‐the-‐stack-‐not-‐longer-‐disables-‐
ASLR.html
49. To nie problem jeszcze potrzeba
dziury. Jakiejś typowej.
• Nieśmiertelny
buffer
overflow
• kanarki,
ssp,
i
kompilacja
OS
większość
to
-‐fstack-‐
protector
(istnieją
/-‐strong/-‐all
)
Czyli
–
jeżeli
istnieje
jakiś
błąd
w
Aplikacji
to
potencjalnie
może
być
wykorzystywana
biblioteka,
która
sama
w
sobie
nie
musi
być
bezpieczna.
50. Return Oriented Programing
• Metoda
na
przejście
zabezpieczeń
m.in
Non
executable
memory.
Zbieramy
gadżety
z
bieżącej
binarki
i
zlinkowanych
bibliotek.
Składamy
payload.
Exec
-‐>
zazwyczaj
kończy
się
#
aka
25.069
(root(evil))
51. Co by tu zaatakować – return
to libc
ROP-‐ujemy
do
udostępnionych
funkcji
libc-‐a.
Gdy
znamy
base
address
to
możemy
wykorzystać
często
także
te
funkcje,
które
nie
zostały
wyeksportowane.
Dlatego
c•-‐owcy
(chapeau
bas)
trzymają
m.in.
bazy
typowych
libc-‐ów
by
znać
offsety
od
adresów
bazowych.
53. Silly Effective ROP Exploit Killer
Pomysł
to
następujący
flow.
Przykład
–
jesteś
providerem
CDN
np.
Akamai,
CDNetworks,
AWS
CloudFront,
Cloudflare,
Azure,
Google
etc.
Chcemy
zabezpieczyć
serwer
brzegowy.
(dla
mnie
na
przykład
terminator
SSL-‐a
1zN)
Przygotowuję
Gentoo
stage
4
w
image
posiadające
prebudowane
.o(biekty)
dla
interesujących
nas
bibliotek/
binarek.
Boot
+
kontekstualizacja.
Wykorzystujemy
entropie
z
/dev/urandom
do
dynamicznego
doboru
layoutu
pamięci
bibliotek
i
interesującego
nas
sw
i.e.
nginx,
haproxy.
Linkujemy
obiekty
w
binarki.
Linkowanie
jest
wielokrotnie
szybsze
od
kompilacji
-‐>
uzyskujemy
binarki,
które
różnią
się
pomiędzy
instancjami.
54. Silly Effective ROP Exploit Killer
W
sytuacji
pozytywnego
ataku
jednej
z
takich
instancji
możemy
wykorzystać
clouda
i
warstwy
niższe
np.
poprzez
badanie
skrótów
części
pamięci
do
wykrywania
kompromitacji.
Jedyny
koszt
to
linkowanie
przy
wstawaniu
instancji
co
wydłuża
czas
na
gotowość.
W
teorii
brak
wpływu
na
runrme.
55. Silly Effective ROP Exploit Killer
Uwagi:
-‐ Nie
zatrzyma
to
zdeterminowanych
profesjonalistów
-‐ Typowe
exploity
nie
zadziałają
na
infra
gdzie
jest
dużo
tak
przygotowanych
końcówek.
-‐ pomysł
jest
free
as
a
beer
–
be
happy
IIY
albo
zaczekaj
na
mój
commit
na
gh
56. Dlaczego jeszcze ASLR ssie i
czy przestanie (aka ASLR-NG)
Dr^2:
Hector
Marco-‐Gisbert
&&
Ismael
Ripoll-‐Ripoll
proponują
ASLR-‐ng.
ASLR
jest
mocno
zależny
od
entropii
w
szczególności
w
32
bitach
brute
force
jest
zdecydowanie
szybszy
(mniej
zgadywania).
Szczerze
polecam
pełną
lekturę.
h}ps://www.blackhat.com/docs/asia-‐16/materials/asia-‐16-‐Marco-‐Gisbert-‐Exploirng-‐Linux-‐And-‐PaX-‐ASLRS-‐Weaknesses-‐On-‐32-‐And-‐64-‐Bit-‐Systems-‐wp.pdf
h}p://cybersecurity.upv.es/solurons/aslr-‐ng/aslr-‐ng.html
57. Zbiasowane przeświadczenia
• Cloud
==
to
co
mamy
tylko
nie
u
nas
To
blackbox.
Może
tak
samo
wyglądać
i
zachowywać
jak
kurczak
a
w
rzeczywistości
być
kaczką.
• Cloud
==
to
co
mamy
tylko
trzeba
komuś
zaufać
Jeżeli
możesz
sobie
na
to
pozwolić
by
ufać
–
zrób
to.
To
Twoje
ryzyko
i
konsekwencje.
• Cloud
to
cel
markerngowy
–logo
cloud
powered...
Znam
dużo
ludzi
którzy
uciekają
od
chmur.
Nie
zawsze
jest
to
optymalna
strategia.
58. Zbiasowane przeświadczenia
• Cloud
to
styl
życia
As
a
Service.
Raz
firma/pieniądze/relacje
są
raz
nie
ma
(i.e.
startupy).
Ryzyko
-‐>
Dynamika
-‐>
optymalizacja.
• Jak
chmury
to
tylko
publiczne.
Prywatne
nie
mają
sensu.
(lub
odwrotnie)
Istnieją
projekty
bardziej
nadające
się
do
jednych
lub
drugich.
Specyficzne
zasoby,
bezpieczeństwo,
obserwowalność
i
sterowalność
fenomenów.
• Nie
musisz
zmigrować
wszystkiego
ale
możesz
(Miro
Burnejko
Infrax
2k15
w
kontekście
przenosin
do
pub
clouda)
Nie
możesz
zmigrować
wszystkiego
ale
mogą
istnieć
elementy,
które
warto
przenieść
do
chmur.
(MC
Infrax
2k16)
• Cloud
to
narzędzie
Tak.
Trzeba
wiedzieć
kiedy
po
nie
sięgać
i
w
jakiej
formie.
Nie
jest
to
rozwiązanie
na
wszystkie
problemy
świata
59. Where you can hit me?
• @
Samsung
–
Samsung
Pay,
Security,
Cloud,
KNOX,
Smart
Building,
• @
h}p://datacentric.pl
-‐
big
data
stuff
• @
h}p://intechion.pl
-‐
IoT
&
Azure,
GCE
• @Conferences,
meerngs
etc.
• In
the
face
-‐
if
you
are
happy
to
argue
and
run
out
of
arguments
during
discussion
;)