¡GoConqr estrena diseño! Cuéntanos qué te parece.

Regístrate gratis

Test

2b Software vulnerabilities

Yawen Hou 12 preguntas

Hacer el test

Este test tiene tipos de pregunta que se abren en el reproductor de siempre.

Preguntas del test (12)

  1. 1Typical memory corruption bugs:
    1. Astack based buffer overflow
    2. Bheap overflow
    3. Coff-by-one overflow
    4. Duse- after-free
  2. 2Buffer overflow: Simple [blank_start]overwrite[blank_end]

    struct {
    char name[8];
    long is_admin;
    } info;

    > in debugger can we see that is_admin is 8 bytes after name

    >>> print &info.name
    (char (*)[40]) 0x7fffffffdce0
    >>> print &info.is_admin
    (long *)0x7fffffffdd08

    By write more than [blank_start]40[blank_end] bytes we can overwrite info.is_admin!
    1. A40
    2. Boverwrite
  3. 3In the stack [blank_start]rsp[blank_end] ([blank_start]stack pointer[blank_end]) keep track of [blank_start]top[blank_end] of the stack.
    The stack grows [blank_start]downwards[blank_end] >> [blank_start]rsp[blank_end] is [blank_start]decremented[blank_end] when pushing.    Imagen de la pregunta 3
    1. Arsp
    2. Besp
    3. Ctop
    4. Dbottom
    5. Estack pointer
    6. Fframe pointer
    7. Gdownwards
    8. Hupwards
    9. Irsp
    10. Jebp
    11. Kdecremented
    12. Lincremented
  4. 4This is stack..?Imagen de la pregunta 4
    1. Aoverflow
  5. 5Order of operations: (type 1, 2, 3, 4) when calling a function (returning is in the other sense)
    [blank_start]3[blank_end]) decrease [blank_start]stack[blank_end] pointer to make space for variables
    [blank_start]1[blank_end]) push current r[blank_start]b[blank_end]p onto stack
    [blank_start]2[blank_end]) set new rbp to rsp (top of stack)
    1. A3
    2. Bstack
    3. C1
    4. Db
    5. E2
  6. 6Injecting shellcode:
    > Shellcode = snippet of e[blank_start]xecutable[blank_end] code that we write in memory with a buffer [blank_start]overflow[blank_end], and having the [blank_start]retur[blank_end]n address pointing to the beginning of our code
    > when function reaches the end:
    >> [blank_start]local[blank_end] variables are deallocated from the stack
    >> [blank_start]rbp[blank_end] is popped from the stack
    >> r[blank_start]i[blank_end]p is popped from the stack
    >> execution continues at the r[blank_start]et[blank_end] address    Imagen de la pregunta 6
    1. Aet
    2. Bxecutable
    3. Cretur
    4. Dlocal
    5. Erbp
    6. Fi
    7. Goverflow
  7. 7To protect against overflows:
    > [blank_start]Stack[blank_end] c[blank_start]anarie[blank_end]s: push a r[blank_start]andom[blank_end] value on the stack at the beginning of the function, before returning, verify that the value has not been m[blank_start]odifi[blank_end]ed (done by default by gcc)
    >> :( : can be by-passed by writing the return address / other address d[blank_start]irectl[blank_end]y
    >> :( : we can use [blank_start]format[blank_end] string vulnerability to r[blank_start]ead[blank_end] the value of the canary
    1. AStack
    2. Banarie
    3. Candom
    4. Directl
    5. Eformat
    6. Fead
    7. Godifi
  8. 8Non executable memory:

    Typically you do not want to set x permission on a page that can be written during execution:
    > The pages that contain code are e[blank_start]xecut[blank_end]able but not w[blank_start]rite[blank_end]able
    > The pages that contain data are w[blank_start]rite[blank_end]able but not e[blank_start]xecut[blank_end]able

    >> We can by-pass this by doing [blank_start]Return[blank_end] [blank_start]oriented[blank_end] programming (ROP)
    Instead of writing ur code on the sack search for piece of code (gadgets) in the program that end with a r[blank_start]eturn[blank_end] instruction.
    Put the a[blank_start]ddress[blank_end]es of these gadgets on the stack
    The gadgets will be executed in sequence    Imagen de la pregunta 8
    1. AReturn
    2. Boriented
    3. Ceturn
    4. Dddress
    5. Execut
    6. Frite
    7. Grite
    8. Hxecut
  9. 9A[blank_start]ddress[blank_end] s[blank_start]pace[blank_end] l[blank_start]ayout[blank_end] r[blank_start]andomisation[blank_end]:
    > Every time a program is started, it is loaded at a r[blank_start]andom[blank_end] address
    > Every time the system boots, the OS is loaded at r[blank_start]andom[blank_end] address

    We can bypass ASLR:
    > ASLR works by shifting addresses by a c[blank_start]onstant[blank_end] value
    > The program might leak the address of a function / variable
    > We can calculate other addresses based on that
    1. Address
    2. Bpace
    3. Cayout
    4. Dandomisation
    5. Eandom
    6. Fandom
    7. Gonstant
  10. 10FormatString vulnerabilities:
    > The [blank_start]first[blank_end] parameter is the format string
    > %[blank_start]s[blank_end], parameter is the address of a string
    > %[blank_start]d[blank_end], parameter is an integer
    > parameters are read from the s[blank_start]tack[blank_end]
    > printf doesn't know [blank_start]how[blank_end] many parameters are received

    >> Peter%p%p%[blank_start]p[blank_end]%p%p%p%p%p%p will dump address that are on the stack, and we can read arbitrary memory with %[blank_start]s[blank_end] ( we can read the data at this address)
    >> %[blank_start]n[blank_end] format spec allows to write the number of chars outputted by printf at the address given by the correspond- ing parameter!

    To avoid that:
    > the first parameter to printf should be a c[blank_start]onstant[blank_end]    Imagen de la pregunta 10
    1. Aonstant
    2. Bfirst
    3. Cd
    4. Ds
    5. Ehow
    6. Ftack
    7. Gp
    8. Hs
    9. In

Información

Descripción
- (2 Web app & Software vulnerabilities) Information security Test sobre 2b Software vulnerabilities, creado por Yawen Hou el 08/06/2019.
Idioma
English
Visitas
1
Valoración
Aún sin valoraciones
Valora este test
Valora este test

Escríbenos

¿Sobre qué es tu mensaje?

¿Qué te parece el nuevo diseño?

¿Te gusta?