Disable Synology Thumbnails Generation

6 05 2014

Thumbnails generation on the Synology NAS can be a useless waste of resources, making your CPU run at 100% for hours or days. This behavior takes place whenever you upload any images without using the proper software released by Synology (i.e. Photo Station Uploader), for example when you upload your holiday pictures through SMB straight onto the Synology shared folder.
Please note that thumbnails are generated even though the Synology Photo Station software is disabled.

In order to avoid this behaviour, you should disable the service responsible for the thumbnails creation, that is /usr/syno/etc/rc.d/S77synomkthumbd.sh.

You can stop it: /usr/syno/etc/rc.d/S77synomkthumbd.sh stop but unless you want it up and running again after any reboot, you can disable it from executing:
chmod -x /usr/syno/etc/rc.d/S77synomkthumbd.sh

Please note that there are many others services running, most of which can be useless to you. Some of them are listed below.

/usr/syno/etc/rc.d/S03hotplugd.sh
/usr/syno/etc/rc.d/S03inetd.sh
/usr/syno/etc/rc.d/S20pgsql.sh
/usr/syno/etc/rc.d/S55cupsd.sh
/usr/syno/etc/rc.d/S56synoindexd.sh
/usr/syno/etc/rc.d/S66fileindexd.sh
/usr/syno/etc/rc.d/S88synomkflvd.sh
/usr/syno/etc/rc.d/S98findhostd.sh

Advertisements




Disable RC4 Cipher Suites on Remote Desktop

12 04 2014

During vulnerability assessment activities I frequently run across the advisory that suggests to disable the RC4 cipher suites on the web server of the day. The reasons behind this are explained here: link.

On windows system, I came across to that vulnerability applied to the Remote Desktop service. I also read about some people having troubles trying to disable those ciphers, meaning the remediations they used didn’t really work. I personally followed this security advisory and it solved the problem.
So basically I just added the following registry key:

  • [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
    • “Enabled”=dword:00000000

As a result, you can look at the handshake TLS handshake before and after the change. It seems that RC4 chiper suites are no longer available.

You can double check with sslscan (sslscan IP:3389 | grep Accepted).





Logrotate rsync server

29 03 2014

In my previous posts, I described how to backup the Synology NAS to an ubuntu-based rsync server. I found out that rsync server doesn’t automatically set a log rotation when installed, thus my logs went quite large.
Here is how you can manage the problem.
Create the file /etc/logrotate.d/rsynclog as follows:
/var/log/rsync.log {
rotate 5
mail yourmail@domain.com
size=5+
copytruncate
compress
missingok
notifempty
}

When your logs get 5MB they will be compressed and rotated for a maximum of 5 times. Some notification will be sent to your email.

For a complete list of commands of the logrotation google welcomes you.





DNS Tunneling with iodine (part 2)

2 03 2014

In my previous article I described how to exploit a covert channel such as dns tunneling using iodine in conjunction with a dns server we are controlling.

Here I describe how to set up a dns tunnel without the need of a controlled dns server of our own.
That is, dns tunneling is made directly through iodine client and iodined server: this is a technically easier scenario to exploit compared with the one in the previous article.

Let’s assume we are phisically connected to a target network. In order to exploit a dns tunneling we have to verify that we can run dns queries to an arbitrary dns server, that is a dns server not included in the default network configurations of the target network (e.g open dns server, 208.67.222.222).

We use nslookup to verify this. Just set up >server 208.67.222.222 and run a query. If the query is successful, than we could exploit a dns tunnel.

What we need is a server with public IP (e.g 11.11.11.11) that we can reach. On that server, install iodine server (i.e iodined), than run:

iodined -fP mypassword 10.100.100.1 myexample.com

than enable port forwading on the kernel:

echo 1 > /proc/sys/net/ipv4/ip_forward

and enable iptables rules:

iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -o eth0 -j MASQUERADE

Now you should turn your server into a SOCK proxy server. You can do it by typing:

ssh -N -D 0.0.0.0:1080 localhost

Now your server is ready.

You should now configure the client. Type:

iodine -fP mypassword -r 11.11.11.11 myexample.com

If it is working, you should see something like:

Opened dns0
Opened UDP socket
Sending DNS queries for myexample.com to 11.11.11.11
Autodetecting DNS query type (use -T to override).
Using DNS type NULL queries
Version ok, both using protocol v 0x00000502. You are user #0
Setting IP of dns0 to 10.100.100.2
Setting MTU of dns0 to 1130
Server tunnel IP is 10.100.100.1
Skipping raw mode
Using EDNS0 extension
Switching upstream to codec Base128
Server switched upstream to codec Base128
No alternative downstream codec available, using default (Raw)
Switching to lazy mode for low-latency
Server switched to lazy mode
Autoprobing max downstream fragment size... (skip with -m fragsize)
...768 not ok.. 384 ok.. 576 ok.. 672 ok.. 720 ok.. ...744 not ok.. 732 ok.. will use 732-2=730
Setting downstream fragment size to max 730...
Connection setup complete, transmitting data.

The tunnel is ready. Try pinging 10.100.100.1 to verify connection, then set up SOCKv5 proxy settings in your browser: IP 10.100.100.1 and port 1080.

You should now be browsing the internet.





Gotta-See Video [02]

15 10 2013

Network security + privilege escalation @Derbycon

http://www.irongeek.com/i.php?page=videos/derbycon3/4101-pigs-don-t-fly-why-owning-a-typical-network-is-so-easy-and-how-to-build-a-secure-one-matt-scriptjunkie-weeks