Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 47 min ago

Adobe Patch Tuesday - January 2015, (Tue, Jan 13th)

Tue, 01/13/2015 - 12:25

Adobe released one bulletin today, affecting Flash Player. The update should be applied to Windows, OS X as well as Linux versions of Adobes Flash player. It is rated with a priority of 1 for most Windows versions of Flash Player.

Adobe Air, as well as browser like Chrome and Internet Explorer are affected as well.

http://helpx.adobe.com/security/products/flash-player/apsb15-01.html

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Microsoft Patch Tuesday - January 2015 (Really? Telnet?), (Tue, Jan 13th)

Tue, 01/13/2015 - 10:26

Overview of the January 2015 Microsoft patches and their status.

# Affected Contra Indications - KB Known Exploits Microsoft rating(**) ISC rating(*) clients servers MS15-001 Vulnerability in Windows Application Compatibility Cache Could Allow Elevation of Privilege
(ReplacesMS13-031 MS13-046 MS13-048 MS13-063 ) Microsoft Windows

CVE-2015-0002 KB 3023266 vuln. public. Severity:Important
Exploitability: 2 Important Important MS15-002 Vulnerability in Windows Telnet Service Could Allow Remote Code Execution Microsoft Windows KB 3020393 . Severity:Critical
Exploitability: 2 Important Critical MS15-003 Vulnerability in Windows User Profile Service Could Allow Elevation of Privilege Microsoft Windows

CVE-2015-0004 KB 3021674 vuln. public. Severity:Important
Exploitability: 2 Important Important MS15-004 Vulnerability in Windows Components Could Allow Elevation of Privilege Microsoft Windows

CVE-2015-0016 KB 3025421 . Severity:Important
Exploitability: 0 Important Important MS15-005 Vulnerability in Network Location Awareness Service Could Allow Security Feature Bypass Microsoft Windows

CVE-2015-0006 KB 3022777 . Severity:Important
Exploitability: 3 Important Important MS15-006 Vulnerability in Windows Error Reporting Could Allow Security Feature Bypass
(ReplacesMS14-071 ) Microsoft Windows

CVE-2015-0001 KB 3004365 . Severity:Important
Exploitability: 2 Important Important MS15-007 Vulnerability in Network Policy Server RADIUS Implementation Could Cause Denial of Service Microsoft Windows

CVE-2015-0015 KB 3014029 . Severity:Important
Exploitability: 3 Important Important MS15-008 Vulnerability in Windows Kernel-Mode Driver Could Allow Elevation of Privilege
(ReplacesMS08-007 ) Microsoft Windows

CVE-2015-0011 KB 3019215 . Severity:Important
Exploitability: 2 Important Important We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY (*): ISC rating
  • We use 4 levels:
    • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
    • Critical: Anything that needs little to become interesting">Less Urt practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
    • The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threatatches.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Tuesday, January 13th 2015 http://isc.sans.edu/podcastdetail.html?id=4309, (Tue, Jan 13th)

Mon, 01/12/2015 - 18:19
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Are You Piratebay? thepiratebay.org Resolving to Various Hosts, (Mon, Jan 12th)

Mon, 01/12/2015 - 15:24

Thanks to our reader David for sending us this detect (anonymized):

GET announce?info_hash=....peer_id=....ip=....port=....uploaded=....downloaded=....*left=....numwant=.... HTTP/1.0
Host: a.tracker.thepriatebay.org
User-Agent: Bittorrent
Accept: */*
Connection: closed

Davids web server was hit with a sufficient number of requests like the one above to cause a denial of service. The requests originated from thousands of different IP addresses, all appear to be located in China. A quick Google search revealed that he wasnt alone, but other web servers experienced similar attacks.

Given the host header (and David observed various thepriatebay.org host names), it looks like some DNS servers responded with Davids IP address if queried for thepiratebay.org.

I did a quick check of passive DNS systems, and didnt find Davids IP. But when I queried Chinese DNS servers for the host name, I recieved numerous answers. Each answer was only repeated a couple times, if at all. It sort of looked like they all returned different IP addresses. US based DNS servers on the other hand usually dont resolve the host name, or respond with 127.0.0.1, a typical blacklisting technique. Only a handful responded with a routable IP address.

Overall, I am not sure what is happening. Looks like a Chinese firewall issue to me. But if you have any ideas or packets, please let me know.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

IoT: The Rise of the Machines (Guest Diary), (Mon, Jan 12th)

Mon, 01/12/2015 - 07:27

[This is a guest diary submitted by Xavier Mertens]

Our houses and offices are more and more infested by electronic devices embedding a real computer with anoperating system and storage. They areconnected to network resources for remote management, statistics or datapolling. This is called the Internet of Things or IoT. My home network ishardened and any new (unknown)device connected to it receives an IP address from a specific range which has no connectivity with other hosts or theInternet but its packets are logged. The goal is to detect suspicious activity like data leaks or unexpected firmwareupdates. The last toy I boughtyesterday is aSmart Plugfrom Supra-Electronics. This device allows you to control apower plug via your mobile device and calculate the energyconsumption with nice stats. I had a very goodopportunity to buy one for a very low price (25). Lets see whats inside....

The documentation mentions a setup procedure and management via a mobile device (with a free app for IOS orAndroid) but the first reflex is to scan the box. Interesting, a webserver as well as a telnet server are waiting forpackets. Lets try common credentials like admin/admin and...

$ telnet 192.168.254.225
Trying 192.168.254.225...
Connected to 192.168.254.225.
Escape character is ^].
(none) login: admin
Password:
BusyBox v1.12.1 (2014-07-31 06:32:52 CEST) built-in shell (ash)
Enter help for a list of built-in commands.
#

Immediately after the boot sequence, the device started to try to communicate with remote hosts:


Amongst DNS requests and NTP synchronization, a lot of traffic was generated to different IP addresses overUDP/10001. The same packet being sent to different hosts. The payload was a block of 60 bytes:



I was not able to decode the content of this payload, please comment if you recognize some patterns. The devicealso performs a regular connectivity check via a single ICMP ECHO packet sent towww.google.com(every 5 mins).This network traffic is generated by the process called RDTServer:

# ps
PID USER VSZ STAT COMMAND
1 admin 1400 S init
2 admin 0 SWN [ksoftirqd/0]
3 admin 0 SW [events/0]
4 admin 0 SW [khelper]
5 admin 0 SW [kthread]
6 admin 0 SW [kblockd/0]
7 admin 0 SW [kswapd0]
8 admin 0 SW [pdflush]
9 admin 0 SW [pdflush]
10 admin 0 SW [aio/0]
11 admin 0 SW [mtdblockd]
18 admin 1084 S nvram_daemon
19 admin 1612 S goahead
20 admin 872 R RDTServer
24 admin 1400 R telnetd
26 admin 872 S RDTServer
27 admin 872 S RDTServer
33 admin 872 S RDTServer
34 admin 872 S RDTServer
35 admin 872 S RDTServer
36 admin 872 S RDTServer
53 admin 1400 S /bin/sh
238 admin 0 SW [RtmpCmdQTask]
239 admin 0 SW [RtmpWscTask]
366 admin 1400 S -sh
505 admin 1400 R ps
678 admin 1400 S udhcpd /etc/udhcpd.conf
1116 admin 1396 S udhcpc -i apcli0 -s /sbin/udhcpc.sh -p /var/run/udhcp
1192 admin 872 S RDTServer
1207 admin 772 S ntpclient -s -c 0 -hntp.belnet.be-i 86400
#

I grabbed a copy of the RDTServer binary (Mips) and using the strings command against the file revealedinteresting stuff. The IP addresses used were found in the binary:

IP FQDN NetName Country
50.19.254.134 m1.iotcplatform.com AMAZON-EC2-8 US
122.248.234.207 m2.iotcplatform.com AMAZON-EC2-SG Singapore
46.137.188.54 m3.iotcplatform.com AMAZON-EU-AWS Ireland
122.226.84.253 JINHUA-MEIDIYA-LTD China
61.188.37.216 CHINANET-SC China
220.181.111.147 CHINANET-IDC-BJ China
120.24.59.150 m4.iotcplatform.com ALISOFT China
114.215.137.159 m5.iotcplatform.com ALISOFT China
175.41.238.100 AMAZON-AP-RESOURCES-JP Japan


Seeing packets sent to China is often suspicious! The domain nameiotcplatform.combelongs toThroughTek, a company specialized in IoT and M2M (Machine toMachine) connection platforms:

Domain Name:IOTCPLATFORM.COM
Registry Domain ID: 1665166563_DOMAIN_COM-VRSN
Registrar WHOIS Server:whois.godaddy.com
Registrar URL:http://www.godaddy.com
Update Date: 2014-07-09T11:44:15Z
Creation Date: 2011-07-04T08:50:36Z
Registrar Registration Expiration Date: 2016-07-04T08:50:36Z
Registrar:GoDaddy.com, LLC
Registrar IANA ID: 146
Registrar Abuse Contact Email:abuse@godaddy.com
Registrar Abuse Contact Phone: +1.480-624-2505
Registry Registrant ID:
Registrant Name: Charles Kao
Registrant Organization:
Registrant Street: 4F., No.221, Chongyang Rd.,
Registrant City: Taipei
Registrant State/Province: Nangang District
Registrant Postal Code: 11573
Registrant Country: Taiwan
Registrant Phone: +886.886226535111
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email:justin_yeh@tutk.com

In fact, theIOTC platformis a service developed by ThoughTek to establish P2P communications between devices.I read the documentation provided with the device as well as all the website pages and there is no mention of thisservice. Manufacturers should include some technical documentation about the network requirements (ex: todownload firmware updates). In this case, its not a major security issue but this story enforces what we alreadyknow (and be afraid) about IoT: those devices have weak configuration and they lack of visibility/documentationabout their behavior. Take care when connecting them on your network. A best practice is to inspect the traffic theygenerate once online (DNS requests, HTTP(S) request or any other protocol).

--
If the enemy leaves a door open, you must rush in. - Sun Tzu
PGP Key:http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x42D006FD51AD7F2C

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Monday, January 12th 2015 http://isc.sans.edu/podcastdetail.html?id=4307, (Mon, Jan 12th)

Sun, 01/11/2015 - 16:27
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Port 161 Oddities (aka SNMP: so what's going on?), (Sun, Jan 11th)

Sun, 01/11/2015 - 10:58

On a very slow Sunday in JanuaryI noticed that port 161 (designated as SNMP)is still alive and kicking, however the port 161DShield reporttrend sawdownward movementtwo weeks ago, and now we are right back at it with the same intensity. Previously it was discussed here that D-Link routers are at play, so Id like to grab a few packets to confirm that we are still seeing the continuance of known attacks, or if we have something else driving the Port 161 numbers up so high. If anybody has any questionableport 161 traffic they could capture and upload, Id love to review and report on what we are seeing.

tony d0t carothers --gmail

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Some Logs and/or packets please?, (Fri, Jan 9th)

Fri, 01/09/2015 - 19:15

Hi, if you have some logs from the following subnets to your infrastructure and you are able to share, could you?

  • 61.174.51.0/24 (although Ill take /16)
  • 218.2.0.0/24
  • 122.225.0.0/16
  • 112.101.64.0/24
  • 103.41.124.0/24
  • 61.240.144.0/24

If you cant share logs or packets, maybe you could send me a source IP and Destination Port. (just use the contact form or send them direct to markh.isc (at) gmail.com )

The above are all active on SSH and DNS, just trying to see if there is anything else and if so what and in which part of the world.

Regards

Mark

NOTE: Thanks for all the info so far, very much appreciated, keep it coming. If sending a file please email direct to markh.isc (at) gmail.com as the contact form file facility is having a challenge. It is being looked at, but in the mean time please use the email address. ">Update: Firstly thank you all for providing information. The response has been great. ">Ive spent the last 5 hours sending thank">you">and getting the info down :-).

A first look at the data is already providing some interesting info. Ill hopefully get the first cut of some info out later today. If you have devices in the Middle East, Africa,Asia, Europe,South America orAustralia I especially interested in those. Also if you have a packet capture for allowed connections from 61.240.144.64, 65, 66, 67 or IDS/IPS capture of the initial request (allowed or denied) and you can share,great.

Some of the log shared so far include firewall and router logs, honeypot logs (one especially interesting as it is using P0F to passively finger print the source), but also some really interestingnetflow and argus info. So again thanks to you all.

Thanks M

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Microsoft advanced notification service changes. , (Fri, Jan 9th)

Thu, 01/08/2015 - 23:49

Quite a few of you have written in to let us know that Microsoft is changing the way in which they provide information (thanks to you all). ">You can read the full blog here --">/archive/2015/01/08/evolving-advance-notification-service-ans-in-2015.aspx

In a nutshell if you want to be advised in advance younow need to register, select the products used and you will then be provided with information relating to the patches that will be released. If you are a premier customer your technical contact can provide information.">The main point for">">Moving forward, we will provide ANS information directly to Premier customers and current organizations involved in our security programs, and will no longer make this information broadly available through a blog post and web page

Now a lot of us do look at that information to plan their next patching cycle. So you will need to look at that process and see what needs changing. Youll have to rely on the information in your patching solution, or register.

You can register here: http://mybulletins.technet.microsoft.com/

The dashboard that is created in the end looks nice, but for me to early to tell how useful it is at this stage, although it was slightly painful to review each bulletin.It will take a few patch cycles to sort it all out Id say. " />

So going forward you will need to adjust how you identify the patches to be applied within your environment. If you do not want to register you can just visit the main bulletins page here --https://technet.microsoft.com/en-us/library/security/dn631937.aspx

This page has a list of all release bulletins.

Cheers

Mark H

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Friday, January 9th 2015 http://isc.sans.edu/podcastdetail.html?id=4305, (Fri, Jan 9th)

Thu, 01/08/2015 - 18:31
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

New OpenSSL release fixes 2 moderate and 6 low vulnerabilities, (Thu, Jan 8th)

Thu, 01/08/2015 - 11:41

OpenSSL just released a new version of the popular SSL/TLS toolkit.

This release fixes 2 moderate and 6 low vulnerabilities. Luckily, both moderate vulnerabilities can only lead to Denial of Service. The other 6 low vulnerabilities are either difficult to exploit or of unknown impact so while you should update (as always) it appears for now that there is no need to rush with this upgrade.

More information is available at http://openssl.org/news/secadv_20150108.txt.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Assessing the risk of POODLE, (Thu, Jan 8th)

Wed, 01/07/2015 - 23:14

One of the biggest security announcements in the last year was definitely the POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability, which marked the real end of SSLv3. In a contrast with many other previously identified vulnerabilities in encryption algorithms used by SSLv3, this vulnerability is viable, and can be exploited by an attacker without jumping over too many obstacles or requiring large resources the POODLE vulnerability is real.

While this raised quite a bit of panic (in some cases the panic was justified) it also raised quite a bit of dust where it should not have had. The goal of this diary is therefore to clear things up a bit, to allow you to make proper risk assessment on moving away from SSLv3 please do add comments and your experiences (and any corrections, if you find errors).

A little refresher

First, though, a little refresher on how the POODLE vulnerability works. The original paper is available at https://www.openssl.org/~bodo/ssl-poodle.pdf, however I will explain couple of details which are, in my opinion, crucial for this attack and that maybe have not been stressed out as they should have in this paper (my personal opinion is that the steps related to the attack should have been better explained since that would allow people to easily assess the risk).

The vulnerability exists in the fact that, when a CBC encryption algorithms is used, SSLv3 does not cover padding with MAC (Message Authentication Code). Additionally (and this is the key), when there is an entire block of padding, SSLv3 checks only the last byte in the padding block. All other, previous bytes in that block are ignore and the value of the last byte must be equal to the block size (i.e. 15, when the block size is 16 bytes).

If an attacker wants to exploit this vulnerability, he first must perform the following actions:

  • Successfully run a Man-in-the-Middle attack against the victim,
  • Downgrade connection to SSLv3, if TLS is used as well, for example,

If the requirements above have been fulfilled, the attack is relatively simple, and the attacker must do the following:

  • Position the byte he wants to recover as the last byte of a block. This is a critical requirement as we will see later.
  • Copy that block as the last (padding) block.

Now the attacker uses the server as the oracle depending on messages received back. The server will try to decrypt the message and when decrypting the last block, due to the CBC encryption algorithm, after the decryption, the last byte will be XOR-ed with the last byte of the previous block. As we used an entire block of padding, the attacker knows that result of this process must be 15. In other words, if the decryption was successful, the attacker can obtain the plain text value of that byte since he can easily calculate it: the decrypted byte = 15 XOR (the last byte of the previous block).

How does the attacker know if the decryption was successful? Its simple: by observing network traffic from the server:

  • If the decryption failed (and this means that the result was not 15), the attacker will see Alert Code 21, which means Decryption failed (the description says: Decryption of a TLSCiphertext record is decrypted in an invalid way: either it was not an even multiple of the block length or its padding values, when checked, were not correct. This message is always fatal.)
  • If the decryption was successful, the attacker can decrypt the byte. The action that the request will cause does not really matter.

All the attacker needs to do now is cause the victim to issue multiple requests. In average he will need 256 request to decrypt a single byte (but notice that it might take him much more or less requests to do this). By causing the victim to issue arbitrary requests, the attacker decrypts his wanted data (usually a session cookie in web applications) byte by byte.

Practicality of POODLE attacks

As you can see in the previous section, there is a number of requirements that the attacker needs to fulfill to execute POODLE attacks. One of the most important is to make the victim issue arbitrary requests to the server. The attacker must somehow be able to influence these requests the byte he wants to decrypt must be the last byte in a block.
With web applications this is relatively easy since the attacker must be in a MitM position anyway, he can make the victims browser issue such special requests (for more details see the original paper).

However, and this is the crucial point of assessing the risk of POODLE what happens if the attacker cannot influence such requests? Well, according to current information, he will be able to decrypt only single pre-positioned bytes.

While this is still bad, the risk might be lower than with a standard web application. And this is the main point of assessing the risk: in last couple of months Ive seen simply too many cases when an auditor (or a penetration tester) ran a tool which reported that SSLv3 is enabled and blindly marked this as a critical vulnerability that has to be mitigated as soon as possible.

One of the typical cases of such detections are client-server applications that use SSLv3 to protect data, but that do not allow the attacker to modify the requests (for example: monitoring systems). Such systems always issue same requests, and they do this automatically so the attacker cannot modify the request (the plain text version of it), as he can with web applications.

So, to wrap up this already long diary always assess risk properly and do not accept results of automated scanners blindly. While the POODLE vulnerability is indeed a severe and critical vulnerability, and we should move to TLS (v1.2 if possible), the migration should be staged and carefully planned.

--
Bojan
@bojanz
INFIGO IS

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Why patch management is ALSO REQUIRED in ICS infrastructure, (Wed, Jan 7th)

Wed, 01/07/2015 - 21:32

Security patch management is a delicate issue in critical infrastructure. This is caused for the specific configuration, operating system version and related software required by the ICS platform. Most support contracts states that any modification outside the parameters stated by the manufacturer will void the relation and release manufacturer and seller from any responsibility about malfunction and any consequence on the industrial process.

Unfortunately, when we talk about ICS software running on windows the restriction is often applied to domain controllers as well. The case I will cover on the present diary is about an incident on a Water ICS system controlled by Emerson Open Enterprise installation and how all the servers located in the domain got modified their attributes on the domain controller without being able to tell what changes were executed.

Before this incident happened, all domain controllers and servers were configured to log the required security events to Arcsight. Now we need to find out which of the billions of logs we need to search. For this installation, we are talking about 3000 events per second. The incident began when the Open Enterprise HMI System began to loose readings from all the RTUs and after a couple of minutes it was unable to send commands to any RTU.

Since we are talking here about Windows Server 2012R2, There is an interesting repository were all event IDs for Windows 8 and Windows 2012 can be located. After looking inside the repository, the following events are interesting for searching inside the arcsight database:

Category Subcategory Event ID Message Summary DS Access Directory Service Changes 5136 A directory service object was modified. DS Access Directory Service Changes 5137 A directory service object was created. DS Access Directory Service Changes 5138 A directory service object was undeleted. DS Access Directory Service Changes 5139 A directory service object was moved. DS Access Directory Service Changes 5141 A directory service object was deleted.

Event ID 5136 states that the attribute field must be filled with the information changed for the specific object. Check the following evidence collected:

Log Name: SecuritySource: Microsoft-Windows-Security-AuditingDate: 23/11/2014 1:30:42 PMEvent ID: 5136Task Category: Directory Service ChangesLevel: InformationKeywords: Audit SuccessUser: N/AComputer: DC.Domain.comDescription:A directory service object was modified. Subject: Security ID: Domain\Administrator Account Name: Administrator Account Domain: Domain Logon ID: 0x5f8a3Directory Service: Name: Domain.local Type: Active Directory Domain Services Object: DN: CN=XXXXXXX,OU=XXXXX,DC=Domain,DC=Com GUID: CN=XXXXX,OU=XXXXX,DC=Domain,DC=Com Class: XXXXX Attribute: XXXXXXXXXXX: YYYYYYYY Syntax (OID): X.X.X.X Value: ZZZZZZZZZZZZZZ Operation: Type: Value Deleted Correlation ID: {ba5fa2fe-9a61-12fa-1b95-3bf03643b4e2}">For some reason, the attribute field was missing and we could not know what attributes were deleted. After researching on this issue, we found it">Want to implement patch management in your organization? Check the specific NIST guide for more information.

Manuel Humberto Santander Pelez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Thursday, January 8th 2015 http://isc.sans.edu/podcastdetail.html?id=4303, (Thu, Jan 8th)

Wed, 01/07/2015 - 16:58
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

A Packet a Day: ICMPv6 Type 1 Code 5, (Wed, Jan 7th)

Wed, 01/07/2015 - 16:21

One of the exercises I keep recommending is to take 5 minutes of traffic form your own network (any network...), and try to explain each packet. Being an eat your own dogfood kind of guy, I try to do this myself every so often, and yesterday, after setting up a new IPv6 connection, I came across this neat packet:

IP6 2601:aaaa:bbbb:cccc:1122:33ff:fe44:5566 2601:aaaa:bbbb:xxxx:1122:3344:5566:7788: ICMP6, destination unreachable, unknown unreach code (5)

If tcpdump calls an ICMP type Unknown, things certainly get interesting. If it is IPv6, then that becomes outright exciting and makes you dive for the RFCs. So whats is happening here?

In the end, it is a simple invalidconfiguration, but something you may find in IPv6 quite commonly. My ISP assigns me an IPv6 prefix via DHCPv6. DHCPv6 has a special feature to do so:Prefix Delegation (often abbreviatedPD). In my case, my DHCP client died. Turns out, that as soon as I no longer request the particular prefix, my modemdecided that the prefix is no longer mine, and itno longer routed it. Now in IPv4, there is no well defined ICMP message that is sent back if you essentially try to spoof a source IP that doesnt belong to you. Maybe an admin prohibited? In IPv6, we got a specific ICMPv6 code, 5, to indicate what is happening.

Type 1 is used for unreachable, similar to 3 in ICMPv4. Code 5 is defined in RFC 4443 as Source address failed ingress/egress policy. This certainly helped me figure out what is going on here.

Here is a quick list of the codes defined for type 1 in RFC 4443:

Code Message 0 No route 1 Admin Prohibited 2 Beyond scope of source address (e.g. a link local address used to reach a global address) 3 Address unreachable 4 Port unreachable 5 ingress/egree policy fail 6

reject route to destination (trying to use a router that doesnt route to that destination)

Again, this is all for type 1. Code 5 and 6 are described as subtypes of 1 (Admin Prohibited)

As a quick tcpdump filter, you have to use icmp6 and ip[40:2]=0x0105. tcpdump does not support icmp6 offsets at this point.

[1]https://tools.ietf.org/html/rfc4443

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Wednesday, January 7th 2015 http://isc.sans.edu/podcastdetail.html?id=4301, (Wed, Jan 7th)

Tue, 01/06/2015 - 18:45
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Please Take Part In Our Annual Stormcast Survey https://www.surveymonkey.com/s/KSVJXFP, (Wed, Jan 7th)

Tue, 01/06/2015 - 18:38

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Tuesday, January 6th 2015 http://isc.sans.edu/podcastdetail.html?id=4297, (Tue, Jan 6th)

Mon, 01/05/2015 - 19:16
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Tuesday, January 6th 2015 http://isc.sans.edu/podcastdetail.html?id=4297, (Tue, Jan 6th)

Mon, 01/05/2015 - 19:16
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

The argument for moving SSH off port 22, (Mon, Jan 5th)

Mon, 01/05/2015 - 16:08

An interesting discussion is occurring on reddit on whether Secure Shell (SSH) should be deployed on a port other than 22 to reduce the likelihood of being compromised. One interesting comment is that security by obscurity is not a security measure, but a way to delay the attacker, so it provides little value. While it is true that it is difficult to stop a determined attacker who is targettingyou, any measure that stops the random script kiddies and scanners from poking at your SSH is not completely useless.

The truth is that I have been deploying SSH on non-standard ports (typically 52222) for more than 15 years on the Internet facing servers I manage. Of course this is not the only security measure I employ. use hosts.allow where practical, keys and passphrases instead of passwords, and deploy DenyHosts. Do I deploy on a non-standard port because of the security advantages to be had by security by obscurity? Not at all! I deploy SSH on a non-standard port because it eliminates all the noise that is every present on port 22. The continual scanning and attempted brute forcing of SSH that has been on the Internet since the beginning of time, and seems to get worse every year, generates a lot of noise in the logs and is at best a nuisance and at worst service affecting for the server. Why put up with it if you dont have to?

It decreases the volume so much that I often have to test my defenses to be sure they are working.

Opinions?

-- Rick WannerMSISE- rwanner at isc dot sans dot edu- http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts