SIM Card Cloning

Hacking 2012. 7. 4. 13:23

LUCKNOW: Next time if you get a missed call starting with +92; #90 or #09, don't show the courtesy of calling back. BSNL has issued alerts to subscribers — particularly about the series mentioned above — saying that calling the number back after a missed call may make a user susceptible to SIM card cloning. There is, however, confusion over this claim made by some BSNL and intelligence officials. Cloning a SIM card requires physical access to it or the interception of the communication between the caller and his or her cellphone operator's network.

It is said that one lakh subscribers have fallen prey to this scam. Intelligence agencies too are said to have confirmed to the service providers particularly in the UP West telecom division that such a racket is going on and the menace is growing fast. "We are sure there must be some more similar combinations that the miscreants are using to clone the handsets, including SIM, and all the information stored in them," an intelligence officer told TOI. (This claim made by this intelligence official seems implausible, or nearly impossible.)

General manager of BSNL, RV Verma, said the department had already issued alerts to all the broadband subscribers and now alerts were being SMSed to other subscribers as well.

Anyone can clone a SIM card by using a hardware tool that can read and copy information from it. But wirelessly or remotely intercepting information contained within the SIM, though theoretically possible, is considered extremely difficult. It may require hacking into the telecom operator's network or using very expensive tools. An article on eHow, a website that explains how users can performs various tasks using several gadgets, says that the SIM can be cloned using a cheap hardware tool that can extract the authentication key from one SIM and copy it to another. But it doesn't mention any method that can make use of missed calls to clone a SIM.

"It usually starts with a missed call from a number starting with +92. In case the subscriber takes the call before it is dropped as a missed call then the caller on the other end poses as a call center executive checking the connectivity. The caller then asks the subscriber to press # 09 or # 90 call back on his number to establish that the connectivity to the subscriber was seamless," says a victim who reported the matter to the BSNL office at Moradabad last week. "The moment I redialled the caller number, my account balance lost a sum of money. Thereafter, in the three days that followed every time I got my cell phone recharged, the balance would be reduced to single digits within the next few minutes," she told the BSNL officials.

'Hacking' 카테고리의 다른 글

Understanding the iOS Security Architecture (0)	2012.08.08
Cydia Repositories (7)	2012.08.05
DNS Vuln. (1)	2012.06.15
Employers on track to get more nosey with employees' social media lives (1)	2012.06.01
How to Keep Your AWS Credentials on an EC2 Instance Securely (0)	2012.01.28

Posted by CEOinIRVINE

DNS Vuln.

Hacking 2012. 6. 15. 01:53

Allow Both TCP and UDP Port 53 to Your DNS Servers

DNS queries are getting bigger so we do not want to accidentally block them

By Scott Hogg on Sun, 08/22/10 - 7:44pm.

. What's this?

Security practitioners for decades have advised people to limit DNS queries against their DNS servers to only use UDP port 53. The reality is that DNS queries can also use TCP port 53 if UDP port 53 is not accepted. Now with the impending deployment of DNSSEC and the eventual addition of IPv6 we will need to allow our firewalls for forward both TCP and UDP port 53 packets.

DNS can be used by attackers as one of their reconnaissance techniques. Public information contained a target's servers is valuable to an attacker and helps them focus their attacks. Attackers can use a variety of techniques to retrieve DNS information through queries. However, hackers often try to perform a zone transfer from your authoritative DNS servers to gain access to even more information. You can use the dig command to gather information from a server for a specific zone file.
dig @192.168.11.24 example.org -t AXFR

Zone transfers take place over TCP port 53 and in order to prevent our DNS servers from divulging critical information to attackers, TCP port 53 is typically blocked. If the organization's firewall protecting the authoritative DNS server allowed the TCP port 53 packets and the DNS server was configured to allow zone transfers to anyone, then this dig command would be successful. However, most organizations have configured their DNS servers to prevent zone transfers from unintended DNS servers. This can be configured in the BIND zone file using any one of these forms of the allow-transfer command as shown below.
allow-transfer {"none";};
allow-transfer { address_match_list };
allow-transfer {192.168.11.11;};
Furthermore, most organizations have also used firewalls to block TCP port 53 to and from their DNS servers and the Internet. This is double-protection in case the DNS server accidentally allowed transfers.

Configuring your DNS servers to permit zone transfers to only legitimate DNS servers has always been and continues to be a best practice. However, the practice of denying TCP port 53 to and from DNS servers is starting to cause some problems. There are two good reasons that we would want to allow both TCP and UDP port 53 connections to our DNS servers. One is DNSSEC and the second is IPv6.

DNSSEC Creates Larger DNS Responses
I love reading The IP Journal and have read it since the first issue in 1998.

In the recent edition of the IP Journal there was an article by a friend of mine, Stephan Lagerholm, of Secure64 and the Texas IPv6 Task Force, titled "Operational Challenges When Implementing DNSSEC". This article covered many of the caveats that organizations run into as they move to deploy DNSSEC.
One of the key issues mentioned is that DNSSEC can cause DNS replies to be larger than 512 bytes. DNSSEC (Defined in RFC 4033, RFC 4034, and RFC 4035) requires the ability to transmit larger DNS messages because of the extra key information contained in the query responses. TCP port 53 can be used in the cases where the DNS responses greater than 512 bytes. However, using UDP messages are preferable to using TCP for large DNS messages is due to the fact that TCP connections can consume computing resources for each connection. DNS servers get numerous connections per second and using TCP can add too much overhead. To address this issue, the IETF RFC 2671 "Extension Mechanisms for DNS (EDNS0)" defines a method to extend the UDP buffer size to 4096 bytes to allow for DNSSEC and larger query responses. To enable EDNS0 on your BIND 9 configuration you can use the following BIND operations statement
edns-udp-size 4096 ;

Awareness of DNSSEC has increased due to the vulnerabilities disclosed 2 years ago and with recent news about the U.S government striving to implement it. Many organizations have been planning their DNSSEC deployments. DNSSEC is becoming more widely deployed now that key Top Level Domains (TLDs) are being signed. The TLD .org has now been signed. The Internet's root zone was signed just 2 months ago in a ceremony in Virginia. VeriSign has stated their desire to support DNSSEC for .com and .net by 2011. Comcast has created a DNSSEC Information Center site that can help you keep up to date on the latest DNSSEC status.

So as the world transitions to DNSSEC, your organization may not necessarily be using it yourself for your own authoritative DNS servers. However, your name servers may be requesting DNSSEC information even though it is not configured to serve up DNSSEC records. You may encounter problems if your resolvers are starting to encounter DNSSEC information and only able to receive UDP packets of 512 bytes or smaller. If your firewall is blocking TCP port 53 DNS messages or UDP port 53 messages using EDNS0, then you may encounter problems even if you haven't deployed DNSSEC yourself.

IPv6 DNS Lookups May be Larger Than 512 Bytes
We all know that IPv6 addresses are four times larger than IPv4 addresses. A standard A-record query response easily fits within the 512 byte UDP limit and so does a standard AAAA-record query response. A standard AAAA-record query response is about 100 bytes. However, it is conceivable that with CNAMEs, glue records, and other data that may accompany a DNS response that it could exceed the UDP 512 byte limit. Therefore, allowing TCP port 53 or enabling EDNS0 is also a requirement for IPv6 communications. This is also the case if you are doing DNS queries for IPv6 names and addresses using the IPv4 protocol to communicate with the DNS servers.

One advantage of using IPv6 is that the vast majority of systems will use aggregatable global unicast addresses. Therefore, there will not be any needs for NAT. DNSSEC has not been compatible with NAT so IPv6 offers an opportunity to use DNSSEC as it was intended to be used. One of the transition mechanisms originally developed was Network Address Translation - Protocol Translation (NAT-PT) (RFC 2766). This technique offered a rudimentary method to translate IPv4 and IPv6 packets between IPv4-only hosts and IPv6-only hosts. However, there were many reasons why NAT-PT was deprecated (RFC 4966) in the summer of 2007. One of those reasons to deprecate NAT-PT was the fact that it broke the usage of DNSSEC.

Firewalls
If a UDP port 53 response is larger than 512 bytes then it may be truncated or then DNS falls back to using TCP. However, if TCP is blocked on the firewall then the lookup can fail altogether. Your firewall may also be preventing you from using EDNS0. Therefore, you should configure your firewall to allow both TCP and UDP port 53 to and from your DNS servers as well as allow your firewall to pass larger EDNS0 packets. To accomplish this change you will have to modify your firewall's configuration parameters to enable EDNS0.

Cisco publishes a nice guide on DNS best practices that includes how to secure your DNS server configurations as well as allow for DNSSEC communications.

If you have a Cisco PIX firewall (6.3 and earlier) you may need to add this command to your configuration.
fixup protocol dns maximum-length 4096
This command will increase the firewall's DNS message length limit and allow EDNS0 messages to be forwarded.

If you have a newer software version running on your PIX or ASA then the traffic policy commands will look like this.
policy-map type inspect dns preset_dns_map
parameters
dns-guard
id-randomization
message-length maximum 4096
id-mismatch count 10 duration 2 action log
exit
match header-flag RD
drop
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
service-policy global_policy global

In order to increase the response length you need to enter these commands:
policy-map global_policy
class inspection_default
inspect dns maximum-length 4096

To view the settings use the following command:
show service-policy inspect dns

Juniper ScreenOS also allows for the increase in DNS message size using the following command.
set di service dns udp_message_limit 512 - 4096

If your firewall doesn't have a visible setting to enable EDNS0 then you may want to check with the firewall manufacturer to see if it can even support this setting. If you are concerned about how your home router/firewall may fare with the introduction of DNSSEC you can check out the test results from Nominet and Core Competence.

Testing
Once you have permitted TCP and UDP port 53 and believe that your systems are EDNS0-capable, then you must test that it is working as expected. There are several methods that you can use to test your configuration and validate if your systems are capable of handling larger DNS packets.
Domain Name System Operations Analysis and Research Center (OARC) provides tools for testing your reply size limits.

They offer a Validating Resolver.
You can use the dig utility to test your configuration.
dig +nodnssec +norec +ignore ns . @L.ROOT-SERVERS.NET
dig +dnssec +norec +ignore ns . @L.ROOT-SERVERS.NET
dig +dnssec +norec +vc any . @L.ROOT-SERVERS.NET

You can also use dig to test against the OARC DNS servers.
dig @208.67.222.222 +short rs.dns-oarc.net txt
dig @158.43.128.1 +short rs.dns-oarc.net txt

RIPE NCC also provides a method for testing your DNS query reply size. RIPE also offers a Java reply size test utility that you may find useful.

When you are testing DNS it is often helpful to have a protocol analyzer running so that you can inspect the queries and the responses. If you are using Wireshark then you can set a display filter for your captured traffic to only look at the DNS packets. This filter will look something like this.
tcp.port == 53 || udp.port == 53

You also need to check that DNS servers on the Internet can receive larger TCP DNS responses from your servers. Eventually, your DNS servers will use DNSSEC and you want those DNS resolvers in other organizations to be able to get all your DNSSEC information. Therefore, you must test your UDP and TCP port 53 traffic in both directions.

Other Issues
If you have permitted both TCP and UDP port 53 to traverse to and from your DNS servers and are still not having any luck, you may have an issue with your DNS implementation. It is conceivable that your DNS vendor has incorrectly interpreted the IETF RFCs and don't support TCP communications for DNS. There is an IETF draft called "DNS Transport over TCP - Implementation Requirements" which clarifies that "DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP". If this is the case then you should educate your vendor and then possibly consider switching to a new version of BIND, djdbns, or Secure64.

I wish you good luck deploying DNSSEC and IPv6 while using DNS over UDP and TCP port 53 with EDNS0.

Scott

'Hacking' 카테고리의 다른 글

Cydia Repositories (7)	2012.08.05
SIM Card Cloning (1)	2012.07.04
Employers on track to get more nosey with employees' social media lives (1)	2012.06.01
How to Keep Your AWS Credentials on an EC2 Instance Securely (0)	2012.01.28
HttpOnly (0)	2011.12.10

Posted by CEOinIRVINE

Employers on track to get more nosey with employees' social media lives

Hacking 2012. 6. 1. 01:28

By 2015, 60 percent of employers are likely to be eavesdropping on our social media selves to make sure our e-blabbing isn't poking security holes into their outfits, Gartner says.

According to Gartner's predictions, published on Tuesday in a report entitled "Conduct Digital Surveillance Ethically and Legally: 2012 Update", employers that are now only monitoring their brands and their marketing are going to broaden their foci to include tracking employees' social media doings as part of security monitoring.

As it is, Gartner says, less than 10 percent of organizations are currently monitoring their employees' social media activities as part of security monitoring. Instead, they're keeping an eye on security around internal infrastructure.

The cloud's going to change that, as will the Bring Your Own Device culture and the popular use of iGadgets in the workplace. As organizations' data migrate onto these technologies, security's got to follow, Gartner says.

Here's how Andrew Walls, research vice president of Gartner, put it in a press release:

Security monitoring and surveillance must follow enterprise information assets and work processes into whichever technical environments are used by employees to execute work. Given that employees with legitimate access to enterprise information assets are involved in most security violations, security monitoring must focus on employee actions and behavior wherever the employees pursue business-related interactions on digital systems. In other words, the development of effective security intelligence and control depends on the ability to capture and analyze user actions that take place inside and outside of the enterprise IT environment.

There certainly seems to be no shortage of internet usage monitoring tools. For example, here's a review site that has loads.

But here's the rub: how does an organization:

Sift through the huge volume of irrelevant social media material to find actual threats;
Keep its security staff from becoming creepy, voyeuristic stalkers; and
Avoid breaking privacy laws (which, mind you, differ from state to state and country to country)?

Here's what Wall says:

While automated, covert monitoring of computer use by staff suspected of serious policy violations can produce hard evidence of inappropriate or illegal behaviors, and guide management response, it might also violate privacy laws. In addition, user awareness of focused monitoring can be a deterrent for illicit behavior, but surveillance activities may be seen as a violation of legislation, regulations, policies or cultural expectations. There are also various laws in multiple countries that restrict the legality of interception of communications or covert monitoring of human activity.

Beyond that, how are employees going to feel about all this monitoring?

My guess is they're going to start paying a lot more attention to privacy controls in social media, as well as the intricacies of what's legal for their employers to do.

If you're curious to know whether your employer can covertly and legally sift through your activity, say, by reading your encrypted email messages, a good resource is the Privacy Rights Clearinghouse's fact sheet on workplace privacy and employee monitoring.

As far as whether or not we can be fired over what we post on social media sites, the PRC says it depends on your employer's policies and your state's law.

A few helpful snippets from PRC on that matter:

Many companies have social media policies that limit what you can and cannot post on social networking sites about your employer. A website called Compliance Building has a database of social media policies for hundreds of companies. You should ask your supervisor or human resources department what the policy is for your company.

Some states, including California, Colorado, Connecticut, North Dakota and New York, have laws that prohibit employers from disciplining an employee based on off-duty activity on social networking sites, unless the activity can be shown to damage the company in some way. In general, posts that are work-related have the potential to cause the company damage.

"There is no federal law that we are aware of that an employer is breaking by monitoring employees on social networking sites. In fact, employers can even hire third-party companies to monitor online employee activity for them.

True that. In fact, as the PRC points out, in March 2010 a company called Teneros launched the "Social Sentry" service to track online activity of employees across social networking sites.

Interestingly enough, that service isn't available anymore. That might have something to do with cultural expectations about privacy.

Those expectations are reflected in some of the headlines that greeted Social Sentry's release: "Sayonara, Social Sentry: Bosses Can Spy for Free With Web Tools", "Teneros Blows a Chill over Social Networks", and "Big Brother is Indeed Watching You: The Spy Side of Social".

I would feel sorry for privacy-deprived employees, but you guys are, evidently, security poison.

It's like CIO reported on Wednesday: at Infosecurity London last month, attendees rated employees scarier when it comes to security than hackers, consultants, third parties, or domestic or foreign government agencies.

In other words, 71 percent of 300 polled attendees said that the people creeping around their own hallways were their biggest data breach threats. Bigger than domestic or foreign government agencies, bigger than Anonymous.

Network security risks from employees are pretty easy to grasp - employees could open a malware-containing email, act carelessly with company trade secrets or intellectual property, or bring insecure devices into the workplace.

Likewise, employees on social media can give away trade secrets or simply act like unprofessional idiots and thereby embarrass their employers. They can also click on scams in Facebook.

Should employers monitor their employees' social media use? It's hard to say no, given the potential security risks of social media.

But as we move toward workplaces with ever more pervasive surveillance, I'd suggest that organizations take the time to study the privacy laws. Those laws continue to evolve. You might be within your rights today but seen as a leering Big Brother tomorrow.

'Hacking' 카테고리의 다른 글

SIM Card Cloning (1)	2012.07.04
DNS Vuln. (1)	2012.06.15
How to Keep Your AWS Credentials on an EC2 Instance Securely (0)	2012.01.28
HttpOnly (0)	2011.12.10
Security Advisory (1)	2011.12.05

Posted by CEOinIRVINE

◀ 이전페이지 1 ··· 14 15 16 17 18 19 20 ··· 761 다음페이지 ▶

Information Security & US & Life & Love & Fashion & Hacking & Passion

SIM Card Cloning

'Hacking' 카테고리의 다른 글

DNS Vuln.

Allow Both TCP and UDP Port 53 to Your DNS Servers

DNS queries are getting bigger so we do not want to accidentally block them

'Hacking' 카테고리의 다른 글

Employers on track to get more nosey with employees' social media lives

'Hacking' 카테고리의 다른 글

최근에 올라온 글

공지사항

카테고리

태그목록

달력

링크

최근에 달린 댓글

최근에 받은 트랙백

글 보관함

티스토리툴바