kali

apt-get update
apt-get dist-upgrade
apt-get install fonts-nanum*
init 6

## 필요시 한글 입력 키보드 설치
apt-get install nabi im-switch // 한글 입력 키보드 설치
im-config -s nabi
im-config -c
init 6
shift + space bar 한/영 전환 가능

## vmware tools 설치
cd ~
apt-get install git gcc make linux-headers-$(uname -r)
git clone https://github.com/rasa/vmware-tools-patches.git

카테고리: linux | 댓글 남기기

openssl ciphers list

출처: https://www.mkssoftware.com/docs/man1/openssl_ciphers.1.asp


SYNOPSIS

openssl ciphers [-v] [-ssl2] [-ssl3] [-tls1] [cipherlist]


DESCRIPTION

The cipherlist command converts OpenSSL cipher lists into ordered SSL cipher preference lists. It can be used as a test tool to determine the appropriate cipherlist.

Options

-v 

(verbose option) lists ciphers with a complete description of protocol version (SSLv2 or SSLv3; the latter includes TLS) key exchange, authentication encryption and mac algorithms used along with any key size restrictions and whether the algorithm is classed as an “export” cipher. Note that without the -v option ciphers may seem to appear twice in a cipher list; this is when similar ciphers are available for SSL v2 and for SSL v3/TLS v1.

-ssl3 

only includes SSL v3 ciphers.

-ssl2 

only includes SSL v2 ciphers.

-tls1 

only includes TLS v1 ciphers.

-h 
-? 

prints a brief usage message.

cipherlist 

is a cipher list to convert to a cipher preference list. If it is not included then the default cipher list will be used. The format is described below.


CIPHER LIST FORMAT

The cipher list consists of one or more cipher strings separated by colons. Commas or spaces are also acceptable separators but colons are normally used.

The actual cipher string can take several different forms.

It can consist of a single cipher suite such as RC4-SHA.

It can represent a list of cipher suites containing a certain algorithm or cipher suites of a certain type. For example SHA1 represents all ciphers suites using the digest algorithm SHA1 and SSLv3 represents all SSL v3 algorithms.

Lists of cipher suites can be combined in a single cipher string using the + character. This is used as a logical and operation. For example SHA1+DES represents all cipher suites containing the SHA1 and the DES algorithms.

Each cipher string can be optionally preceded by the characters !, - or +.

If ! is used then the ciphers are permanently deleted from the list. The ciphers deleted can never reappear in the list even if they are explicitly stated.

If - is used then the ciphers are deleted from the list, but some or all of the ciphers can be added again by later options.

If + is used then the ciphers are moved to the end of the list. This option doesn’t add any new ciphers it just moves matching existing ones.

If none of these characters is present then the string is just interpreted as a list of ciphers to be appended to the current preference list. If the list includes any ciphers already present they will be ignored: that is they will not moved to the end of the list.

Additionally the cipher string @STRENGTH can be used at any point to sort the current cipher list in order of encryption algorithm key length.


CIPHER STRINGS

The following is a list of all permitted cipher strings and their meanings:

DEFAULT 

the default cipher list. This is determined at compile time and is normally ALL:!ADH:RC4+RSA:+SSLv2:@STRENGTH. This must be the first cipher string specified.

ALL 

all ciphers suites except the eNULL ciphers which musti be explicitly enabled.

HIGH 

“high” encryption cipher suites. This currently means those with key lengths larger than 128 bits.

MEDIUM 

“medium” encryption cipher suites currently those using 128 bit encryption.

LOW 

“low” encryption cipher suites currently those using 64 or 56 bit encryption algorithms but excluding export cipher suites.

EXP 
EXPORT 

export encryption algorithms. Including 40 and 56 bits algorithms.

EXPORT40 

specifies 40 bit export encryption algorithms.

EXPORT56 

56 bit export encryption algorithms.

eNULL 
NULL 

the “NULL” ciphers that is those offering no encryption. Because these offer no encryption at all and are a security risk they are disabled unless explicitly included.

aNULL 

the cipher suites offering no authentication. This is currently the anonymous DH algorithms. These cipher suites are vulnerable to a “man in the middle” attack and so their use is normally discouraged.

RSA 
RSA 

cipher suites using RSA key exchange.

kEDH 

cipher suites using ephemeral DH key agreement.

kDHr 
kDHd 

cipher suites using DH key agreement and DH certificates signed by CAs with RSA and DSS keys respectively. Not implemented.

aRSA 

cipher suites using RSA authentication that is the certificates carry RSA keys.

aDSS 
DSS 

cipher suites using DSS authentication that is the certificates carry DSS keys.

aDH 

cipher suites effectively using DH authentication that is, the certificates carry DH keys. Not implemented.

kFZA 
aFZA 
eFZA 
FZA 

ciphers suites using FORTEZZA key exchange, authentication encryption or all FORTEZZA algorithms. Not implemented.

TLSv1 
SSLv3 
SSLv2 

TLS v1.0 SSL v3.0 or SSL v2.0 cipher suites respectively.

DH 

cipher suites using DH including anonymous DH.

ADH 

anonymous DH cipher suites.

3DES 

cipher suites using triple DES.

DES 

cipher suites using DES (not triple DES).

RC4 

cipher suites using RC4.

RC2 

cipher suites using RC2.

IDEA 

cipher suites using IDEA.

MD5 

cipher suites using MD5.

SHA1 
SHA 

cipher suites using SHA1.


CIPHER SUITE NAMES

The following lists give the SSL or TLS cipher suites names from the relevant specification and their OpenSSL equivalents.

SSL v3.0 cipher suites.

SSL_RSA_WITH_NULL_MD5                   NULL-MD5
SSL_RSA_WITH_NULL_SHA                   NULL-SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5          EXP-RC4-MD5
SSL_RSA_WITH_RC4_128_MD5                RC4-MD5
SSL_RSA_WITH_RC4_128_SHA                RC4-SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5      EXP-RC2-CBC-MD5
SSL_RSA_WITH_IDEA_CBC_SHA               IDEA-CBC-SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA       EXP-DES-CBC-SHA
SSL_RSA_WITH_DES_CBC_SHA                DES-CBC-SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA           DES-CBC3-SHA

SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA    Not implemented.
SSL_DH_DSS_WITH_DES_CBC_SHA             Not implemented.
SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA        Not implemented.
SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA    Not implemented.
SSL_DH_RSA_WITH_DES_CBC_SHA             Not implemented.
SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA        Not implemented.
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-DSS-DES-CBC-SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA            EDH-DSS-CBC-SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA       EDH-DSS-DES-CBC3-SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-RSA-DES-CBC-SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA            EDH-RSA-DES-CBC-SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA       EDH-RSA-DES-CBC3-SHA

SSL_DH_anon_EXPORT_WITH_RC4_40_MD5      EXP-ADH-RC4-MD5
SSL_DH_anon_WITH_RC4_128_MD5            ADH-RC4-MD5
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA   EXP-ADH-DES-CBC-SHA
SSL_DH_anon_WITH_DES_CBC_SHA            ADH-DES-CBC-SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA       ADH-DES-CBC3-SHA

SSL_FORTEZZA_KEA_WITH_NULL_SHA          Not implemented.
SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA  Not implemented.
SSL_FORTEZZA_KEA_WITH_RC4_128_SHA       Not implemented.

TLS v1.0 cipher suites.

TLS_RSA_WITH_NULL_MD5                   NULL-MD5
TLS_RSA_WITH_NULL_SHA                   NULL-SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5          EXP-RC4-MD5
TLS_RSA_WITH_RC4_128_MD5                RC4-MD5
TLS_RSA_WITH_RC4_128_SHA                RC4-SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5      EXP-RC2-CBC-MD5
TLS_RSA_WITH_IDEA_CBC_SHA               IDEA-CBC-SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA       EXP-DES-CBC-SHA
TLS_RSA_WITH_DES_CBC_SHA                DES-CBC-SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA           DES-CBC3-SHA

TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA    Not implemented.
TLS_DH_DSS_WITH_DES_CBC_SHA             Not implemented.
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        Not implemented.
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA    Not implemented.
TLS_DH_RSA_WITH_DES_CBC_SHA             Not implemented.
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        Not implemented.
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-DSS-DES-CBC-SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA            EDH-DSS-CBC-SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       EDH-DSS-DES-CBC3-SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA   EXP-EDH-RSA-DES-CBC-SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA            EDH-RSA-DES-CBC-SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       EDH-RSA-DES-CBC3-SHA

TLS_DH_anon_EXPORT_WITH_RC4_40_MD5      EXP-ADH-RC4-MD5
TLS_DH_anon_WITH_RC4_128_MD5            ADH-RC4-MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA   EXP-ADH-DES-CBC-SHA
TLS_DH_anon_WITH_DES_CBC_SHA            ADH-DES-CBC-SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       ADH-DES-CBC3-SHA

Additional Export 1024 and other cipher suites

Note: these ciphers can also be used in SSL v3.

TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA     EXP1024-DES-CBC-SHA
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA      EXP1024-RC4-SHA
TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA EXP1024-DHE-DSS-DES-CBC-SHA
TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA  EXP1024-DHE-DSS-RC4-SHA
TLS_DHE_DSS_WITH_RC4_128_SHA            DHE-DSS-RC4-SHA

SSL v2.0 cipher suites.

SSL_CK_RC4_128_WITH_MD5                 RC4-MD5
SSL_CK_RC4_128_EXPORT40_WITH_MD5        EXP-RC4-MD5
SSL_CK_RC2_128_CBC_WITH_MD5             RC2-MD5
SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5    EXP-RC2-MD5
SSL_CK_IDEA_128_CBC_WITH_MD5            IDEA-CBC-MD5
SSL_CK_DES_64_CBC_WITH_MD5              DES-CBC-MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5        DES-CBC3-MD5

NOTES

The non-ephemeral DH modes are currently unimplemented in OpenSSL because there is no support for DH certificates.

Some compiled versions of OpenSSL may not include all the ciphers listed here because some ciphers were excluded at compile time.


EXAMPLES

Verbose listing of all OpenSSL ciphers including NULL ciphers:

openssl ciphers -v 'ALL:eNULL'

Include all ciphers except NULL and anonymous DH then sort by strength:

openssl ciphers -v 'ALL:!ADH:@STRENGTH'

Include only 3DES ciphers and then place RSA ciphers last:

openssl ciphers -v '3DES:+RSA'
카테고리: linux | 댓글 남기기

apt-get ?

출처: http://blog.outsider.ne.kr/346

apt-get(Advanced Packaging Tool)은 우분투(Ubuntu)를 포함안 데비안(Debian)계열의 리눅스에서 쓰이는 팩키지 관리 명령어 도구입니다. 우분투에는 GUI로 되어 있는시냅틱 꾸러미 관리자도 있기는 하지만 이런 저런 개발관련 패키지를 설치할 때는 커맨드기반인 apt-get이 더 편하기도 합니다. sudo는 superuser권한으로 실행하기 위함입니다.

패키지 인덱스 인덱스 정보를 업데이트 : apt-get은 인덱스를 가지고 있는데 이 인덱스는 /etc/apt/sources.list에 있습니다. 이곳에 저장된 저장소에서 사용할 패키지의 정보를 얻습니다.

sudo apt-get update

설치된 패키지 업그래이드 : 설치되어 있는 패키지를 모두 새버전으로 업그래이드 합니다.

sudo apt-get upgrade

의존성검사하며 설치하기

sudo apt-get dist-upgrade

패키지 설치

sudo apt-get install 패키지이름

패키지 재설치

apt-get –reinstall install 패키지이름

패키지 삭제 : 설정파일은 지우지 않음

sudo apt-get remove 패키지이름

설정파일까지 모두 지움

sudo apt-get –purge remove 패키지이름

패키지 소스코드 다운로드

sudo apt-get source 패키지이름

위에서 받은 소스코드를 의존성있게 빌드

sudo apt-get build-dep 패키지이름

패키지 검색

sudo apt-cache search 패키지이름

패키지 정보 보기

sudo apt-cache show 패키지이름

apt를 이용해서 설치된 deb패키지는 /var/cache/apt/archive/ 에 설치가 됩니다.

카테고리: linux | 댓글 남기기

redis RCE 취약점 (CVE-2015-4335)

Redis?

  • set, get 이 빈번히 발생되는 데이터 저장시 최적의 성능을 보장하는 NoSQL DB
  • 메모리 기반의 오픈소스 No SQL
  • Install 링크: http://redis.googlecode.com/

취약점 원문: http://benmmurphy.github.io/blog/2015/06/04/redis-eval-lua-sandbox-escape/

Redis EVAL Lua Sandbox Escape

It is possible to break out of the Lua sandbox in Redis and execute arbitrary code. This vulnerability is not new and is heavily based on Peter Cawley’s work with Lua bytecode type confusion.

This shouldn’t pose a threat to users under the trusted Redis security model where only trusted users can connect to the database. However, in real deployments there could be databases that can be accessed by untrusted users. The main deployments that are vulnerable are developers machines, places where redis servers can be reached via SSRF attacks and cloud hosting.

Redis 2.8.21 and 3.0.2 have been released to fix this issue.

Vulnerable Deployments

Developers Machines

Developers machines may be vulnerable because they bind Redis to all interfaces which used to be the default listen directive in the Redis configuration.

Developers may also be vulnerable even if they bind to 127.0.0.1 because Redis is effectively a HTTP server. The first mention of attacking Redis via HTTP I could find is by Nicolas Grégoire where he documents attacking a Redis server on a Facebook property using a SSRF vulnerability.

Because Redis is a HTTP server the same origin policies of browsers will allow any website on the internet to send a POST request to it. When using XHR the body is completely controllable. For example if you run the following in the console of your webbrowser while running wireshark:

var x = new XMLHttpRequest();
x.open("POST", "http://127.0.0.1:6379");
x.send('eval "print(\\"hello\\")" 0\r\n');

In wireshark you will see:

POST / HTTP/1.1
Host: 127.0.0.1:6379
Connection: keep-alive
Content-Length: 27
Pragma: no-cache
Cache-Control: no-cache
Origin: http://www.agarri.fr
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36
Content-Type: text/plain;charset=UTF-8
Accept: */*
Referer: http://www.agarri.fr/kom/archives/2014/09/11/trying_to_hack_redis_via_http_requests/index.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8

eval "print(\"hello\")" 0
-ERR unknown command 'POST'
-ERR unknown command 'Host:'
-ERR unknown command 'Connection:'
-ERR unknown command 'Content-Length:'
-ERR unknown command 'Pragma:'
-ERR unknown command 'Cache-Control:'
-ERR unknown command 'Origin:'
-ERR unknown command 'User-Agent:'
-ERR unknown command 'Content-Type:'
-ERR unknown command 'Accept:'
-ERR unknown command 'Referer:'
-ERR unknown command 'Accept-Encoding:'
-ERR unknown command 'Accept-Language:'
$-1

And in the stdout for Redis you will see:

hello

The attacker is not able to read the response from the server because of the same origin policy. However, this might be worked around by using a DNS rebinding attack. Even with DNS rebinding it might not be possible to read the response because the response is not valid HTTP.

However, reading the response is not necessary because you can package a super generic exploit that checks the result of the redis.call(“INFO”) command and then launches a OS/architecture specific payload.

SSRF attacks

This is similar to attacking developers except a trusted server is tricked into making a request to the Redis server However, you need a lot of control over the body which might not often be possible depending on how the body is encoded.

Redis Cloud Hosting

This will only effect providers where people running arbitrary code from the Redis process is not part of their threat model. The major players in this area look like they are using sandboxing. For example the pids returned by ‘INFO’ on heroku are very low <10 which indicates they are running the Redis servers in containers. You can already run arbitrary code in containers via dynos on Heroku so running arbitrary code in a Redis container is probably not useful for an attacker. Amazon Elasticcache also looks like it uses linux containers.

Similarily, it looks like Microsoft’s hosted Redis solution runs in an isolated VM. Redis ‘INFO’ returns a virtual os string and it takes ~15 minutes to launch an instance. If MS aren’t running in an isolated VM then the 15 minute startup time is very weird.

This will be a problem if a hosting provider runs a whole bunch of redis processes on the same machine/same VM from different customers without any kind of isolation.

Exploit

Peter Cawley has found that the loadstring function can be used to load bytecode that is unsafe. He has created three very useful lua exploit primitives that make exploitation easy.

First is a way of reading the Value contained in a TValue struct. This allows reading the pointer value from a lua tagged value. Some pointer values are already public (using tostring) but there doesn’t seem to be a way to get the pointer value for a lua string so this is useful.

Second is a way of reading 8 bytes from an arbitrary memory address.

Third is a way of writing 8 bytes to an arbitrary memory address.

Using the arbitrary memory read it is possible to leak the address of a known C function. From the address of this c-function it is possible to find the base address of the redis-server binary. From this base address it is possible to find pointers to libc/libsystem_c functions and to find the base address of the libc/libsystem_c libraries. From these libraries it is possible to find the addresses of useful exported functions (longjump/system) and ROP gadgets. This technique is similar to pwntools dynelf

The arbitrary memory read is also used to leak an address inside the stack. The lua_State object holds a long_jump variable that references a long_jump buffer that is allocated on the stack. This leaks the stack address which can be useful if you just want to corrupt the stack or the rsp and rip can be overwritten in the longjump buf to directly take control when longjump is called. OSX has no pointer mangling protections so this is quite easy to corrupt.

On linux the rip and rsp (and rbp) values are mangled. However, if you have full read access to the memory you can reverse the secret cookie value to corrupt the values. Also, linux prevents you from longjmp’ing to an invalid stack frame (ie: the heap) but you can longjump to point the stack inside the longjump buffer then pivot the stack into the heap. This is not really necessary if you don’t care about corrupting the stack and crashing the redis process but if you longjump and don’t corrupt the stack then you can resume normal execution of redis after the exploit has finished running.

Exploitability

I have exploits for Linux 64 bit and OSX 64 bit. Both exploits take care to not crash the redis server during successful execution. They will make a call to system() then go back to normal redis execution.

I have run the Linux exploit on the Amazon RHEL Image (PIE enabled) and the Amazon 14.04 Ubuntu Image (no PIE). I believe the exploit will work on most modern Linux 64 bit systems (I suspect it will not work if you compile libc with fomit-frame-pointer but this can be worked around). It does not use any hardcoded addresses from libc or the Redis binary.

The OSX version I have only tested on Yosemite but an earlier version was working on Mavericks and I believe the Yosemite version works on both. This has been tested with two different Redis versions and similarily does not depend on hardcoded address from libsystem_c or the Redis binary. However, it uses addresses from libsystem_c to speed up the exploit.

Workarounds

The best option is to set a strong password on Redis. Systems that are reachable via HTTP without a password are a problem waiting to happen.

It is also possible to rename the EVAL command. If you are not using EVAL this is a good option but you still might be at risk of someone modifying your Redis data via HTTP SSRF attacks.

Upgrading to Redis 2.8.21 and 3.0.2 will also fix this issue but I still strongly recommend using password authentication on Redis systems.

참조

http://www.agarri.fr/kom/archives/2014/09/11/trying_to_hack_redis_via_http_requests/index.html

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4335

카테고리: security | 댓글 남기기

wordpress 수동 업데이트

1. 모든 플러그인 비활성화
2. 아파치 중지
2. wp-admin, wp-includes 폴더 삭제
3. 업데이트된 wp-admin, wp-includes 폴더 업로드
4. wp-content 폴더는 덮어쓰기
5. 위 과정 실행후, 관리 웹페이지 접근시 db 업데이트 자동 시행됨
6. 업데이트 완료

카테고리: wordpress | 댓글 남기기