SMB / Netbios Enumeration

SMB / Netbios
# Search for SMB services (open ports only reported)
nmap -p139,445 a.a.a.a-b --open

# Specific nbt span
nbtscan a.a.a.a-b

SMB Null Session 
This is valid for Windows machines before 2003 Server and XP
rpcclient -U "" a.a.a.a
Password: <leave empty>
> srvinfo
... (server info)
> enumdomusers
... (users defined on server)
> getdompwinfo
... (password policy info)

enum4linux
enum4linux -v a.a.a.a

nmap using 'nse'
# Enumerate SMB users
nmap -p139,445 --script smb-enum-users a.a.a.a

# Check for SMB Vunerabilities
nmap -p139,445 --script smb-check-vulns --script-args=unsafe=1 a.a.a.a

SNMP Enumeration

SNMP Enumeration
# SNMP scan for open 161 ports
nmap -sU -p 161 --open a.a.a.a-b

onesixtyone
# Use the 161 tool
# community is a file which contains a list of community strings eg
public
private
manager
# ips is a file which contains a list of ip addresses.  It can be generated easily using
for ip in (seq 50 100); do
echo a.a.a.$ip >> ips
done
# Now invoke the onesixtyone tool with these files
onesixtyone -c community -i ips

snmpwalk
# Use snmpwalk to get the values of each leaf of the snmp server using community string 'public' and version 1
snmpwalk -c public -v1 a.a.a.a

# Search for a particular MiB value
snmpwalk -c public -v1 a.a.a.a 1.2.3.4.5.6.7.8.9

snmpenum



snmpcheck

SMTP Enumeration

SMTP Enumeration
# Scan for open port 25
nmap -sT -p 25 --open a.a.a.a-b


# Connect to an SMTP server
nc -nv a.a.a.a 25
220 ... server details
# Verify that a user exists.
> VRFY ******
250 ... ******


where a.a.a.a-b is an ip range such as 192.168.1.100-150

nmap & Port Scanning

# ICMP / ping sweep
nmap -sn a.a.a.a-b

# Output to a grepable file
nmap -sn a.a.a.a-b -oG nmap-ping-sweep.txt
grep Up nmap-ping-sweep.txt

# Specific port scan
nmap -p 22 a.a.a.a-b -oG nmap-ssh-scan.txt


Port Scanning
# Connect scan
nmap -sT a.a.a.a-b

# Syn / half open scan
nmap -sS a.a.a.a-b

# Syn scan on the top 100 ports
nmap -sS --top-ports 100 a.a.a.a-b

# ACK scan
nmap -sA --top-ports 100 a.a.a.a-b

# SNMP scan for open 161 ports
nmap -sU -p 161 --open a.a.a.a-b

# Banner grabbing
nmap -sV a.a.a.a-b

# Operating system fingerprinting
nmap -O a.a.a.a-b

# Comprehensive scan
nmap -A a.a.a.a-b

nse = nmap scripting engine

where a.a.a.a-b is an ip range such as 192.168.1.100-150

Using hping3

A quick cheat sheet for using hping3 for port scanning,

-c 1      Only send one request per port (c = count)
-v        Verbose, show response for each port
-1        Sends a ping request (ICMP echo request) This number one not letter ell
-2        Send as UDP packet
-S        Send a SYN scan, open ports will send a SYN-ACK packet back (a half-open scan)
-A        Send an ACK packet
-F        Send packet with a FIN flag
-8 1-500  Scan a range of ports equivalent of --span
-p 80     Scan a particular port

Examples

Send one request with a half-open scan to port 80
> hping3 -c 1 -S <www.website.somewhere> -p 80
HPING <www.website.somewhere> (eth1 <website ip>): S set, 40 headers + 0 data bytes
len=46 ip=<website ip> ttl=64 id=31610 sport=80 flags=SA seq=0 win=65535 rtt=14.8 ms

--- <www.website.somewhere> hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss


Send one request per port using a half-open scan against a Windows XP machine with no firewall
>hping3 -c 1 -S --scan 1-10000 <ip address>
Scanning <ip address>, port 1-10000
10000 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+-----+
|port| serv name |  flags  |ttl| id  | win | len |
+----+-----------+---------+---+-----+-----+-----+
  445 microsoft-d: .S..A...  64 33955 65535    46
  139 netbios-ssn: .S..A...  64 46756 65535    46
  135 loc-srv    : .S..A...  64 47780 65535    46
 3389              .S..A...  64 58947 65535    46

All replies received. Done.
Not responding ports:

Flags
The S and A flags show that the target system responded with a SYN-ACK which means the port is open and can be explored further.

Spring Sleuth

Sleuth is used to trace calls in a microservices environment. It creates a trace-id over the whole interactions and a span-id between each call.  For example, there is a call from a client to a microservice to load information for a customer id.  First is the call to the customer service, then the recent orders and accounts services.  All these calls would share the same trace-id but between each one is a different span-id.  To turn on sleuth just add the following dependencies into the pom.  You'll also need to add an application name.

spring.application.name=My Server

Maven

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-starter-sleuth</artifactId>

    <version>1.2.0.RELEASE</version>

</dependency>

The trace and span ids will now be created and can be seen in the headers.

To log this and make it useful though is one thing but there is a graphical tool which makes this very easy.

Zipkin

Zipkin can be configured so that all Sleuth output is sent there and it allows a view of the interactions so that the times and services called can be seen.  To configure and use zipkin just add another dependency,

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-sleuth-zipkin</artifactId>

    <version>1.2.0.RELEASE</version>
</dependency>

By default everything is logged to localhost:9411 but this can be changed by adding a property

spring.zipkin.baseurl=http://zipkin:9411/

Docker

If you are running with docker you'll need to add a zipkin image into the compose file,

      

  zipkin:

    image: openzipkin/zipkin

    networks:

      - my-network

    hostname: zipkin

    ports:
      - "9411:9411"

Docker crib sheet

Here are a list of commands that are useful for docker, docker-machine and docker-compose

Listings

// See what docker containers are running
> docker ps

// See which images exist
> docker images
> docker image ls

// See which networks exist (usually created as part of docker-compose)
> docker network ls

// See which volumes exist
> docker volume ls

Removing Images and Containers

// List the images and then remove one using the image id
> docker rmi <image_id>

// List the containers and remove one using the container id
> docker rm <container_id>

// Remove a volume
> docker volume rm <volume_id>

// Remove a network
> docker network rm <network_id>

Starting and stopping

// Start a particular image and routing 1234 on localhost to 5678 on the docker image.  For a web application you'll need to expose the application server port such as 8080 eg -p 8080:8080
// After running this it'll show up on a docker ps as a container running this image
> docker run -p 1234:5678 <image_id>

// Start an image in 'detached' mode to keep the output quiet
> docker run -d -p 1234:5678 <image_id>

// View the logs of the docker container running a particular image
> docker logs <container_id>

// Stop a particular container
> docker stop <container_id>

// Attach a shell to a running docker container
> docker exec -it <container_id> "/bin/bash"

// Start with an environment variable
> docker run -d -e MY_ENVIRONMENT_VAR=bob <image_id>

Other useful commands

// See what resources are currently being used
> docker stats

// Grab the logs from a docker machine
> dockers logs <container_id> > output.log

// Copy a file from a docker image to the local machine
> docker cp <container_id>:<container file path> <local path>
> docker cp ab34d4532e78:/tmp/log.txt ./

docker-machine

// Useful where the host machine doesn't support natively such as anything pre windows 10

// Get the ip of the docker-machine, usually 192.168.99.100
> docker-machine ip

Swagger UI ReST Documentation

Where SOAP gives a clear contract between the client and service, ReST services do not.  This means that the documentation is even more important to allow correct use of the service for the client.  Swagger allows the ReST endpoints to be documented as annotations within the code so that it is easier to write and maintain.

Maven Dependencies

Add the two dependencies below to use swagger and enable the swagger ui.

    <dependency>
        <groupId>io.springfox</groupId>
        <artifactId>springfox-swagger2</artifactId>
        <version>2.6.1</version>
    </dependency>
    <dependency>
        <groupId>io.springfox</groupId>
        <artifactId>springfox-swagger-ui</artifactId>
        <version>2.6.1</version>
    </dependency>

Spring Integration

With Spring annotation driven configuration this process is easy.  Create a class and annotate it with @Configuration so that spring uses it.  Additionally use @EnableSwagger2 to make sure that swagger is enabled.

@Configuration
@EnableSwagger2
public class SwaggerConfiguration
{
    /**
     * Add to the swagger documentation
     *
     * @return The {@link Docket} class with api information and config
     */
    @Bean
    public Docket getApiDocumentation()
    {
        return new Docket(DocumentationType.SWAGGER_2)
                .groupName("Project ReST Service")
                .apiInfo(new ApiInfoBuilder()
                        .title("My Service")
                        .description("My service which does lots of interesting things.")
                        .build())
                .select()
                .apis(RequestHandlerSelectors.any())
                .paths(PathSelectors.any())
                .build();
    }
}

With spring boot the situation isn't really any different to that above accept that the @EnableSwagger2 can be put on the same class as a the @SpringBootApplication annotation or left exactly as it is above.

Swagger Annotations

In addition to the annotation to enable swagger (@EnableSwagger2) the other main annotations to use are,

@Api - this can be used on a controller to describe the overall behaviour

@ApiOperation - put this on the methods in the controller to describe what they do

@ApiParam - used to describe the particular parameter that is passed to a controller method

A full list of annotations can be found here https://github.com/swagger-api/swagger-core/wiki/Annotations-1.5.X

Mocking new instances with Powermock

Using Powermock it is possible to mock a new instance to avoid unnecessary depth to your unit test. This is relatively unusual in an IoC environment (inversion of control eg spring) because you'd inject the PropertyLoader and therefore mocking would be easy.  However, particularly in legacy code this can be found.

If a class has this method you many not want to traverse into the PropertyLoader.

public class MyClass {

    /**
     * Method to enrich the object with a property applicable for today.
     *
     * @param myObj The object to be enriched
     */
    public void enrichWithProperties(MyObject myObj) {
        final PropertyLoader propertyLoader = new PropertyLoader();
        myObj.setProperty(propertyLoader.getTodaysProperty());
    }
}

It could be that new PropertyLoader() has a whole series of dependencies that you don't want to end up mocking as this will make the unit test really unclear.  Instead you can use Powermock to return a mocked PropertyLoader instance to greatly simply things.



import static org.junit.Assert.assertEquals;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;
import static org.powermock.api.mockito.PowerMockito.whenNew;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;

/**
 * Test class for the .....
 */
@RunWith(PowerMockRunner.class)
@PrepareForTest(MyClass.class)
public class MyClassTest {

    /** The class under test. */
    private MyClass classUnderTest = new MyClass();

    @Test
    public void testEnrichWithProperties() {

        // Arrange
        final String todaysValue = "todaysValue";
        final MyObject myObj = new MyObject();
        final PropertyLoader mockedPropertyLoader = mock(PropertyLoader.class);
        whenNew(PropertyLoader.class).withAnyArguments().thenReturn(mockedPropertyLoader);
        when(mockedPropertyLoader.getTodaysProperty()).thenReturn(todaysValue);

        // Act
        classUnderTest.enrichWithProperties(myObj);

        // Assert
        assertEquals(todaysValue, myObj.getProperty());
    }

}


Note: Unlike the mocking statics, you have to PrepareForTest the class which instantiates the mocked class not the mocked class itself. So above MyClass is prepared not PropertyLoader.

Eclipse Not Finding com.sun.tools

This is really simple and obvious but took me a while to work out.  I had a maven project which Eclipse would open but one of the maven dependencies has a child of

    <dependency>
        <groupId>com.sun</groupId>
        <artifactId>tools</artifactId>
    </dependency>

The maven plugin couldn't find this dependency and as a result wouldn't build the project, show compilation errors or build unit tests.

It turns out that a recent java installation had changed the path environment variable to put

    C:\ProgramData\Oracle\Java\javapath

at the front of the PATH variable.  The contents of this folder are shortcuts to the runtime (JRE) environment.  This means that when I was starting Eclipse it was running a jre and not a jdk.  Sorting out the PATH environment variable and moving the offending new entry to the end meant that I was using my own JAVA_PATH again which was pointing to the jdk.  Restarting Eclipse then meant that the problem was sorted.