Red Hat has pushed out another rev of its Linux variant. With Enterprise Linux 5.5, support for the latest processors from Advanced Micro Devices, Intel, and IBM has been back-ported to the Linux 2.6.18 at the heart of the RHEL 5 stack.
According to Tm Burke, vice president of platform engineering at Red Hat, the kernel in RHEL 5.5 has been improved, and it now includes features from more current Linux kernels, so it's not particularly fair to call it Linux 2.6.18. The point is that any application that was certified to run on Linux 2.6.18 or later, possibly many years ago, will work on RHEL 5.5 and still have support for new hardware like the Power7 processors from IBM that debuted back in February, the "Westmere-EP" Xeon 5600s from Intel that came out two weeks ago, the "Magny-Cours" Opteron 6100s from AMD that launched earlier this week, and the "Nehalem-EX" Xeon 7500s that were announced yesterday.
Because machines based on the Opteron 6100s, Xeon 7500, and Power7 processors all use a form of non-uniform memory access (NUMA) memory sharing across multiple processor sockets and also have multiple cores and caches inside sockets, RHEL 5.5 includes a lot of work that makes the operating system very aware of the system topology so memory allocation and job scheduling is done such that instruction streams and their data are placed as close together as possible. The kernel also has tweaks that try to cram as much work on as few cores as possible, allowing for servers to conserve power as they dial down or quiesce cores in the systems.
The updated RHEL also has a lot of I/O optimizations to take advantage of virtual I/O hardware features in the most current x64 and Power processors, which cuts down on I/O overhead in virtualized environments. In I/O-heavy virtualized workloads where the I/O was virtualized in software, rather than on the chip, the I/O overhead could be as high as 30 per cent, which is unacceptable.
Burke says that with these tweaks for I/O virtualization, which include a feature called Single Root I/O Virtualization (SR-IOV), a guest operating system running inside either a Xen or KVM hypervisor embedded in RHEL 5.5 can drive a 10 Gigabit Ethernet adapter card to its saturation point, and Burke claims this is the only hypervisor environment today that can do this. (That won't last for long, with RHEL being open source).
While the freestanding KVM hypervisor at the heart of the Red Hat Enterprise Virtualization, or RHEV, product was updated with a beta of its own 2.2 release using the RHEL 5.5 kernel earlier this week, RHEL 5.5 is available today and supports fatter guest virtual machines. The RHEV 2.2 beta can support 16 virtual CPUs and up to 256 GB of memory per guest, but RHEL 5.5 can support 32 physical processor cores and up to 512 GB of memory on either a Xen or KVM guest.
The bare-metal RHEL 5.5 kernel can support up to 1 TB of physical memory and can support well beyond the current top-end 64 sockets delivered today in eight-way Xeon 7500 systems. The open source community has already figured out how to do 512-core NUMA systems for the Itanium chips and is leveraging this work as x64 architectures get fatter. The RHEL 5 kernel has a stunning theoretical maximum of 32,000 threads that it can support, which is well beyond anything any server maker can put into the field in a single system image. Later this year, IBM's top-end Power 795 systems will have 32 sockets with a total of 256 cores and 1,024 threads.
The largest general-purpose Xeon 7500 machines will have maybe 64-sockets, which means 512 cores and 1,024 threads, and it looks like Itanium 9300 machines will probably top out at 64 sockets as well, but those quad-core chips only have eight threads, so that's a maximum of 512 threads. AMD is topped out at 40 threads in four-socket boxes with the Opteron 6100s. That will barely tickle the limits of RHEL 5.5.
By the way, RHEL 4 is not getting support for all this new iron, since Red Hat stopped doing major backporting to this early RHEL version six months ago. At some point, says Burke, the changes that would be necessary make new hardware work on the older versions without breaking application compatibility would involve way too much work or not be possible at all.
In general, a RHEL version gets three years of cutting-edge hardware support (roughly updated every six months), one year of transitional support where major hardware enablement and driver work is done, but perhaps not the greatest amount of tuning, and then three years where the version is in maintenance mode, with bug fixes and security patches. The expectation is that RHEL 5 will have a couple more years of hardware maintenance, but it really depends on how radical the hardware changes are in the future. If the changes are too radical, RHEL 5 gets sent to pasture sooner.
In addition to the updated hardware support, RHEL 5.5 has pulled in OpenOffice 3.1, which has better compatibility with Microsoft's Office 2007 formats, and the Samba print and file server has been updated to work with Windows 7. The SystemTap dynamic tracing tool that is part of the development stack in RHEL has also been enhanced so it can probe and poke C++ applications, rather than just C apps. The GDB debugger also has better support for C++ applications in that it allows developers to debug one thread at a time instead of having to suspend all threads in C++ code at the same time.
Showing posts with label hacker. Show all posts
Showing posts with label hacker. Show all posts
Friday, April 2, 2010
Hacker's record credit card theft fetches 20-year sentence
Confessed TJX hacker Albert Gonzalez was sentenced to 20 years in federal prison for orchestrating one of the largest thefts of payment card numbers in history.
The sentence, by US District Court Judge Patti Saris, is the lengthiest to be imposed in a US hacking or identity prosecution. Miami-based Gonzalez was also fined $25,000 and still faces restitution charges that could be in the tens of millions of dollars.
Prosecutors told the judge Gonzalez should receive 25 years because he victimized millions of people and cost banks and their insurers as much as $200m. His attorney, Martin Weinberg, challenged that estimate and presented evidence his client suffered from Asperger's Syndrome, a form of autism.
Last year, Gonzalez pleaded guilty in three separate cases brought in Massachusetts, New Jersey and New York. Thursday's sentence in Boston dealt only with the Massachusetts case. A hearing scheduled for Friday will deal with the other two prosecutions.
Prosecutors said Gonzalez led a gang of hackers who conducted war-driving campaigns that identified retailers with weak wireless networks. They then penetrated those networks and installed sniffer programs that siphoned millions of credit and debit card numbers as they were being zapped to payment processors.
The operation targeted a variety of retailers and restaurants including TJX Cos. and BJ's Wholesale Club, Office Max, Barnes & Noble and Dave & Busters restaurant chain. Thursday's sentence came the same day Dave & Busters agreed to implement a comprehensive security program to settle US Federal Trade Commission charges the restaurant left consumers vulnerable to credit card thieves.
source : theregister.co.uk
The sentence, by US District Court Judge Patti Saris, is the lengthiest to be imposed in a US hacking or identity prosecution. Miami-based Gonzalez was also fined $25,000 and still faces restitution charges that could be in the tens of millions of dollars.
Prosecutors told the judge Gonzalez should receive 25 years because he victimized millions of people and cost banks and their insurers as much as $200m. His attorney, Martin Weinberg, challenged that estimate and presented evidence his client suffered from Asperger's Syndrome, a form of autism.
Last year, Gonzalez pleaded guilty in three separate cases brought in Massachusetts, New Jersey and New York. Thursday's sentence in Boston dealt only with the Massachusetts case. A hearing scheduled for Friday will deal with the other two prosecutions.
Prosecutors said Gonzalez led a gang of hackers who conducted war-driving campaigns that identified retailers with weak wireless networks. They then penetrated those networks and installed sniffer programs that siphoned millions of credit and debit card numbers as they were being zapped to payment processors.
The operation targeted a variety of retailers and restaurants including TJX Cos. and BJ's Wholesale Club, Office Max, Barnes & Noble and Dave & Busters restaurant chain. Thursday's sentence came the same day Dave & Busters agreed to implement a comprehensive security program to settle US Federal Trade Commission charges the restaurant left consumers vulnerable to credit card thieves.
source : theregister.co.uk
Hackers hit where they live
The countries of hackers originating malware-laced spam runs have been exposed by new research, which confirms they are often located thousands of miles away from the compromised systems they use to send out junk mail.
A third of targeted malware attacks sent so far in March came from the United States (36.6 per cent), based on mail server location. However, after the sender's actual location is analysed, more targeted attacks actually began in China (28.2 per cent) and Romania (21.1 per cent) than the US (13.8 percent), according to the March 2010 edition of the monthly MessageLabs security report.
Paul Wood, MessageLabs intelligence senior analyst, explained the discrepancy: “A large proportion of targeted attacks are sent from legitimate webmail accounts which are located in the US and therefore, the IP address of the sending mail server is not a useful indicator of the true origin of the attack.
"Analysis of the sender’s IP address, rather than the IP address of the email server, reveals the true source of these targeted attacks.”
Further analysis of targeted attacks shows people at the sharp end of targeted malware attacks are responsible for foreign trade and defence policy, especially in relation to Asian countries. Virus activity in Taiwan was one in 90.9 emails, making it the most targeted country for email-borne malware in March. By comparison, one in 552 emails sent to US mailboxes came laced with malware.
Meanwhile, one in 77.1 emails sent to public sector mailboxes were blocked as malicious by MessageLabs.
The worldwide ratio of email-borne viruses to regular email traffic was one in 358.3 emails (0.28 per cent) in March, an decrease of 0.05 percentage points since February. In March 16.8 percent of email-borne malware contained links to malicious websites, a big decrease of 13.7 percentage points since February.
Spam rates after connections to known black spots were taken out of the picture reached 90.7 per cent, an increase of 1.5 percentage points since February. The vast majority of these junk mail messages came from compromised malware-infested networks of zombie PCs (aka botnets) MessageLabs reports that 77 per cent of spam sent from the Rustock botnet this month used secure TLS connections.
The average additional inbound and outbound traffic due to TLS requires an overhead of around 1KB, smaller than the average size of spam emails, and putting an added strain on already pressured email servers. Spam sent using TLS accounted for approximately 20 per cent of all junk mail so far in March, peaking at 35 per cent on March 10.
“TLS is a popular way of sending email through an encrypted channel," Wood said. “However, it uses far more server resources and is much slower than plain-text email and requires both inbound and outbound traffic. The outbound traffic frequently outweighs the size of the spam message itself and can significantly tax the workload on corporate email servers.”
source : theregister.co.uk
A third of targeted malware attacks sent so far in March came from the United States (36.6 per cent), based on mail server location. However, after the sender's actual location is analysed, more targeted attacks actually began in China (28.2 per cent) and Romania (21.1 per cent) than the US (13.8 percent), according to the March 2010 edition of the monthly MessageLabs security report.
Paul Wood, MessageLabs intelligence senior analyst, explained the discrepancy: “A large proportion of targeted attacks are sent from legitimate webmail accounts which are located in the US and therefore, the IP address of the sending mail server is not a useful indicator of the true origin of the attack.
"Analysis of the sender’s IP address, rather than the IP address of the email server, reveals the true source of these targeted attacks.”
Further analysis of targeted attacks shows people at the sharp end of targeted malware attacks are responsible for foreign trade and defence policy, especially in relation to Asian countries. Virus activity in Taiwan was one in 90.9 emails, making it the most targeted country for email-borne malware in March. By comparison, one in 552 emails sent to US mailboxes came laced with malware.
Meanwhile, one in 77.1 emails sent to public sector mailboxes were blocked as malicious by MessageLabs.
The worldwide ratio of email-borne viruses to regular email traffic was one in 358.3 emails (0.28 per cent) in March, an decrease of 0.05 percentage points since February. In March 16.8 percent of email-borne malware contained links to malicious websites, a big decrease of 13.7 percentage points since February.
Spam rates after connections to known black spots were taken out of the picture reached 90.7 per cent, an increase of 1.5 percentage points since February. The vast majority of these junk mail messages came from compromised malware-infested networks of zombie PCs (aka botnets) MessageLabs reports that 77 per cent of spam sent from the Rustock botnet this month used secure TLS connections.
The average additional inbound and outbound traffic due to TLS requires an overhead of around 1KB, smaller than the average size of spam emails, and putting an added strain on already pressured email servers. Spam sent using TLS accounted for approximately 20 per cent of all junk mail so far in March, peaking at 35 per cent on March 10.
“TLS is a popular way of sending email through an encrypted channel," Wood said. “However, it uses far more server resources and is much slower than plain-text email and requires both inbound and outbound traffic. The outbound traffic frequently outweighs the size of the spam message itself and can significantly tax the workload on corporate email servers.”
source : theregister.co.uk
Microscope-wielding boffins crack cordless phone crypto DECT vivisection
Cryptographers have broken the proprietary encryption used to prevent eavesdropping on more than 800 million cordless phones worldwide, demonstrating once again the risks of relying on obscure technologies to remain secure.
The attack is the first to crack the cipher at the heart of the DECT, or Digital Enhanced Cordless Telecommunications, standard, which encrypts radio signals as they travel between cordless phones in homes and businesses and corresponding base stations. A previous hack, by contrast, merely exploited weaknesses in the way the algorithm was implemented.
The fatal flaw in the DECT Standard Cipher is its insufficient amount of "pre-ciphering," which is the encryption equivalent of shaking a cup of dice to make sure they generate unpredictable results. Because the algorithm discards only the first 40 or 80 bits during the encryption process, it's possible to deduce the secret key after collecting and analyzing enough of the protected conversation.
"This standard, as with everything else we have broken, has been designed some 20 years ago, and it is proprietary encryption," said Karsten Nohl, one of the cryptographers who helped devise the attack. "It relied on the fact that the encryption was unknown and hence could not be broken. This is a case where something that has some potential for being strong is broken by just this one design decision that in any public review would have been spotted immediately."
Nohl, 28, is the same University of Virginia microscope-wielding reverse engineer to crack the encryption in the world's most widely used smartcard. In December, he struck again after devising a practical attack for eavesdropping on cellphone calls.
He and fellow researchers Erik Tews of the Darmstadt University of Technology and Ralf-Philipp Weinmann of the University of Luxembourg, plan to present their findings Monday at the 2010 Fast Software Encryption workshop in Korea.
Like several of Nohl's previous hacks, it began with nitric acid and an electron optical microscope. After dissolving away the epoxy on the silicon chip and then shaving down and magnifying the section dedicated to the DECT encryption, he was able to glean key insights into the underlying algorithm. He then compared the findings against details selectively laid out in a patent and exposed during a debug process.
The results of all three probe methods revealed the fatally insufficient amount of pre-ciphering in the DECT Standard Cipher.
In practical terms, the attack works by collecting bits of the encrypted data stream with known unencrypted contents. In cordless phones, this often comes from a device's control channel, which broadcasts a variety of predictable data, including call duration and button responses. Sniffing an encrypted conversation with a USRP antenna and the average PC, an attacker would need to collect about four hours of data to break the key in typical scenarios.
In others - such as where DECT is used in restaurants and bars to wirelessly zap payment card details - the time needed to crack the key could be dramatically shorter, Nohl said. The time can also be sped up in a variety of other ways, including by adding certain types of graphics cards to beef up the power of the attacking PC. In some cases, the attack can retrieve the secret key in 10 minutes.
"We expect that some smarter cryptographers than ourselves will find better attacks, of course," Nohl told El Reg. "We found the algorithm and then implemented the first attack. It's almost guaranteed that this is not the best attack."
The DECT Forum, the international body that oversees the standard, said it takes the attack scenarios laid out in the paper seriously and "continues to investigate their applicability."
The crack of DECT is only the latest time Nohl has defeated the proprietary encryption of a device with critical mass. His 2008 attack on the Mifare Classic smartcard used similar techniques of filing down a silicon chip and then tracing the connections between transistors. His proposed attack of GSM encryption affects cellphones used by more than 800 carriers in 219 countries.
The attack is the first to crack the cipher at the heart of the DECT, or Digital Enhanced Cordless Telecommunications, standard, which encrypts radio signals as they travel between cordless phones in homes and businesses and corresponding base stations. A previous hack, by contrast, merely exploited weaknesses in the way the algorithm was implemented.
The fatal flaw in the DECT Standard Cipher is its insufficient amount of "pre-ciphering," which is the encryption equivalent of shaking a cup of dice to make sure they generate unpredictable results. Because the algorithm discards only the first 40 or 80 bits during the encryption process, it's possible to deduce the secret key after collecting and analyzing enough of the protected conversation.
"This standard, as with everything else we have broken, has been designed some 20 years ago, and it is proprietary encryption," said Karsten Nohl, one of the cryptographers who helped devise the attack. "It relied on the fact that the encryption was unknown and hence could not be broken. This is a case where something that has some potential for being strong is broken by just this one design decision that in any public review would have been spotted immediately."
Nohl, 28, is the same University of Virginia microscope-wielding reverse engineer to crack the encryption in the world's most widely used smartcard. In December, he struck again after devising a practical attack for eavesdropping on cellphone calls.
He and fellow researchers Erik Tews of the Darmstadt University of Technology and Ralf-Philipp Weinmann of the University of Luxembourg, plan to present their findings Monday at the 2010 Fast Software Encryption workshop in Korea.
Like several of Nohl's previous hacks, it began with nitric acid and an electron optical microscope. After dissolving away the epoxy on the silicon chip and then shaving down and magnifying the section dedicated to the DECT encryption, he was able to glean key insights into the underlying algorithm. He then compared the findings against details selectively laid out in a patent and exposed during a debug process.
The results of all three probe methods revealed the fatally insufficient amount of pre-ciphering in the DECT Standard Cipher.
In practical terms, the attack works by collecting bits of the encrypted data stream with known unencrypted contents. In cordless phones, this often comes from a device's control channel, which broadcasts a variety of predictable data, including call duration and button responses. Sniffing an encrypted conversation with a USRP antenna and the average PC, an attacker would need to collect about four hours of data to break the key in typical scenarios.
In others - such as where DECT is used in restaurants and bars to wirelessly zap payment card details - the time needed to crack the key could be dramatically shorter, Nohl said. The time can also be sped up in a variety of other ways, including by adding certain types of graphics cards to beef up the power of the attacking PC. In some cases, the attack can retrieve the secret key in 10 minutes.
"We expect that some smarter cryptographers than ourselves will find better attacks, of course," Nohl told El Reg. "We found the algorithm and then implemented the first attack. It's almost guaranteed that this is not the best attack."
The DECT Forum, the international body that oversees the standard, said it takes the attack scenarios laid out in the paper seriously and "continues to investigate their applicability."
The crack of DECT is only the latest time Nohl has defeated the proprietary encryption of a device with critical mass. His 2008 attack on the Mifare Classic smartcard used similar techniques of filing down a silicon chip and then tracing the connections between transistors. His proposed attack of GSM encryption affects cellphones used by more than 800 carriers in 219 countries.
Automated Scanning vs the OWASP Top Ten
The OWASP Top Ten is a list of the most critical website security flaws – a list also often used as a minimum standard for website vulnerability assessment (VA) and compliance. There is an ongoing industry dialog about the possibility of identifying the OWASP Top Ten in a purely automated fashion (scanning). People frequently ask what can and can’t be found using either white box or black box scanners. This is important because a single missed vulnerability, or more accurately exploited vulnerability, can cause an organization significant financial harm. Proper expectations must be set when it comes to the various vulnerability assessment solutions.
For our part, WhiteHat Security is in the website security business and provides a vulnerability management service. Our Sentinel Service incorporates expert analysis with proprietary scanning technology. Using a black box process, we assess hundreds of websites a month, more than anyone in the industry. What we’ve come to understand is that a significant portion of vulnerabilities are virtually impossible for scanners to find. By the same token, even the most seasoned Web security experts cannot find many issues in a reliable and consistent manner. To achieve full vulnerability coverage and therefore complete vulnerability management, we must rely on a combination and integration of both methods.
We’d like to share some of our experiences that led to this conclusion. Using situations we’ve seen in the real world, and the OWASP Top Ten as a baseline, we’ll demonstrate why scanning technology alone cannot find the OWASP Top Ten. To begin, we’ll focus on a single feature of a fictitious Web Bank responsible for funds transfers from one account to another account. Here is the full URL:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=
1000.00&session=1001
The “from_acct” is the current user’s account number. “to_acct” is where the money should be sent. “Amount” is obviously the transfer amount, and the “session” is the authenticated session ID after having properly logged-in. This is a fairly typical and straightforward business process.
Unvalidated Input
Scanners must hazard a guess about what “transfer.cgi” does. Otherwise, it would be impossible to determine what it should NOT do.
A website security expert can easily figure this out, but scanners aren’t equipped with that intelligence: There is no knowledge of or appreciation for context. For the sake of discussion, let’s say a scanner has the ability, because there’s a dollar figure present and the “transfer” keyword in the URL might help it decide that this feature moves money. Realistically, these parameter names could be anything and are often far more cryptic. To attempt a classic funds transfer attack, let’s change the above URL substituting the “1000.00” amount to “-1000.00.”
Negative Amount Example:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=-1000.00&session=1001
By transferring a negative amount, this custom Web application would potentially deduct money from the target account instead of adding to it! The challenge for a scanner is being able to decide whether or not the attack succeeded. How would it tell?
If the fraudulent transfer succeeded, the website might respond with, “Success, would you like to make another transaction?,” “Transfer will take place by 9 AM tomorrow,” “Request received, thank you,” or any number of possible affirmations. If the attack failed, “Transfer failed,” “Error: Transfer amount must be a positive number,” or, “Bank robbery detected, men with guns have been dispatched to your location!” Every custom Web Bank application will likely respond in a different manner. That’s precisely the problem! Pre-programming all the possible keyword phrases or behavioral aspects is simply unfeasible and for all mathematical provability, impossible. However, human gray matter (or, a crack website security operations team) can make this determination.
For our part, WhiteHat Security is in the website security business and provides a vulnerability management service. Our Sentinel Service incorporates expert analysis with proprietary scanning technology. Using a black box process, we assess hundreds of websites a month, more than anyone in the industry. What we’ve come to understand is that a significant portion of vulnerabilities are virtually impossible for scanners to find. By the same token, even the most seasoned Web security experts cannot find many issues in a reliable and consistent manner. To achieve full vulnerability coverage and therefore complete vulnerability management, we must rely on a combination and integration of both methods.
We’d like to share some of our experiences that led to this conclusion. Using situations we’ve seen in the real world, and the OWASP Top Ten as a baseline, we’ll demonstrate why scanning technology alone cannot find the OWASP Top Ten. To begin, we’ll focus on a single feature of a fictitious Web Bank responsible for funds transfers from one account to another account. Here is the full URL:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=
1000.00&session=1001
The “from_acct” is the current user’s account number. “to_acct” is where the money should be sent. “Amount” is obviously the transfer amount, and the “session” is the authenticated session ID after having properly logged-in. This is a fairly typical and straightforward business process.
Unvalidated Input
Scanners must hazard a guess about what “transfer.cgi” does. Otherwise, it would be impossible to determine what it should NOT do.
A website security expert can easily figure this out, but scanners aren’t equipped with that intelligence: There is no knowledge of or appreciation for context. For the sake of discussion, let’s say a scanner has the ability, because there’s a dollar figure present and the “transfer” keyword in the URL might help it decide that this feature moves money. Realistically, these parameter names could be anything and are often far more cryptic. To attempt a classic funds transfer attack, let’s change the above URL substituting the “1000.00” amount to “-1000.00.”
Negative Amount Example:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=-1000.00&session=1001
By transferring a negative amount, this custom Web application would potentially deduct money from the target account instead of adding to it! The challenge for a scanner is being able to decide whether or not the attack succeeded. How would it tell?
If the fraudulent transfer succeeded, the website might respond with, “Success, would you like to make another transaction?,” “Transfer will take place by 9 AM tomorrow,” “Request received, thank you,” or any number of possible affirmations. If the attack failed, “Transfer failed,” “Error: Transfer amount must be a positive number,” or, “Bank robbery detected, men with guns have been dispatched to your location!” Every custom Web Bank application will likely respond in a different manner. That’s precisely the problem! Pre-programming all the possible keyword phrases or behavioral aspects is simply unfeasible and for all mathematical provability, impossible. However, human gray matter (or, a crack website security operations team) can make this determination.
Automated Scanning vs the OWASP Top Ten
The OWASP Top Ten is a list of the most critical website security flaws – a list also often used as a minimum standard for website vulnerability assessment (VA) and compliance. There is an ongoing industry dialog about the possibility of identifying the OWASP Top Ten in a purely automated fashion (scanning). People frequently ask what can and can’t be found using either white box or black box scanners. This is important because a single missed vulnerability, or more accurately exploited vulnerability, can cause an organization significant financial harm. Proper expectations must be set when it comes to the various vulnerability assessment solutions.
For our part, WhiteHat Security is in the website security business and provides a vulnerability management service. Our Sentinel Service incorporates expert analysis with proprietary scanning technology. Using a black box process, we assess hundreds of websites a month, more than anyone in the industry. What we’ve come to understand is that a significant portion of vulnerabilities are virtually impossible for scanners to find. By the same token, even the most seasoned Web security experts cannot find many issues in a reliable and consistent manner. To achieve full vulnerability coverage and therefore complete vulnerability management, we must rely on a combination and integration of both methods.
We’d like to share some of our experiences that led to this conclusion. Using situations we’ve seen in the real world, and the OWASP Top Ten as a baseline, we’ll demonstrate why scanning technology alone cannot find the OWASP Top Ten. To begin, we’ll focus on a single feature of a fictitious Web Bank responsible for funds transfers from one account to another account. Here is the full URL:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=
1000.00&session=1001
The “from_acct” is the current user’s account number. “to_acct” is where the money should be sent. “Amount” is obviously the transfer amount, and the “session” is the authenticated session ID after having properly logged-in. This is a fairly typical and straightforward business process.
Unvalidated Input
Scanners must hazard a guess about what “transfer.cgi” does. Otherwise, it would be impossible to determine what it should NOT do.
A website security expert can easily figure this out, but scanners aren’t equipped with that intelligence: There is no knowledge of or appreciation for context. For the sake of discussion, let’s say a scanner has the ability, because there’s a dollar figure present and the “transfer” keyword in the URL might help it decide that this feature moves money. Realistically, these parameter names could be anything and are often far more cryptic. To attempt a classic funds transfer attack, let’s change the above URL substituting the “1000.00” amount to “-1000.00.”
Negative Amount Example:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=-1000.00&session=1001
By transferring a negative amount, this custom Web application would potentially deduct money from the target account instead of adding to it! The challenge for a scanner is being able to decide whether or not the attack succeeded. How would it tell?
If the fraudulent transfer succeeded, the website might respond with, “Success, would you like to make another transaction?,” “Transfer will take place by 9 AM tomorrow,” “Request received, thank you,” or any number of possible affirmations. If the attack failed, “Transfer failed,” “Error: Transfer amount must be a positive number,” or, “Bank robbery detected, men with guns have been dispatched to your location!” Every custom Web Bank application will likely respond in a different manner. That’s precisely the problem! Pre-programming all the possible keyword phrases or behavioral aspects is simply unfeasible and for all mathematical provability, impossible. However, human gray matter (or, a crack website security operations team) can make this determination.
For our part, WhiteHat Security is in the website security business and provides a vulnerability management service. Our Sentinel Service incorporates expert analysis with proprietary scanning technology. Using a black box process, we assess hundreds of websites a month, more than anyone in the industry. What we’ve come to understand is that a significant portion of vulnerabilities are virtually impossible for scanners to find. By the same token, even the most seasoned Web security experts cannot find many issues in a reliable and consistent manner. To achieve full vulnerability coverage and therefore complete vulnerability management, we must rely on a combination and integration of both methods.
We’d like to share some of our experiences that led to this conclusion. Using situations we’ve seen in the real world, and the OWASP Top Ten as a baseline, we’ll demonstrate why scanning technology alone cannot find the OWASP Top Ten. To begin, we’ll focus on a single feature of a fictitious Web Bank responsible for funds transfers from one account to another account. Here is the full URL:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=
1000.00&session=1001
The “from_acct” is the current user’s account number. “to_acct” is where the money should be sent. “Amount” is obviously the transfer amount, and the “session” is the authenticated session ID after having properly logged-in. This is a fairly typical and straightforward business process.
Unvalidated Input
Scanners must hazard a guess about what “transfer.cgi” does. Otherwise, it would be impossible to determine what it should NOT do.
A website security expert can easily figure this out, but scanners aren’t equipped with that intelligence: There is no knowledge of or appreciation for context. For the sake of discussion, let’s say a scanner has the ability, because there’s a dollar figure present and the “transfer” keyword in the URL might help it decide that this feature moves money. Realistically, these parameter names could be anything and are often far more cryptic. To attempt a classic funds transfer attack, let’s change the above URL substituting the “1000.00” amount to “-1000.00.”
Negative Amount Example:
http://server/transfer.cgi?from_acct=1235813&to_acct=31415&amount=-1000.00&session=1001
By transferring a negative amount, this custom Web application would potentially deduct money from the target account instead of adding to it! The challenge for a scanner is being able to decide whether or not the attack succeeded. How would it tell?
If the fraudulent transfer succeeded, the website might respond with, “Success, would you like to make another transaction?,” “Transfer will take place by 9 AM tomorrow,” “Request received, thank you,” or any number of possible affirmations. If the attack failed, “Transfer failed,” “Error: Transfer amount must be a positive number,” or, “Bank robbery detected, men with guns have been dispatched to your location!” Every custom Web Bank application will likely respond in a different manner. That’s precisely the problem! Pre-programming all the possible keyword phrases or behavioral aspects is simply unfeasible and for all mathematical provability, impossible. However, human gray matter (or, a crack website security operations team) can make this determination.
Tuesday, February 9, 2010
Social Engineering
I am writing this article, because social engineering is almost a necessity for any hacker. You would be surprised what valuable information people will give away to a complete stranger. I have not seen any articles on this topic so far, so I am going to do my best and hopefully teach you all something you did not know before.
Introduction
Social Engineering is the art of manipulating a person into revealing sensitive information. Social Engineering is the best hacking tool you can use, in my opinion. Similar to using a computer program to make another system spew out amounts of valuable information about the machine, that an attacker can later use. Think of it as "people hacking". When hacking into system you find a weakness or vulnerability that you can exploit, to gain access to restricted information. Social engineering is taking advantage of a persons weakness and getting them to disclose confidential information. All it takes is a large amount a confidence and basic knowledge of human nature and social behavior patterns. Social engineering does not just apply to computer security, it can apply to nearly any situation.
Understanding Human Nature
When it comes to social engineering there are typically only a handful of “tools” you can use. Some of which are; A basic understanding of human nature, cognitive biases, and psychological fallacies. People generally have social patterns and behaviors that can easily be exploited. Everyone has these flaws, it is a matter of finding out what works with the particular person. There are literally hundreds of these fallacies, and nearly everyone is guilty of them. This is just a few that really stand out to me. Maybe I will cover more in a future article. Some of the most popular human social patterns include:
*The Bandwagon Effect-This is the tendency to follow patterns of another persons, or a groups behavior. Generally everyone has heard the term "jump on the bandwagon", It simply means to do as others do. This particular bias plays a very important roll in social engineering and can be taken advantage of quite easily. Also known as conformity.
*Illusion of Control-This is the illusion that a human believes that they can control the outcome of certain situation, when it is clearly out of their hands. Think of someone who is gambling who believes they can really control the outcome of the numbers they roll. Some people truly believe that they can control the outcome of an event as if to predict the future. Prayer or belief in the paranormal could also be thrown into this category.
*Stereotyping-Stereotyping is judging a person by their distinguished characteristics. Everyone is clearly guilty of this at some point. Every time you meet someone for the first time, you almost always inadvertently judge them. You judge them by their clothes, their hairstyle and just their general appearance. However, stereotyping can sometimes be accurate as I will explain later on in the article.
*The Ostrich Effect-This is act of ignoring the negative situation that is going on. Think of someone that is over-optimistic about financial issues and pretending everything is fine. This particular fallacy is performed by almost anyone in a negative situation.
*Consistency bias-This is known as incorrectly remembering your past thoughts or actions in a given situation. This can be greatly taken advantage of. A new employee may not know how to answer a question, or how they answered it in the past. Therefore possibly disclosing valuable information.
Basic Techniques
You are not going to want to use every technique at once, find one that fits a particular situation and play the part well. Most social engineering can be done over the phone. It is quite simple to call up a company while imitating a person of authority and retrieving sensitive information. Help desks and customer service are very likely to this method of attack.
Be Polite
The best thing you can do is always be polite, never blow your cover by acting rude. Remember, you are sometimes taking advantage of someones good nature. So getting on their bad side is not a good start. Remember to speak up and be firm, but do not be rude. For example, call up a company you are interested in, and politely ask questions. Act as if you truly want to learn about how their system works, or what tools they use. Do not blatantly ask for something that you know is restricted information. You have to keep talking to them, while sounding knowledgeable and interested. Ask to speak to a manager, or someone in charge. Working your way up to someone that knows it all. Write down the names of employees pretend you are interested in that particular field of work, ask what type of education and things you will need to learn. The goal here is to persuade them from a psychological point of view.
Pretend to be ignorant
You obviously do not want the target to know much about you, so you want to be as discrete as possible. You do not want them to become concerned with a question you may have asked. Playing dumb is also another technique that can be used. Pretend to know nothing whatsoever and create a fake problem to ask customer service about. Keep them on the phone long enough and keep asking questions. Give them a fake name and phony problem. Ask for their name and figure out where they stand in the company. You know how annoying it is when you call a company and they keep redirecting you to someone else. They have thousands of calls each day, chances are they will not remember you. In all honesty they probably could not care less, they just want to get rid you and have someone else help you.
Be Curious, without giving it away
Write down a list of things you want to figure out with a certain phone call. Whether it be a certain name, phone number or just a piece of information that helps put together a piece of the puzzle. Ask for names, and to speak to certain people. Make sure you do your homework first and have a general knowledge about the company. If you do not know what to say beforehand you will sound like a fumbling idiot and your confidence level will decrease.
Pretending to be someone of higher authority
This applies the the bandwagon effect and also false memory. Tell a client that is lower in the chain that you are someone who you are not. Tell them you are an employee (in this case it would be a good idea to have a list of employees that you found on the company website or through the yellow pages.) Ask to speak to so and so, who is higher up in the company than she is. Tell them you need a phone number, or whatever it may be you are searching for. That is why I think it is a good idea to have a goal of what you are truly after. This method is known as reverse social engineering. This requires a bit of research and preparation to pull off, but with proper execution and very well be one of the best methods.
Other Techniques
These techniques are aimed to physical access to a specific company. Be careful with these though, they could land you in some pretty tough situations that may be harder to talk your way out of. Just remember that social engineering can be applied to nearly any given situation.
Dumpster Diving
As silly as this may sound, dumpster diving as an effective way of gaining valuable information about a company. You would be surprised what kinds of things they may have thrown away. Perhaps a trashed company computer with the hard rive still in it. Or possibly company phone books, organizational charts, memos, company policy manuals, calendars of meetings, events and vacations, system manuals, printouts of sensitive data or login names and passwords, printouts of source code, disks and tapes, company letterhead and memo forms, and outdated hardware. I will not go into great detail of how to dumpster dive, but I am sure you get the picture. Bottom line is that valuable things can be found in a company dumpster.
Tailgating
The art of following an authorized person into an area where you are not authorized. This is where your acting skills can come in handy. Pretend to be the repair man they called last week. Come ready with all your tools, hardhat white t-shirt and jeans and play the part. When really you just want physical access to something a normal civilian would not have rights to access. This technique takes some serious dedication, but in the end very much worth the effort. This requires doing your best to blend in. Maybe pretending to be just another employee on a smoke break. They will eventually finish and go back inside. That would be your cue to follow them inside, thus giving you physical access. Whatever your doing play the part, and do it with confidence.
Shoulder Surfing
Seems easy enough, right? It is as simple as it sounds, peering over someones shoulder to see what they are typing. Be careful not to get caught with this one, by making it obvious you are trying to view what they are typing. I am sure all of you have exercised some form of this at one point. I do not think I need to go into great detail on this, just be smooth about things.
People Watching
This is by far my favorite method. Keep in mind that social engineering does not always involve tricking people. Like I said before, it is all about understanding human nature. For some odd reason, I enjoy watching people. Whenever I go to a mall, airport or somewhere where I can sit down in public, I love to watch people. (In a non-rapist/stalker sort of way) I like to nonchalantly eavesdrop and just hear about their lives and what they have to say. I know you have all done it, at one time or another you have listened in on someones conversation and heard something they probably did not want you to hear. Everyone judges other people by the way they look or talk. It is one of the cognitive biases I listed called Stereotyping. A great way to practice your social engineering skills is to sit down and judge people. Not in a rude way, but try to figure out their life based on their appearance and social patterns. Pick out someone and see think about what they are wearing, what they are talking about, how they carry themselves and try to imagine what kind of life they lead.
Conclusion
This is just the tip of the iceberg when it comes to social engineering. There is much more to cover, but I hope you all learned something. Overtime you will become better at reading and understanding human nature. You will develop your own style of social engineering. There are many more methods that I left out, but these are great to start with. Knowing how to social engineer is a great way to prevent yourself from getting tricked by others. For example, the police use social engineering and forms of manipulation constantly. Others may disagree, but overall I feel this is an important topic to cover and I enjoyed writing this article. This is my first article, so let me know what you thought and I will keep them coming.
Introduction
Social Engineering is the art of manipulating a person into revealing sensitive information. Social Engineering is the best hacking tool you can use, in my opinion. Similar to using a computer program to make another system spew out amounts of valuable information about the machine, that an attacker can later use. Think of it as "people hacking". When hacking into system you find a weakness or vulnerability that you can exploit, to gain access to restricted information. Social engineering is taking advantage of a persons weakness and getting them to disclose confidential information. All it takes is a large amount a confidence and basic knowledge of human nature and social behavior patterns. Social engineering does not just apply to computer security, it can apply to nearly any situation.
Understanding Human Nature
When it comes to social engineering there are typically only a handful of “tools” you can use. Some of which are; A basic understanding of human nature, cognitive biases, and psychological fallacies. People generally have social patterns and behaviors that can easily be exploited. Everyone has these flaws, it is a matter of finding out what works with the particular person. There are literally hundreds of these fallacies, and nearly everyone is guilty of them. This is just a few that really stand out to me. Maybe I will cover more in a future article. Some of the most popular human social patterns include:
*The Bandwagon Effect-This is the tendency to follow patterns of another persons, or a groups behavior. Generally everyone has heard the term "jump on the bandwagon", It simply means to do as others do. This particular bias plays a very important roll in social engineering and can be taken advantage of quite easily. Also known as conformity.
*Illusion of Control-This is the illusion that a human believes that they can control the outcome of certain situation, when it is clearly out of their hands. Think of someone who is gambling who believes they can really control the outcome of the numbers they roll. Some people truly believe that they can control the outcome of an event as if to predict the future. Prayer or belief in the paranormal could also be thrown into this category.
*Stereotyping-Stereotyping is judging a person by their distinguished characteristics. Everyone is clearly guilty of this at some point. Every time you meet someone for the first time, you almost always inadvertently judge them. You judge them by their clothes, their hairstyle and just their general appearance. However, stereotyping can sometimes be accurate as I will explain later on in the article.
*The Ostrich Effect-This is act of ignoring the negative situation that is going on. Think of someone that is over-optimistic about financial issues and pretending everything is fine. This particular fallacy is performed by almost anyone in a negative situation.
*Consistency bias-This is known as incorrectly remembering your past thoughts or actions in a given situation. This can be greatly taken advantage of. A new employee may not know how to answer a question, or how they answered it in the past. Therefore possibly disclosing valuable information.
Basic Techniques
You are not going to want to use every technique at once, find one that fits a particular situation and play the part well. Most social engineering can be done over the phone. It is quite simple to call up a company while imitating a person of authority and retrieving sensitive information. Help desks and customer service are very likely to this method of attack.
Be Polite
The best thing you can do is always be polite, never blow your cover by acting rude. Remember, you are sometimes taking advantage of someones good nature. So getting on their bad side is not a good start. Remember to speak up and be firm, but do not be rude. For example, call up a company you are interested in, and politely ask questions. Act as if you truly want to learn about how their system works, or what tools they use. Do not blatantly ask for something that you know is restricted information. You have to keep talking to them, while sounding knowledgeable and interested. Ask to speak to a manager, or someone in charge. Working your way up to someone that knows it all. Write down the names of employees pretend you are interested in that particular field of work, ask what type of education and things you will need to learn. The goal here is to persuade them from a psychological point of view.
Pretend to be ignorant
You obviously do not want the target to know much about you, so you want to be as discrete as possible. You do not want them to become concerned with a question you may have asked. Playing dumb is also another technique that can be used. Pretend to know nothing whatsoever and create a fake problem to ask customer service about. Keep them on the phone long enough and keep asking questions. Give them a fake name and phony problem. Ask for their name and figure out where they stand in the company. You know how annoying it is when you call a company and they keep redirecting you to someone else. They have thousands of calls each day, chances are they will not remember you. In all honesty they probably could not care less, they just want to get rid you and have someone else help you.
Be Curious, without giving it away
Write down a list of things you want to figure out with a certain phone call. Whether it be a certain name, phone number or just a piece of information that helps put together a piece of the puzzle. Ask for names, and to speak to certain people. Make sure you do your homework first and have a general knowledge about the company. If you do not know what to say beforehand you will sound like a fumbling idiot and your confidence level will decrease.
Pretending to be someone of higher authority
This applies the the bandwagon effect and also false memory. Tell a client that is lower in the chain that you are someone who you are not. Tell them you are an employee (in this case it would be a good idea to have a list of employees that you found on the company website or through the yellow pages.) Ask to speak to so and so, who is higher up in the company than she is. Tell them you need a phone number, or whatever it may be you are searching for. That is why I think it is a good idea to have a goal of what you are truly after. This method is known as reverse social engineering. This requires a bit of research and preparation to pull off, but with proper execution and very well be one of the best methods.
Other Techniques
These techniques are aimed to physical access to a specific company. Be careful with these though, they could land you in some pretty tough situations that may be harder to talk your way out of. Just remember that social engineering can be applied to nearly any given situation.
Dumpster Diving
As silly as this may sound, dumpster diving as an effective way of gaining valuable information about a company. You would be surprised what kinds of things they may have thrown away. Perhaps a trashed company computer with the hard rive still in it. Or possibly company phone books, organizational charts, memos, company policy manuals, calendars of meetings, events and vacations, system manuals, printouts of sensitive data or login names and passwords, printouts of source code, disks and tapes, company letterhead and memo forms, and outdated hardware. I will not go into great detail of how to dumpster dive, but I am sure you get the picture. Bottom line is that valuable things can be found in a company dumpster.
Tailgating
The art of following an authorized person into an area where you are not authorized. This is where your acting skills can come in handy. Pretend to be the repair man they called last week. Come ready with all your tools, hardhat white t-shirt and jeans and play the part. When really you just want physical access to something a normal civilian would not have rights to access. This technique takes some serious dedication, but in the end very much worth the effort. This requires doing your best to blend in. Maybe pretending to be just another employee on a smoke break. They will eventually finish and go back inside. That would be your cue to follow them inside, thus giving you physical access. Whatever your doing play the part, and do it with confidence.
Shoulder Surfing
Seems easy enough, right? It is as simple as it sounds, peering over someones shoulder to see what they are typing. Be careful not to get caught with this one, by making it obvious you are trying to view what they are typing. I am sure all of you have exercised some form of this at one point. I do not think I need to go into great detail on this, just be smooth about things.
People Watching
This is by far my favorite method. Keep in mind that social engineering does not always involve tricking people. Like I said before, it is all about understanding human nature. For some odd reason, I enjoy watching people. Whenever I go to a mall, airport or somewhere where I can sit down in public, I love to watch people. (In a non-rapist/stalker sort of way) I like to nonchalantly eavesdrop and just hear about their lives and what they have to say. I know you have all done it, at one time or another you have listened in on someones conversation and heard something they probably did not want you to hear. Everyone judges other people by the way they look or talk. It is one of the cognitive biases I listed called Stereotyping. A great way to practice your social engineering skills is to sit down and judge people. Not in a rude way, but try to figure out their life based on their appearance and social patterns. Pick out someone and see think about what they are wearing, what they are talking about, how they carry themselves and try to imagine what kind of life they lead.
Conclusion
This is just the tip of the iceberg when it comes to social engineering. There is much more to cover, but I hope you all learned something. Overtime you will become better at reading and understanding human nature. You will develop your own style of social engineering. There are many more methods that I left out, but these are great to start with. Knowing how to social engineer is a great way to prevent yourself from getting tricked by others. For example, the police use social engineering and forms of manipulation constantly. Others may disagree, but overall I feel this is an important topic to cover and I enjoyed writing this article. This is my first article, so let me know what you thought and I will keep them coming.
Web Interaction Using Python
Introduction
In a number of the HTS programming missions you are asked to interact with the site from a program that you have written, as opposed to using a webbrowser. There are plenty of other applications for web interaction, however. I have written a few python scripts to download various data from websites (e.g. http://python.pastebin.com/f268e6319 )
I will cover two ways of getting data from a website (and in fact, sending data too). If there are any problems with the article, leave a comment.
All examples have been written in Python 2.6. There are quite a few differences between 2.6 and 3.0, but the only ones that should apply in the code snippets in this article involve the print function.
In Python 2.6 a simple hello world is this:
CODE :
__________________________________________________________________________
print "Hello World"
__________________________________________________________________________
In Python 3.0 it looks like this:
CODE :
__________________________________________________________________________
print("Hello World")
__________________________________________________________________________
It's a good idea, and I will switch to 3.0 when it is finally worn in, but for the moment I'm sticking with 2.6.
If there are problems with any of the code running as 3.0, try using the 2to3 script (It came preinstalled with Xubuntu for me.. not sure about on windows etc).
Anyway, now that's all covered, on with the article.
The Url Libraries
First of all we will start with a tutorial on the URL libraries. These are urllib and urllib2.
Let's immediately get started with some code.
CODE :
__________________________________________________________________________
import urllib2
url = "http://example.com"
website = urllib2.urlopen(url)
print website.read()
__________________________________________________________________________
Pretty simple code really, and for a lot of things it's all you need to know. It fetches the website "http://example.com" and stores the data as an instance on which we use the read() function to return the data retrieved from the site. Here are the functions:
instance.read() This returns the data retrieved from the site.
instance.info() This returns the HTTP message from the server, it has a lot of useful information in it including cookie info and server type.
instance.geturl() Returns the URL that was requested - seems pointless but we'll cover it in a second and you'll see why there is a point.
instance.getcode() Returns the HTTP status code. (e.g. 404, 200)
It's worth messing around with those a bit, rather than just taking my word for what they do.
I'll now just show a use of the geturl() function:
CODE :
__________________________________________________________________________
import urllib2
url = "http://google.com" # After google, try 'http://example.com'
website = urllib2.urlopen(url)
if url == website.geturl():
print "Website not redirected."
else:
print "Website redirected you."
__________________________________________________________________________
Why you'd want to do that, I don't know, but there's bound to be a use for it sometime. But that is one application of the geturl() function anyway.
Let's do a HTTP POST request now. They're pretty easy really, but can look a little complicated, so don't worry.
Before you look at the code, you might want to set up a server (or get some webspace) so you can test this out. A little PHP script like below will do the trick:
CODE :
__________________________________________________________________________
echo $_POST['test'];
?>
__________________________________________________________________________
And before anyone says anything about XSS - get lost - it's a testpage that will be up for 10 minutes on a server that noone cares about. But if you really are that bothered, you can use strip_tags() around that. (I say this because I can tell there'll be someone who will try and pipe up a clever comment).
Now then, we'll be introducing a new module for this (though it isn't strictly necessary, it's the best way I reckon). I will import the single function as we don't need any other functions from the module.
Okay, let's go:
CODE :
__________________________________________________________________________
import urllib2
from urllib import urlencode # new module and function
url = "http://localhost/test.php"
data = {'test':'lolwut'}
# you can add as much info as you want to this dictionary
# "test" is the label for the data, so that PHP script above
# should display "lolwut".
encoded_data = urlencode(data)
# remember that this is from that imported module, normally you'd
# use this: urllib.urlencode(data) if you used a normal import.
website = urllib2.urlopen(url, encoded_data)
print website.read() # That was pretty easy, right?
__________________________________________________________________________
Pretty straightforward, right?
Let's go onto HTTP Basic Authentication. This is more tricky. Here's the skeleton code for opening more advanced things, including HTTP authentication.
CODE :
__________________________________________________________________________
import urllib2
url = "http://example.com"
openerDirective1 = ...
openerDirective2 = ...
opener = urllib2.build_opener(openerDirective1, openerDirective2)
urllib2.install_opener(opener)
website = urllib2.urlopen(url)
__________________________________________________________________________
Okay, that's a lot more complicated. Note the "openerDirective"s. They are basically a way of adding headers to the urlopen requests.
You can have numerous opener directives, or just the one. You build them into an opener using the build_opener() function then install it, using install_opener(). After that, you can request a site and it will include the headers that you have specified.
Let's look at creating a HTTP Basic Authentication header.
CODE :
__________________________________________________________________________
authDirective = urllib2.HTTPBasicAuthHandler()
realm = "Webmail"
url = "http://example.com/webmail/"
username = "leethaxxer"
password = "letmein"
authDirective.add_password(realm, url, username, password)
__________________________________________________________________________
Then, we just build the opener and install it like we did in the skeleton code. Here:
CODE :
__________________________________________________________________________
opener = urllib2.build_opener(authDirective)
urllib2.install_opener(opener)
__________________________________________________________________________
I plan to write another article soon about cookies in Python, both as part of CGI and as part of requests with Urllib2.
Now I will move onto sockets and raw HTTP requests, and include cookies in that.
Socket Programming in Python
Socket programming is a really useful thing to learn - it's a must really, especially if you want to learn about security.
Again, we'll get some code out there straight away:
CODE :
__________________________________________________________________________
import socket
s = socket.socket()
host = "www.example.com"
port = 80
addr = (host, port)
s.connect(addr)
s.send("Something to send..")
print s.recv(1024)
# 1024 is the buffer size, you don't need to worry about it
# much right now.
s.close()
__________________________________________________________________________
There we are. We've created a socket, connected to "www.example.com" on port 80 then sent "Something to send.." and received something back, which has been printed out. Then we closed the socket, which isn't strictly necessary - but good practice.
Here's some better stuff to send, however:
CODE :
__________________________________________________________________________
GET /index.html HTTP/1.1\r\n
Host: www.example.com\r\n
__________________________________________________________________________
That's a simple HTTP GET request, asking for "index.html".
Here's a post request:
CODE :
__________________________________________________________________________
POST /index.php HTTP/1.1\r\n
Host: www.example.com\r\n
Content-Length: 11\r\n
\r\n
hello=world\r\n
__________________________________________________________________________
Now let's add a cookie to a HTTP GET:
CODE :
__________________________________________________________________________
GET /index.html HTTP/1.1\r\n
Host: www.example.com\r\n
Set-Cookie: hello=world\r\n
__________________________________________________________________________
There are other socket modes that can be set, this article is a very basic introduction. I would recommend reading this article if you want to learn more: http://www.amk.ca/python/howto/sockets/
Conclusion
Hopefully this article will help you begin to interact with the Internet using Python. It's just the beginning and I will work on follow-up articles. Good luck and thanks for reading.
dotty.
In a number of the HTS programming missions you are asked to interact with the site from a program that you have written, as opposed to using a webbrowser. There are plenty of other applications for web interaction, however. I have written a few python scripts to download various data from websites (e.g. http://python.pastebin.com/f268e6319 )
I will cover two ways of getting data from a website (and in fact, sending data too). If there are any problems with the article, leave a comment.
All examples have been written in Python 2.6. There are quite a few differences between 2.6 and 3.0, but the only ones that should apply in the code snippets in this article involve the print function.
In Python 2.6 a simple hello world is this:
CODE :
__________________________________________________________________________
print "Hello World"
__________________________________________________________________________
In Python 3.0 it looks like this:
CODE :
__________________________________________________________________________
print("Hello World")
__________________________________________________________________________
It's a good idea, and I will switch to 3.0 when it is finally worn in, but for the moment I'm sticking with 2.6.
If there are problems with any of the code running as 3.0, try using the 2to3 script (It came preinstalled with Xubuntu for me.. not sure about on windows etc).
Anyway, now that's all covered, on with the article.
The Url Libraries
First of all we will start with a tutorial on the URL libraries. These are urllib and urllib2.
Let's immediately get started with some code.
CODE :
__________________________________________________________________________
import urllib2
url = "http://example.com"
website = urllib2.urlopen(url)
print website.read()
__________________________________________________________________________
Pretty simple code really, and for a lot of things it's all you need to know. It fetches the website "http://example.com" and stores the data as an instance on which we use the read() function to return the data retrieved from the site. Here are the functions:
instance.read() This returns the data retrieved from the site.
instance.info() This returns the HTTP message from the server, it has a lot of useful information in it including cookie info and server type.
instance.geturl() Returns the URL that was requested - seems pointless but we'll cover it in a second and you'll see why there is a point.
instance.getcode() Returns the HTTP status code. (e.g. 404, 200)
It's worth messing around with those a bit, rather than just taking my word for what they do.
I'll now just show a use of the geturl() function:
CODE :
__________________________________________________________________________
import urllib2
url = "http://google.com" # After google, try 'http://example.com'
website = urllib2.urlopen(url)
if url == website.geturl():
print "Website not redirected."
else:
print "Website redirected you."
__________________________________________________________________________
Why you'd want to do that, I don't know, but there's bound to be a use for it sometime. But that is one application of the geturl() function anyway.
Let's do a HTTP POST request now. They're pretty easy really, but can look a little complicated, so don't worry.
Before you look at the code, you might want to set up a server (or get some webspace) so you can test this out. A little PHP script like below will do the trick:
CODE :
__________________________________________________________________________
echo $_POST['test'];
?>
__________________________________________________________________________
And before anyone says anything about XSS - get lost - it's a testpage that will be up for 10 minutes on a server that noone cares about. But if you really are that bothered, you can use strip_tags() around that. (I say this because I can tell there'll be someone who will try and pipe up a clever comment).
Now then, we'll be introducing a new module for this (though it isn't strictly necessary, it's the best way I reckon). I will import the single function as we don't need any other functions from the module.
Okay, let's go:
CODE :
__________________________________________________________________________
import urllib2
from urllib import urlencode # new module and function
url = "http://localhost/test.php"
data = {'test':'lolwut'}
# you can add as much info as you want to this dictionary
# "test" is the label for the data, so that PHP script above
# should display "lolwut".
encoded_data = urlencode(data)
# remember that this is from that imported module, normally you'd
# use this: urllib.urlencode(data) if you used a normal import.
website = urllib2.urlopen(url, encoded_data)
print website.read() # That was pretty easy, right?
__________________________________________________________________________
Pretty straightforward, right?
Let's go onto HTTP Basic Authentication. This is more tricky. Here's the skeleton code for opening more advanced things, including HTTP authentication.
CODE :
__________________________________________________________________________
import urllib2
url = "http://example.com"
openerDirective1 = ...
openerDirective2 = ...
opener = urllib2.build_opener(openerDirective1, openerDirective2)
urllib2.install_opener(opener)
website = urllib2.urlopen(url)
__________________________________________________________________________
Okay, that's a lot more complicated. Note the "openerDirective"s. They are basically a way of adding headers to the urlopen requests.
You can have numerous opener directives, or just the one. You build them into an opener using the build_opener() function then install it, using install_opener(). After that, you can request a site and it will include the headers that you have specified.
Let's look at creating a HTTP Basic Authentication header.
CODE :
__________________________________________________________________________
authDirective = urllib2.HTTPBasicAuthHandler()
realm = "Webmail"
url = "http://example.com/webmail/"
username = "leethaxxer"
password = "letmein"
authDirective.add_password(realm, url, username, password)
__________________________________________________________________________
Then, we just build the opener and install it like we did in the skeleton code. Here:
CODE :
__________________________________________________________________________
opener = urllib2.build_opener(authDirective)
urllib2.install_opener(opener)
__________________________________________________________________________
I plan to write another article soon about cookies in Python, both as part of CGI and as part of requests with Urllib2.
Now I will move onto sockets and raw HTTP requests, and include cookies in that.
Socket Programming in Python
Socket programming is a really useful thing to learn - it's a must really, especially if you want to learn about security.
Again, we'll get some code out there straight away:
CODE :
__________________________________________________________________________
import socket
s = socket.socket()
host = "www.example.com"
port = 80
addr = (host, port)
s.connect(addr)
s.send("Something to send..")
print s.recv(1024)
# 1024 is the buffer size, you don't need to worry about it
# much right now.
s.close()
__________________________________________________________________________
There we are. We've created a socket, connected to "www.example.com" on port 80 then sent "Something to send.." and received something back, which has been printed out. Then we closed the socket, which isn't strictly necessary - but good practice.
Here's some better stuff to send, however:
CODE :
__________________________________________________________________________
GET /index.html HTTP/1.1\r\n
Host: www.example.com\r\n
__________________________________________________________________________
That's a simple HTTP GET request, asking for "index.html".
Here's a post request:
CODE :
__________________________________________________________________________
POST /index.php HTTP/1.1\r\n
Host: www.example.com\r\n
Content-Length: 11\r\n
\r\n
hello=world\r\n
__________________________________________________________________________
Now let's add a cookie to a HTTP GET:
CODE :
__________________________________________________________________________
GET /index.html HTTP/1.1\r\n
Host: www.example.com\r\n
Set-Cookie: hello=world\r\n
__________________________________________________________________________
There are other socket modes that can be set, this article is a very basic introduction. I would recommend reading this article if you want to learn more: http://www.amk.ca/python/howto/sockets/
Conclusion
Hopefully this article will help you begin to interact with the Internet using Python. It's just the beginning and I will work on follow-up articles. Good luck and thanks for reading.
dotty.
An Introduction to CSRF Vulnerabilities
What is a CSRF Attack?
A CSRF attack is a form of attack in which commands are transmitted from a victim to another website without the users consent. CSRF attacks are usually invisible and rely on browser functionality (such as automatically loading images).
How is a CSRF Attack Carried Out?
CSRF attacks are embedded in an element browsers automatically react to (such as an image tag).
Lets assume that Joe has just registered with a brand new Electronic Money transfer site. When Joe wants to transfer money, he heads to www.example.com/transfer.php to send some money to his wife, Mary.
He fills out the forms for the amount of money he wants to transfer and who he wants to send the money to, and then clicks submit. The URL now looks like this:
CODE :
__________________________________________________________________________
//www.example.com/transfer.php?from=Joe&to=Mary&amount=2
__________________________________________________________________________
The next day, Janice, Joes angry ex-wife, also registers with the site. She decides to send $5 to her boyfriend, named Sam. She heads to www.example.com/transfer.php, fills out the forms (quite angrily), and hits submit.
She notices that the URL,
CODE :
__________________________________________________________________________
//www.example.com/transfer.php?from=Janice&to=Sam&amount=5
__________________________________________________________________________
does not require any authorization besides her Session cookie (which is automatically send to the web server).
Still bitter over what she thinks was an unfair settlement to her divorce with Joe, she slips on her black hat and decides to cheat Joe out of his money.
She sends a message to Joe which looks like this:
CODE :
__________________________________________________________________________
//Title: I Hate You!!!!
You are the most rotten, vile, PIG ever!!!!!
[img]www.example.com/transfer.php?from=Joe&to=Janice&amount=5000[/img]
__________________________________________________________________________
(Note that Janice used BBCode for her image tag, which example.com automatically translates into HTML.)
Later that day, Joe logs on and views the message. His browser sees the image tag and automatically follows it to
CODE :
__________________________________________________________________________
//www.example.com/transfer.php?from=Joe&to=Janice&amount=5000
__________________________________________________________________________
His browser then attempts to download the page and display it as an image. Because the link provided is not a valid image, the browser displays it as a broken image.
However, the server at example.com sees that Joe has visited the link, and transfers $5000 dollars to Janice.
All this happens invisibly and within seconds.
Dangers of CSRF
We now understand how a CSRF attack is performed. But, what can this attack do?
It can:
*Transfer Funds
*Log a user in/out
*Register a user
*Log data of a user
*Send a message from the victim to someone else
*Etc
The only requirement is that the server must not have a means of detecting if the user has authorized the action that a CSRF attack performs.
Prevention of CSRF Attacks
CSRF attacks can be prevented in a number of ways, but the best way to prevent them is a combination of many different methods.
CSRF attacks are much easier if an action can be performed with an HTTP GET request, but simply having only POST requests is not sufficient to prevent CSRF attacks.
One common method of preventing CSRF attacks is to have a hidden value randomly generated upon the users visit of the webpage. The advantage of this strategy is that the attacker can not predict what the token will be, and thus cannot conduct the attack. This would look something like
CODE :
__________________________________________________________________________
//
A CSRF attack is a form of attack in which commands are transmitted from a victim to another website without the users consent. CSRF attacks are usually invisible and rely on browser functionality (such as automatically loading images).
How is a CSRF Attack Carried Out?
CSRF attacks are embedded in an element browsers automatically react to (such as an image tag).
Lets assume that Joe has just registered with a brand new Electronic Money transfer site. When Joe wants to transfer money, he heads to www.example.com/transfer.php to send some money to his wife, Mary.
He fills out the forms for the amount of money he wants to transfer and who he wants to send the money to, and then clicks submit. The URL now looks like this:
CODE :
__________________________________________________________________________
//www.example.com/transfer.php?from=Joe&to=Mary&amount=2
__________________________________________________________________________
The next day, Janice, Joes angry ex-wife, also registers with the site. She decides to send $5 to her boyfriend, named Sam. She heads to www.example.com/transfer.php, fills out the forms (quite angrily), and hits submit.
She notices that the URL,
CODE :
__________________________________________________________________________
//www.example.com/transfer.php?from=Janice&to=Sam&amount=5
__________________________________________________________________________
does not require any authorization besides her Session cookie (which is automatically send to the web server).
Still bitter over what she thinks was an unfair settlement to her divorce with Joe, she slips on her black hat and decides to cheat Joe out of his money.
She sends a message to Joe which looks like this:
CODE :
__________________________________________________________________________
//Title: I Hate You!!!!
You are the most rotten, vile, PIG ever!!!!!
[img]www.example.com/transfer.php?from=Joe&to=Janice&amount=5000[/img]
__________________________________________________________________________
(Note that Janice used BBCode for her image tag, which example.com automatically translates into HTML.)
Later that day, Joe logs on and views the message. His browser sees the image tag and automatically follows it to
CODE :
__________________________________________________________________________
//www.example.com/transfer.php?from=Joe&to=Janice&amount=5000
__________________________________________________________________________
His browser then attempts to download the page and display it as an image. Because the link provided is not a valid image, the browser displays it as a broken image.
However, the server at example.com sees that Joe has visited the link, and transfers $5000 dollars to Janice.
All this happens invisibly and within seconds.
Dangers of CSRF
We now understand how a CSRF attack is performed. But, what can this attack do?
It can:
*Transfer Funds
*Log a user in/out
*Register a user
*Log data of a user
*Send a message from the victim to someone else
*Etc
The only requirement is that the server must not have a means of detecting if the user has authorized the action that a CSRF attack performs.
Prevention of CSRF Attacks
CSRF attacks can be prevented in a number of ways, but the best way to prevent them is a combination of many different methods.
CSRF attacks are much easier if an action can be performed with an HTTP GET request, but simply having only POST requests is not sufficient to prevent CSRF attacks.
One common method of preventing CSRF attacks is to have a hidden value randomly generated upon the users visit of the webpage. The advantage of this strategy is that the attacker can not predict what the token will be, and thus cannot conduct the attack. This would look something like
CODE :
__________________________________________________________________________
//
Assembly Language for Z80 processor on TI83+ Calculator
This article is about assembly langauge for the z80 processor, and running the code on the TI83+ calculator system. The z80 processor is a robust, 16bit processor produced by Zilog. This processor is used in your TI83+ calculator, GameBoy Color, Sega Game Gear, and a fair list of electronics. I'm writing this article for both experienced assembly langauge guru's interested in z80 processor and n00bs who want to get their hands in on the action.
WHY LEARN ASSEMBLY LANGUAGE AT ALL?
I can tell you personally that it is a rewarding langauge to understand because you will have that much more understanding of computers and gives you much more control over memory. This is also the mnemonic code for for a byte instruction set. The byte instruction set is what is used for shellcode!! Shellcoding is part of remote buffer overflows part of leet still legit hacking methods. Another reason is because this is FUN STUFF! come on! get your hands dirty and do some z80. Once you know one assembly language, you can teach yourself any assembly language for any processor.
This article is from information, research and hacking around a couple years ago over a christmas break.
WHAT IS GOIN DOWN IN THIS ARTICLE?
In this article I will explain what you need to set up your coding environment, Learn instructions of z80 processor along with nifty Interrupt Service Routines provided by TI83+ System, write a HelloWorld application and do some simple math instructions, along with tangents I find relevant from personal experience. I hope this is one of 2 or 3 articles, where the second article should cover arrays, conditional statements, and write a Game. The 3rd will cover the stack and monochramatic graphics.
YOU NEED!
-Windows XP (Linux is available, but I couldn't find a decent assembler/linker)
-Silver USB cable available at (http://education.ti.com/educationportal/sites/US/productDetail/us_connectivitycable_silverusb.html)
this is used for transfering files to and from the calc and PC (note: if you're cheap you could make one yourself if you have the skillz :X, if so hats off to you)
-TASM.exe (Table assembler NOT Turbo assembler) This is the assembler
-devpac8x.com This is the linker it generates the executable code that will be the file to upload to calculator
SETTING UP THE ENVIRONMENT?
I'm assuming you have the silver link cable now and the software that came along with it installed on your PC. Now...
1) Now make a folder called z80 and put both the TASM.exe and devpac8x files in same directory.
2) Make a makez80.bat batch File with following code...
CODE :
__________________________________________________________________________
::@Author - xfelix
::@File - makez80.bat
::Description - assemble and link z80 programs
tasm -80 -i -b %1.z80 %1.bin
devpac8x %1
__________________________________________________________________________
3) Open up a DOS shell and move to TASM root directory
Environment is set now let's diggin.
Before you Begin
----------------
Writing instructions and registers are not case sensitive although useing labels are, but as one is learning assembly language they should develop their own style of writing, this can be thought of as your trade mark as a programmer. You can tell alot about a programmer just by the way they write code, and once one has been programming for a while they can tell the difference between a true poet and a script kiddie. So when doing this tutorial take your time, and make sure you are taking in many of the juicy details because this is a jam packed tutorial. Even though this tutorial is broken up in to two parts, any one is welcome to break it up into their own parts, and follow it at their own pace, this is a good strategy to approach this article.
Part 1
-------
Instructions
There are many instructions provided with a processor, which can be thought of as commands to peform some action. An action could be to move data from a register to memory, to add the data of one register to another register, compare two registers, jump to a location in memory, etc. If one has ever done assembly language for the Intel-IA32 processor there are many instructions that you will probably take for granted when working with Z80 processor. The z80
processor does not contain a multiply instruction MUL or a divide instruction DIV like the intel IA-32. One must develop their own clever ways to do this.
Registers
Registers are used for quick access of memory and is what also performs all computations. You can move data from memory to a register in the processor, move data froma a register to memory, and move data from a register to another register, but one may never move memory directly to memory. The Instuction to peform these actions is LD, which is short for load. The format of this instruction is
LD DESTINATION, SOURCE
where DESTINATION can be any register or memory address, and SOURCE can be any register or memory location. What ever the type of data storage it is (memory or register) it will move the data in the SOURCE storage to the DESTINATION storage. One can also use constant number values as the source seen in the sample code below...
First a table of the z80 register names for 8 bit and 16 bit, then some sample code.
8 bit registers
---------------
A - 8 bit accumulator register
B - general purpose / b is high byte of BC register
C - general purpose / C is low byte of BC register
D - general purpose / D is high byte of DE register
E - general purpose / E is low byte of DE register
H - H is high byte of HL register
L - L is low byte of HL register
16 bit registers
-----------------
BC - general purpose/base pointer register
DE - general purpose register
HL - 16 bit accumulator register
SP - stack pointer
IX - Index register
IY - Index register
I don't use the last two register IX and IY very often since they both contain (I) register, which can make life hell, so I avoid them at all costs, but there are times when they are necesarry.
SAMPLE
------
CODE :
__________________________________________________________________________
LD a, b ;moves the contents of register b to register a
__________________________________________________________________________
CODE :
__________________________________________________________________________
LD a, $10 ;moves the constant hexadecimal number 10
LD b, a ;now we move the contents of a to b
LD HL, memoryData ;moves the memoryData memory address into HL,
LD (HL), b ;moves the contents of b into the memory address storage
memoryData: .db 0 ;memoryData variable initialized to zero
__________________________________________________________________________
*****CAUTION****
I do not recommend moving data into memory similar to the following example
CODE :
__________________________________________________________________________
LD ($FFFF), a
__________________________________________________________________________
...although this is valid and will execute your calculator will most likely crash and your RAM will erase itself and you will have a freshly wiped RAM on your hands. While programming on your TI83+ it will most likely crash often, even if you only have logic errors. This is due to the fact that programming on your calcuator is in REAL mode, unlike when you program on your computer which is in PROTECTED mode.
HelloWorld
If you have not figured out by now a semi-colon ; is a comment in TASM and most other assembly languages. The white spaces used before and after the instruction is a TAB space, TASM will not like your code if you don't use a TAB space inbetween your instruction and storage placers.
CODE :
__________________________________________________________________________
;***************************************************************************
;@author - xfelix
;@date - 12/05/09
;@file - hello.z80
;@description - This is a HelloWorld application for learning how to
; develop z80 applications for TI83+ Calculator :D
;Compile Instructions: tasm -80 -i -b hello.z80 hello.bin (For linking)
; devpac8x hello (For byte code)
;***************************************************************************
#include "ti83plus.inc"
.list
.org $9d93
.db $bb,$6d
code: xor a ;zero a by exlusive or-ing it by itself
ld h, a ;load a into h
ld l, a ;load a into l
ld (PenCol), hl ;put hl in PenCol memory
ld hl, str1
bcall(_PutS) ;_PutS takes HL register as parameter
bcall(_NewLine)
ret
data:
str1: .db "Hello World!! w00t, calc codez (^_^!)", 0
.end
.end
__________________________________________________________________________
Explanation
Line 1 #include "ti83plus.inc"
The #include directive is similar to the one in C only instead of including .h (header files) you can include .inc (include files). The ti83plus.inc file contains names of kernel functions and important memory locations used by the mirageOS.
Line 2 .list
Line 3 .org $9d93
Line 4 .db $bb,$6d
make sure these lines are always in any program you ever run. Line 3 contains the .org directive, which specifies where in memory the application will run, which is always $9d93. Make sure this number does not change because your program will not run correctly and crash your calculator, I was writing a program before and accidently typed $9593 instead, but it took me a long time to figure out why my application wasn't working. It is suddle details like this that can hold you back. Line 4 .db (define byte) will define two bytes at the very beginning of the program $bb,$6d. These two bytes are magic numbers that the mirageOS will like to see to make sure it's executing a valid TI83+ progam.
Line 5 xor a
The only instruction in this program that you have not seen before is xor, which will perform an exlusive or operation on the register given with the a register. Since I have given the (a) register, the operation will be a XOR a, which zero out the a register. If I had the following sample code
xor b ;Then the operation will become a XOR b
You should know what Line 6-10 does by reading the comments, but I would like to explain more Line 11
Line 11 bcall(_PutS)
bcall instruction is defined in the include file as well as the (_PutS) function name. The kernel function (_PutS) takes the hl register as a parameter, which should be the memory address of the string you would like to be displayed. The (_NewLine) kernel function will go to the next line for printing data or recieving input.
Line 14 ret
The ret instuction returns to the memory location that called the executuable. This memory location is stored in the stack, but I will talk more about the stack and procedures in the 3rd article.
Labels
---------------
There are three labels in this program and two of them are optional that I put in for clarity, so I know where my code section and data section are located. The code section is where your code should be, and the data section is where you should declare all of your variables. Here is how you declare a string variable
Line 16 str1: .db "Hello World!! w00t, calc codez (^_^!)", 0
Notice the name of the variable is just a label followed by a .db (define byte). Inorder to declare a 16 bit variable you would use the following sample code
CODE :
__________________________________________________________________________
myNum: .dw $1337
__________________________________________________________________________
... which is a .dw (define word) a 16 bit variable myNum, set to a value of $1337 in hexadecimal. Typically the data section is before the code section, but people who write viruses and shellcode will put the code section first followed by data section ^.^ Try to rewrite the hello application so that the data section comes before the code section.
Make sure there are two .ends at the end of the file since who ever wrote TASM screwed up and expected two .ends as if it's already not hard enough to make a typo mistake.
Compiling
----------
Make sure you save the file as a .z80 file, I called mine hello.z80. Then type the following in command prompt makez80 hello and should then assemble and link the file like in this image.
Now once this is accomplised this makez80 has assembled and linked your application, which has generated a TI83+ executable file hello.8XP. Asssuming you have installed the software that came with your TI83+ silver link cable, right click the file and hit send to TI device, and you will get a menu like this
It will automatically start the transfer after a short time has passed.
Now pick up your TI83+ calculator and hit the PRGM button and you should see your application sitting in RAM Hello. To Run this program you must hit
-2nd Catalog
-Choice Asm(
-Now hit the PRGM button
-Choose the Hello application
-Now hit ENTER
Your application should have run and exited very quickly ^^ congradulations!! you've run your first application on the z80 processor. Now take a break or play around with the output text or what not, but wait to continue to Part 2 of this paper, you have taken in alot of information. But before I begin part 2 here is another useful kernel function bcall(_DispHL) (display HL register), this function will dump what ever data is stored in the HL registers, so feel free to play around with loading data from memory to registers during this grace period :D
Part 2
------------------
Math instructions
I will discuss the following math instructions ADD, INC, DEC, SUB, and SRL, but there are many more. Check the references for an entire list of the Z80 processor instructions set and more. The format of these instructions is similar to the LD instruction only when adding the 8 bit registers make sure that the (A) register is always getting added to, and for 16 bit registers either the HL,IX, or IY registers. This is because A and HL registers are considered the accumulator registers for their respective size, it's just how it is. All assembly languages have their accumulator registers, only Z80 takes advantage and is more strict then any 32 bit processor. Say we have to following sample code
CODE :
__________________________________________________________________________
LD HL, $10
LD DE, $5
ADD HL, DE ;Add the contents of DE register to the HL register
bcall(_DispHL) ;dump the HL register in decimal notation
__________________________________________________________________________
This will add the contents of the DE register to the contents of the HL register. After the ADD instruction is executed the HL register will equal $15 and the DE register will equal $5. When executed the following output of this sample code will be 21. Caution the z80 processor does not support the following instruction
CODE :
__________________________________________________________________________
ADD BC, DE
__________________________________________________________________________
it's simply not supported by the Z80 processor to peform this operation, which can cause headaches ontop of headaches at times. One may also add to a register directly from memory, but never to memory from a register. Check out the next example
CODE :
__________________________________________________________________________
remainingHealth: .db $35
LD A, $65 ;damage after getting knifed in counter strike sorce into B register
LD HL, remainingHealth ;HL register points to remainingHealth memory address
ADD A, (HL) ;adds the contents from the memory to the B register
;There is a suddle problem in the above code can you think what it is?? Hint what is the maximum number that can fit into an 8 bit register?
;Can you fix it??
__________________________________________________________________________
When you load the memory address of the variable into the HL register, it is essentially pointing to that place in memory, which is similar to how pointers in C and C++ work. When you put parantesis around the HL register you are accessing the byte data at the location in memory. To give you an idea of how working with arrays would work to get the next item in the array you would use (HL+1), then (HL+2), etc. How would you display the register in A?? here is the following code
CODE :
__________________________________________________________________________
LD HL, 0 ;zero/clean out the HL register
LD L, A ;Load A register into lower register of HL register
bcall(_DispHL) ;Display HL register contents
__________________________________________________________________________
The subtract instruction will substract the contents of the specified register from the A register. Here is a following sample code
CODE :
__________________________________________________________________________
LD A, $FF ;Load the hex value $FF into the A register
LD B, $FE ;Load the hex value $FE into the B register
SUB B ;Subtract the contents of B register from A register, aka A=A-B
__________________________________________________________________________
After the following sample code is executed the A register will be equal to 1. The next two instructions are insanely easy to follow INC and DEC. The INC instruction will increment a register by 1, and the DEC instruction will decrement a register by 1.
CODE :
__________________________________________________________________________
DEC HL ;decrement HL by 1
INC HL ;increment HL by 1
__________________________________________________________________________
HL register will not be changed after the execution of the previous sample code. Now the next instruction that will be discussed is the srl instruction, which stands for (Shift Right Logical). This performs a bitwise operation of shifting the bits to the right by 1 on the specified register. Shifting bits to the right on a register is like dividing the contents of the register by 2^n where n is the number of shifts to the right. If we had the following value in the A register $FF then A will look like this in binary:
A: 11111111 //Also equal to 256 in decimal notation
Now if we call the SRL instruction like this
CODE :
__________________________________________________________________________
SRL A
__________________________________________________________________________
All the bits in the A register will be shifted to the right and drop off the right most bit to the carry flag. I will discuss more on flags and their purpose in the 2nd article when I talk about conditional statements, loops, etc. Now the A register looks like this
A: 01111111 //Also equal to 128 in decimal notation or 256/2 which is what happen after the SRL instruction executed
Now let's right a useful application with the knowledge you've accumulated. The application that We will write is one that will determine the first five numbers of the fibonacci sequence. It's important to note that this code would be alot shorter if we had learned loops, which we haven't yet and/or the use of macros and procedures which are also in later articles. Anyway here is the code that will display the first 5 numbers of the fibonaccie squeunce. It is also important to note that (_NewLine) will destroy all registers:(
CODE :
__________________________________________________________________________
;***************************************************************************
;@author - xfelix
;@date - 01/06/10
;@file - fib.z80
;@description - This is a Fibonacci sequence application that will determine the first
; 5 numbers of the Fibonacci sequence. This application is for learning
; how to develop z80 applications for TI83+ Calculator :D
;Compile Instructions: tasm -80 -i -b fib.z80 fib.bin (For linking)
; devpac8x fib (For byte code)
;***************************************************************************
#include "ti83plus.inc"
.list
.org $9d93
.db $bb, $6d
code:
LD A, (firstNum)
LD HL, secondNum
LD B, (HL)
LD HL, $0000
LD L, A
bcall(_DispHL)
bcall(_NewLine) ;Destroy Registers in process of going to new line
LD HL, $0000
LD L, B
bcall(_DispHL)
bcall(_NewLine)
LD A, (firstNum)
LD HL, secondNum
LD B, (HL)
LD HL, $0000
ADD A, B
LD (firstNum), A ;save the third number to first number
LD L, A
bcall(_DispHL)
bcall(_NewLine)
LD A, (firstNum)
LD HL, secondNum
LD B, (HL)
LD HL, $0000
ADD A, B
LD (secondNum), A ;save the fourth number to second number
LD L, A
bcall(_DispHL)
bcall(_NewLine)
LD A, (firstNum)
LD HL, secondNum
LD B, (HL)
LD HL, $0000
ADD A,B
LD L, A
bcall(_DispHL)
bcall(_NewLine)
ret
Data:
firstNum: .db $1
secondNum: .db $1
.end
.end
__________________________________________________________________________
Final Notes
--------------------
This ends the first article of programming in assembly language for the z80 processor on your TI83+ calculator. I hope it was useful and you picked up a thing or two about assembly language. I have listed references below for instruction set and tutorial/ code examples, which should be useful, you don't have to wait for the second article inorder to continue your quest of learning z80 assembler. Once you have been working with assembly language you have my permission to walk proudly amoung your programmer/hacker peers, and can look down on those who don't know assembly language. You are now apart of the z80 scene.
References
-------------------
z80 Heaven tutorials http://z80-heaven.wikidot.com/system:tutorials
z80 instruction set http://nemesis.lonestar.org/computers/tandy/software/apps/m4/qd/opcodes.html
official Zilog manual http://www.zilog.com/docs/z80/um0080.pdf
WHY LEARN ASSEMBLY LANGUAGE AT ALL?
I can tell you personally that it is a rewarding langauge to understand because you will have that much more understanding of computers and gives you much more control over memory. This is also the mnemonic code for for a byte instruction set. The byte instruction set is what is used for shellcode!! Shellcoding is part of remote buffer overflows part of leet still legit hacking methods. Another reason is because this is FUN STUFF! come on! get your hands dirty and do some z80. Once you know one assembly language, you can teach yourself any assembly language for any processor.
This article is from information, research and hacking around a couple years ago over a christmas break.
WHAT IS GOIN DOWN IN THIS ARTICLE?
In this article I will explain what you need to set up your coding environment, Learn instructions of z80 processor along with nifty Interrupt Service Routines provided by TI83+ System, write a HelloWorld application and do some simple math instructions, along with tangents I find relevant from personal experience. I hope this is one of 2 or 3 articles, where the second article should cover arrays, conditional statements, and write a Game. The 3rd will cover the stack and monochramatic graphics.
YOU NEED!
-Windows XP (Linux is available, but I couldn't find a decent assembler/linker)
-Silver USB cable available at (http://education.ti.com/educationportal/sites/US/productDetail/us_connectivitycable_silverusb.html)
this is used for transfering files to and from the calc and PC (note: if you're cheap you could make one yourself if you have the skillz :X, if so hats off to you)
-TASM.exe (Table assembler NOT Turbo assembler) This is the assembler
-devpac8x.com This is the linker it generates the executable code that will be the file to upload to calculator
SETTING UP THE ENVIRONMENT?
I'm assuming you have the silver link cable now and the software that came along with it installed on your PC. Now...
1) Now make a folder called z80 and put both the TASM.exe and devpac8x files in same directory.
2) Make a makez80.bat batch File with following code...
CODE :
__________________________________________________________________________
::@Author - xfelix
::@File - makez80.bat
::Description - assemble and link z80 programs
tasm -80 -i -b %1.z80 %1.bin
devpac8x %1
__________________________________________________________________________
3) Open up a DOS shell and move to TASM root directory
Environment is set now let's diggin.
Before you Begin
----------------
Writing instructions and registers are not case sensitive although useing labels are, but as one is learning assembly language they should develop their own style of writing, this can be thought of as your trade mark as a programmer. You can tell alot about a programmer just by the way they write code, and once one has been programming for a while they can tell the difference between a true poet and a script kiddie. So when doing this tutorial take your time, and make sure you are taking in many of the juicy details because this is a jam packed tutorial. Even though this tutorial is broken up in to two parts, any one is welcome to break it up into their own parts, and follow it at their own pace, this is a good strategy to approach this article.
Part 1
-------
Instructions
There are many instructions provided with a processor, which can be thought of as commands to peform some action. An action could be to move data from a register to memory, to add the data of one register to another register, compare two registers, jump to a location in memory, etc. If one has ever done assembly language for the Intel-IA32 processor there are many instructions that you will probably take for granted when working with Z80 processor. The z80
processor does not contain a multiply instruction MUL or a divide instruction DIV like the intel IA-32. One must develop their own clever ways to do this.
Registers
Registers are used for quick access of memory and is what also performs all computations. You can move data from memory to a register in the processor, move data froma a register to memory, and move data from a register to another register, but one may never move memory directly to memory. The Instuction to peform these actions is LD, which is short for load. The format of this instruction is
LD DESTINATION, SOURCE
where DESTINATION can be any register or memory address, and SOURCE can be any register or memory location. What ever the type of data storage it is (memory or register) it will move the data in the SOURCE storage to the DESTINATION storage. One can also use constant number values as the source seen in the sample code below...
First a table of the z80 register names for 8 bit and 16 bit, then some sample code.
8 bit registers
---------------
A - 8 bit accumulator register
B - general purpose / b is high byte of BC register
C - general purpose / C is low byte of BC register
D - general purpose / D is high byte of DE register
E - general purpose / E is low byte of DE register
H - H is high byte of HL register
L - L is low byte of HL register
16 bit registers
-----------------
BC - general purpose/base pointer register
DE - general purpose register
HL - 16 bit accumulator register
SP - stack pointer
IX - Index register
IY - Index register
I don't use the last two register IX and IY very often since they both contain (I) register, which can make life hell, so I avoid them at all costs, but there are times when they are necesarry.
SAMPLE
------
CODE :
__________________________________________________________________________
LD a, b ;moves the contents of register b to register a
__________________________________________________________________________
CODE :
__________________________________________________________________________
LD a, $10 ;moves the constant hexadecimal number 10
LD b, a ;now we move the contents of a to b
LD HL, memoryData ;moves the memoryData memory address into HL,
LD (HL), b ;moves the contents of b into the memory address storage
memoryData: .db 0 ;memoryData variable initialized to zero
__________________________________________________________________________
*****CAUTION****
I do not recommend moving data into memory similar to the following example
CODE :
__________________________________________________________________________
LD ($FFFF), a
__________________________________________________________________________
...although this is valid and will execute your calculator will most likely crash and your RAM will erase itself and you will have a freshly wiped RAM on your hands. While programming on your TI83+ it will most likely crash often, even if you only have logic errors. This is due to the fact that programming on your calcuator is in REAL mode, unlike when you program on your computer which is in PROTECTED mode.
HelloWorld
If you have not figured out by now a semi-colon ; is a comment in TASM and most other assembly languages. The white spaces used before and after the instruction is a TAB space, TASM will not like your code if you don't use a TAB space inbetween your instruction and storage placers.
CODE :
__________________________________________________________________________
;***************************************************************************
;@author - xfelix
;@date - 12/05/09
;@file - hello.z80
;@description - This is a HelloWorld application for learning how to
; develop z80 applications for TI83+ Calculator :D
;Compile Instructions: tasm -80 -i -b hello.z80 hello.bin (For linking)
; devpac8x hello (For byte code)
;***************************************************************************
#include "ti83plus.inc"
.list
.org $9d93
.db $bb,$6d
code: xor a ;zero a by exlusive or-ing it by itself
ld h, a ;load a into h
ld l, a ;load a into l
ld (PenCol), hl ;put hl in PenCol memory
ld hl, str1
bcall(_PutS) ;_PutS takes HL register as parameter
bcall(_NewLine)
ret
data:
str1: .db "Hello World!! w00t, calc codez (^_^!)", 0
.end
.end
__________________________________________________________________________
Explanation
Line 1 #include "ti83plus.inc"
The #include directive is similar to the one in C only instead of including .h (header files) you can include .inc (include files). The ti83plus.inc file contains names of kernel functions and important memory locations used by the mirageOS.
Line 2 .list
Line 3 .org $9d93
Line 4 .db $bb,$6d
make sure these lines are always in any program you ever run. Line 3 contains the .org directive, which specifies where in memory the application will run, which is always $9d93. Make sure this number does not change because your program will not run correctly and crash your calculator, I was writing a program before and accidently typed $9593 instead, but it took me a long time to figure out why my application wasn't working. It is suddle details like this that can hold you back. Line 4 .db (define byte) will define two bytes at the very beginning of the program $bb,$6d. These two bytes are magic numbers that the mirageOS will like to see to make sure it's executing a valid TI83+ progam.
Line 5 xor a
The only instruction in this program that you have not seen before is xor, which will perform an exlusive or operation on the register given with the a register. Since I have given the (a) register, the operation will be a XOR a, which zero out the a register. If I had the following sample code
xor b ;Then the operation will become a XOR b
You should know what Line 6-10 does by reading the comments, but I would like to explain more Line 11
Line 11 bcall(_PutS)
bcall instruction is defined in the include file as well as the (_PutS) function name. The kernel function (_PutS) takes the hl register as a parameter, which should be the memory address of the string you would like to be displayed. The (_NewLine) kernel function will go to the next line for printing data or recieving input.
Line 14 ret
The ret instuction returns to the memory location that called the executuable. This memory location is stored in the stack, but I will talk more about the stack and procedures in the 3rd article.
Labels
---------------
There are three labels in this program and two of them are optional that I put in for clarity, so I know where my code section and data section are located. The code section is where your code should be, and the data section is where you should declare all of your variables. Here is how you declare a string variable
Line 16 str1: .db "Hello World!! w00t, calc codez (^_^!)", 0
Notice the name of the variable is just a label followed by a .db (define byte). Inorder to declare a 16 bit variable you would use the following sample code
CODE :
__________________________________________________________________________
myNum: .dw $1337
__________________________________________________________________________
... which is a .dw (define word) a 16 bit variable myNum, set to a value of $1337 in hexadecimal. Typically the data section is before the code section, but people who write viruses and shellcode will put the code section first followed by data section ^.^ Try to rewrite the hello application so that the data section comes before the code section.
Make sure there are two .ends at the end of the file since who ever wrote TASM screwed up and expected two .ends as if it's already not hard enough to make a typo mistake.
Compiling
----------
Make sure you save the file as a .z80 file, I called mine hello.z80. Then type the following in command prompt makez80 hello and should then assemble and link the file like in this image.
Now once this is accomplised this makez80 has assembled and linked your application, which has generated a TI83+ executable file hello.8XP. Asssuming you have installed the software that came with your TI83+ silver link cable, right click the file and hit send to TI device, and you will get a menu like this
It will automatically start the transfer after a short time has passed.
Now pick up your TI83+ calculator and hit the PRGM button and you should see your application sitting in RAM Hello. To Run this program you must hit
-2nd Catalog
-Choice Asm(
-Now hit the PRGM button
-Choose the Hello application
-Now hit ENTER
Your application should have run and exited very quickly ^^ congradulations!! you've run your first application on the z80 processor. Now take a break or play around with the output text or what not, but wait to continue to Part 2 of this paper, you have taken in alot of information. But before I begin part 2 here is another useful kernel function bcall(_DispHL) (display HL register), this function will dump what ever data is stored in the HL registers, so feel free to play around with loading data from memory to registers during this grace period :D
Part 2
------------------
Math instructions
I will discuss the following math instructions ADD, INC, DEC, SUB, and SRL, but there are many more. Check the references for an entire list of the Z80 processor instructions set and more. The format of these instructions is similar to the LD instruction only when adding the 8 bit registers make sure that the (A) register is always getting added to, and for 16 bit registers either the HL,IX, or IY registers. This is because A and HL registers are considered the accumulator registers for their respective size, it's just how it is. All assembly languages have their accumulator registers, only Z80 takes advantage and is more strict then any 32 bit processor. Say we have to following sample code
CODE :
__________________________________________________________________________
LD HL, $10
LD DE, $5
ADD HL, DE ;Add the contents of DE register to the HL register
bcall(_DispHL) ;dump the HL register in decimal notation
__________________________________________________________________________
This will add the contents of the DE register to the contents of the HL register. After the ADD instruction is executed the HL register will equal $15 and the DE register will equal $5. When executed the following output of this sample code will be 21. Caution the z80 processor does not support the following instruction
CODE :
__________________________________________________________________________
ADD BC, DE
__________________________________________________________________________
it's simply not supported by the Z80 processor to peform this operation, which can cause headaches ontop of headaches at times. One may also add to a register directly from memory, but never to memory from a register. Check out the next example
CODE :
__________________________________________________________________________
remainingHealth: .db $35
LD A, $65 ;damage after getting knifed in counter strike sorce into B register
LD HL, remainingHealth ;HL register points to remainingHealth memory address
ADD A, (HL) ;adds the contents from the memory to the B register
;There is a suddle problem in the above code can you think what it is?? Hint what is the maximum number that can fit into an 8 bit register?
;Can you fix it??
__________________________________________________________________________
When you load the memory address of the variable into the HL register, it is essentially pointing to that place in memory, which is similar to how pointers in C and C++ work. When you put parantesis around the HL register you are accessing the byte data at the location in memory. To give you an idea of how working with arrays would work to get the next item in the array you would use (HL+1), then (HL+2), etc. How would you display the register in A?? here is the following code
CODE :
__________________________________________________________________________
LD HL, 0 ;zero/clean out the HL register
LD L, A ;Load A register into lower register of HL register
bcall(_DispHL) ;Display HL register contents
__________________________________________________________________________
The subtract instruction will substract the contents of the specified register from the A register. Here is a following sample code
CODE :
__________________________________________________________________________
LD A, $FF ;Load the hex value $FF into the A register
LD B, $FE ;Load the hex value $FE into the B register
SUB B ;Subtract the contents of B register from A register, aka A=A-B
__________________________________________________________________________
After the following sample code is executed the A register will be equal to 1. The next two instructions are insanely easy to follow INC and DEC. The INC instruction will increment a register by 1, and the DEC instruction will decrement a register by 1.
CODE :
__________________________________________________________________________
DEC HL ;decrement HL by 1
INC HL ;increment HL by 1
__________________________________________________________________________
HL register will not be changed after the execution of the previous sample code. Now the next instruction that will be discussed is the srl instruction, which stands for (Shift Right Logical). This performs a bitwise operation of shifting the bits to the right by 1 on the specified register. Shifting bits to the right on a register is like dividing the contents of the register by 2^n where n is the number of shifts to the right. If we had the following value in the A register $FF then A will look like this in binary:
A: 11111111 //Also equal to 256 in decimal notation
Now if we call the SRL instruction like this
CODE :
__________________________________________________________________________
SRL A
__________________________________________________________________________
All the bits in the A register will be shifted to the right and drop off the right most bit to the carry flag. I will discuss more on flags and their purpose in the 2nd article when I talk about conditional statements, loops, etc. Now the A register looks like this
A: 01111111 //Also equal to 128 in decimal notation or 256/2 which is what happen after the SRL instruction executed
Now let's right a useful application with the knowledge you've accumulated. The application that We will write is one that will determine the first five numbers of the fibonacci sequence. It's important to note that this code would be alot shorter if we had learned loops, which we haven't yet and/or the use of macros and procedures which are also in later articles. Anyway here is the code that will display the first 5 numbers of the fibonaccie squeunce. It is also important to note that (_NewLine) will destroy all registers:(
CODE :
__________________________________________________________________________
;***************************************************************************
;@author - xfelix
;@date - 01/06/10
;@file - fib.z80
;@description - This is a Fibonacci sequence application that will determine the first
; 5 numbers of the Fibonacci sequence. This application is for learning
; how to develop z80 applications for TI83+ Calculator :D
;Compile Instructions: tasm -80 -i -b fib.z80 fib.bin (For linking)
; devpac8x fib (For byte code)
;***************************************************************************
#include "ti83plus.inc"
.list
.org $9d93
.db $bb, $6d
code:
LD A, (firstNum)
LD HL, secondNum
LD B, (HL)
LD HL, $0000
LD L, A
bcall(_DispHL)
bcall(_NewLine) ;Destroy Registers in process of going to new line
LD HL, $0000
LD L, B
bcall(_DispHL)
bcall(_NewLine)
LD A, (firstNum)
LD HL, secondNum
LD B, (HL)
LD HL, $0000
ADD A, B
LD (firstNum), A ;save the third number to first number
LD L, A
bcall(_DispHL)
bcall(_NewLine)
LD A, (firstNum)
LD HL, secondNum
LD B, (HL)
LD HL, $0000
ADD A, B
LD (secondNum), A ;save the fourth number to second number
LD L, A
bcall(_DispHL)
bcall(_NewLine)
LD A, (firstNum)
LD HL, secondNum
LD B, (HL)
LD HL, $0000
ADD A,B
LD L, A
bcall(_DispHL)
bcall(_NewLine)
ret
Data:
firstNum: .db $1
secondNum: .db $1
.end
.end
__________________________________________________________________________
Final Notes
--------------------
This ends the first article of programming in assembly language for the z80 processor on your TI83+ calculator. I hope it was useful and you picked up a thing or two about assembly language. I have listed references below for instruction set and tutorial/ code examples, which should be useful, you don't have to wait for the second article inorder to continue your quest of learning z80 assembler. Once you have been working with assembly language you have my permission to walk proudly amoung your programmer/hacker peers, and can look down on those who don't know assembly language. You are now apart of the z80 scene.
References
-------------------
z80 Heaven tutorials http://z80-heaven.wikidot.com/system:tutorials
z80 instruction set http://nemesis.lonestar.org/computers/tandy/software/apps/m4/qd/opcodes.html
official Zilog manual http://www.zilog.com/docs/z80/um0080.pdf
Introduction to Modern Steganography
This article introduces steganography and explains some of its techniques and methods supported by examples. My objective was to make this post as short as possible while covering all important information. Your comments are welcome for any possible enhancements or for future articles about steganography by me or other people.
Steganography
Steganography is all the techniques used to exchange secret messages without drawing attention. It is the science of hiding information.
Some of the old school methods to hide information are: invisible ink, null ciphers, microdots or the use of pinpricks, deliberate misspelling or slightly different font to mark certain words in messages and maps.
Null cipher
It’s a normal text written in the clear, but includes a hidden message. For example:
"Fishing freshwater bends and saltwater coasts rewards anyone feeling stressed. Resourceful anglers usually find masterful leapers fun and admit swordfish rank overwhelming anyday." [2]
If we take out the third letter in each word, we get: Send Lawyers, Guns, and Money.
Modern steganography refers to hiding information in digital images, audio files or even video. There are many methods and tools to do that. Nevertheless, and to have double protection, secret messages are first encrypted and then hidden using a steganography tool.
The steganographic process can be described with the following formula:
Cover medium + Data to hide + Stego key* = Stego Medium
* Note that if no encryption is added, there is no need for a Stego key.
Hiding messages in pictures
This is usually done by:
1. LSB (Least Significant Bit insertion).
2. Masking & filtering.
3. Algorithms & transformations.
Using LSB is famous, so I will choose it to explain how data can be hidden in images.
LSB is always the last bit on the right-hand side of any binary number. Changing this bit causes the least possible effect to the original value.
In a 24-bit image, there are 3 bytes of data to represent RGB values for every pixel in that image. This implies that we can store/hide 3 bits in every pixel. For example, if the image
has the following bits:
10010101 00001101 11001001
10010110 00001111 11001010
10011111 00010000 11001011
To store 101101101. we replace with the original LSBs like this:
10010101 00001100 11001001
10010111 00001110 11001011
10011111 00010000 11001011
To reveal the stored message, the LSBs are extracted alone from the Stego Medium and combined together.
Hiding messages in audio files
Two known methods to store message in audio files are: Frequency Domain and Time Domain.
In Frequency Domain, a message can be stored in practically unused frequencies of audio files. For instance, In a CD where the sample rate is 44.1 kHz, the highest frequency without aliasing is 22.05 kHz.
Now, because the average peak frequency that an adult can hear is approximately 18 kHz, this leaves 4 kHz of frequency that is "practically unused". This space can then be used to hide a message (a copyright message for example).
In Time Domain, a message can be stored in the LSBs, something similar to what we saw with images. To maintain CD quality, it is important to encode at 16 bits per sample at a rate of 44.1kHz. However, we can also record at 8 bits per sample using the high significant bits (first bits on your left-hand side) and save the other 4 LSBs to hide our message without making any perceptible change to the audio quality.
In a comparison between the two, detecting messages hidden with time domain is harder because it requires more resources. [4]
Watermarking (digital watermarking)
Whenever there is a topic about steganography now a day, Digital Watermarking is also mentioned. It refers to embedding hidden messages as well, but not for the purpose of sending secret information. Instead, Watermarking is usually used for the following:
1. Copyright protection: include ownership information.
2. Copy protection: include instructions to stop data copying devices from making and distributing copies of the original.
3. Prove data authenticity.
4. Tracking: If copies of a file are distributed illegally, the source can be revealed if the master copies had unique watermarks included.
Stego Tools
The following freeware tools have been tested by me on Windows 7 and they work great:
1. 4t HIT Mail Privacy LITE 1.01
2. S-Tools 4.0
To find more tools (commercials and freeware) make use of the following lists as they are the best I found online or do your own googling:
1.http://home.comcast.net/~ebm.md/stego/software.html
2.http://www.jjtc.com/Security/stegtools.htm
Steganalyses and countermeasures
Steganalyses aim to investigate suspected information to determine whether they include any sealed data and reveal the hidden message if exist.
Any unusual patterns (visual or statistical) are usually analyzed to detect suspected information. Hence, any method can be useful, for instance, image editors and hex editors (e.g. HEX Workshop).
Some methods are designed and developed to detect and reveal information hidden by known steganography tools. There are also enhanced and powerful digital forensic analysis
tools such as StegAlyzerSS (Steganography Analyzer Signature Scanner) developed by the Steganography Analysis and Research Center [5].
Conclusion note
The references at the end of this article are quite informative, have a go on them in your free time if you are looking for more details.
References
[1] Introduction to Steganography. [cited 2010 Jan 08]; Available from: http://www.infosyssec.com/infosyssec/Steganography/menu.htm
[2] Johnson, N. F., Duric, Z., Jajodia, S. Information Hiding: Steganography and Watermarking - Attacks and Countermeasures. Kluwer Academic Press. Norwrll, MA, New York, The
Hague, London, 2000.
[3] Gary C. Kessler. Steganography: Hiding Data Within Data. 2001 [cited 2010 Jan 08]; Available from: http://www.garykessler.net/library/steganography.html
[4] Steganography in Signals. [cited 2010 Jan 09]; Available from: http://www.owlnet.rice.edu/~elec301/Projects01/smokey_steg/steg.html
[5] Steganography Analyzer Signature Scanner. [cited 2010 Jan 09]; Available from: http://www.sarc-wv.com/stegalyzerss.aspx
Steganography
Steganography is all the techniques used to exchange secret messages without drawing attention. It is the science of hiding information.
Some of the old school methods to hide information are: invisible ink, null ciphers, microdots or the use of pinpricks, deliberate misspelling or slightly different font to mark certain words in messages and maps.
Null cipher
It’s a normal text written in the clear, but includes a hidden message. For example:
"Fishing freshwater bends and saltwater coasts rewards anyone feeling stressed. Resourceful anglers usually find masterful leapers fun and admit swordfish rank overwhelming anyday." [2]
If we take out the third letter in each word, we get: Send Lawyers, Guns, and Money.
Modern steganography refers to hiding information in digital images, audio files or even video. There are many methods and tools to do that. Nevertheless, and to have double protection, secret messages are first encrypted and then hidden using a steganography tool.
The steganographic process can be described with the following formula:
Cover medium + Data to hide + Stego key* = Stego Medium
* Note that if no encryption is added, there is no need for a Stego key.
Hiding messages in pictures
This is usually done by:
1. LSB (Least Significant Bit insertion).
2. Masking & filtering.
3. Algorithms & transformations.
Using LSB is famous, so I will choose it to explain how data can be hidden in images.
LSB is always the last bit on the right-hand side of any binary number. Changing this bit causes the least possible effect to the original value.
In a 24-bit image, there are 3 bytes of data to represent RGB values for every pixel in that image. This implies that we can store/hide 3 bits in every pixel. For example, if the image
has the following bits:
10010101 00001101 11001001
10010110 00001111 11001010
10011111 00010000 11001011
To store 101101101. we replace with the original LSBs like this:
10010101 00001100 11001001
10010111 00001110 11001011
10011111 00010000 11001011
To reveal the stored message, the LSBs are extracted alone from the Stego Medium and combined together.
Hiding messages in audio files
Two known methods to store message in audio files are: Frequency Domain and Time Domain.
In Frequency Domain, a message can be stored in practically unused frequencies of audio files. For instance, In a CD where the sample rate is 44.1 kHz, the highest frequency without aliasing is 22.05 kHz.
Now, because the average peak frequency that an adult can hear is approximately 18 kHz, this leaves 4 kHz of frequency that is "practically unused". This space can then be used to hide a message (a copyright message for example).
In Time Domain, a message can be stored in the LSBs, something similar to what we saw with images. To maintain CD quality, it is important to encode at 16 bits per sample at a rate of 44.1kHz. However, we can also record at 8 bits per sample using the high significant bits (first bits on your left-hand side) and save the other 4 LSBs to hide our message without making any perceptible change to the audio quality.
In a comparison between the two, detecting messages hidden with time domain is harder because it requires more resources. [4]
Watermarking (digital watermarking)
Whenever there is a topic about steganography now a day, Digital Watermarking is also mentioned. It refers to embedding hidden messages as well, but not for the purpose of sending secret information. Instead, Watermarking is usually used for the following:
1. Copyright protection: include ownership information.
2. Copy protection: include instructions to stop data copying devices from making and distributing copies of the original.
3. Prove data authenticity.
4. Tracking: If copies of a file are distributed illegally, the source can be revealed if the master copies had unique watermarks included.
Stego Tools
The following freeware tools have been tested by me on Windows 7 and they work great:
1. 4t HIT Mail Privacy LITE 1.01
2. S-Tools 4.0
To find more tools (commercials and freeware) make use of the following lists as they are the best I found online or do your own googling:
1.http://home.comcast.net/~ebm.md/stego/software.html
2.http://www.jjtc.com/Security/stegtools.htm
Steganalyses and countermeasures
Steganalyses aim to investigate suspected information to determine whether they include any sealed data and reveal the hidden message if exist.
Any unusual patterns (visual or statistical) are usually analyzed to detect suspected information. Hence, any method can be useful, for instance, image editors and hex editors (e.g. HEX Workshop).
Some methods are designed and developed to detect and reveal information hidden by known steganography tools. There are also enhanced and powerful digital forensic analysis
tools such as StegAlyzerSS (Steganography Analyzer Signature Scanner) developed by the Steganography Analysis and Research Center [5].
Conclusion note
The references at the end of this article are quite informative, have a go on them in your free time if you are looking for more details.
References
[1] Introduction to Steganography. [cited 2010 Jan 08]; Available from: http://www.infosyssec.com/infosyssec/Steganography/menu.htm
[2] Johnson, N. F., Duric, Z., Jajodia, S. Information Hiding: Steganography and Watermarking - Attacks and Countermeasures. Kluwer Academic Press. Norwrll, MA, New York, The
Hague, London, 2000.
[3] Gary C. Kessler. Steganography: Hiding Data Within Data. 2001 [cited 2010 Jan 08]; Available from: http://www.garykessler.net/library/steganography.html
[4] Steganography in Signals. [cited 2010 Jan 09]; Available from: http://www.owlnet.rice.edu/~elec301/Projects01/smokey_steg/steg.html
[5] Steganography Analyzer Signature Scanner. [cited 2010 Jan 09]; Available from: http://www.sarc-wv.com/stegalyzerss.aspx
Introduction to Probabilistic Theory
Introduction
During several of the missions posted on the site here, you may be required to crack a password hash that was created using real-world algorithms such as MD5 and SHA1. There are, however, a few missions in which you are required to exploit a proprietary algorithm that was created by the devs of the mission. These algorithms are intentionally created with a weakness so that you can learn to exploit these weaknesses and later apply those skills to more complex algorithms.
Combinations vs. Permutations
The main focus of this article is based around brute-force cracking, though the principles here can be applied to more efficient methods such as birthday and collision attacks. As you probably already know, the basic idea of a brute-force attack is to try every possible password in order to find the desired key. Though the idea is simple enough, the implementation can be much trickier. While you are guaranteed to eventually get the right answer, brute-force is the most inefficient way to go about it.
For example, if you know that the password you are trying to crack has no more than 15 letters (lowercase only), this means that there are over 1.67 septillion different passwords. These passwords make up what is called the keyspace, or the total number of possible passwords. My laptop crunches about 5.5 to 6 million hashes per second per Cain and Abel. With the keyspace mentioned above, it will take just under 8.9 million years try every password, and that's just with lowercase letters! If you include capital letters and numbers, the computational time required skyrockets to over 4 trillion years, or 290 times the age of the universe. Clearly, we need to reduce the keyspace, but how?
This is where permutations and combinations come in. Though the two phrases are often used interchangeably, they actually have two very different meanings. A "permutation" is a list of every possible sequence of a given set where order matters. Basically, it is the basis of most brute-force attacks. If you think of a bike lock with 3 numbers from 0 to 9, you can easily figure out how many different numbers there are by raising 10 (the number of choices per slot) to the power of 3 (the number of slots), just as we got our keyspace above (26 letters per slot, 15 slots). This is what you usually assume you must do when brute-forcing a password.
Using an example from Extended Basic 11, a password is calculated by assigning each letter, a to z, a prime number. When the user inputs their password, each letter is replaced with the corresponding prime and then all the numbers are multiplied together to form the hash. Since the hash is comprised of prime numbers, the only possible solution is to multiply the correct prime factors together. The easiest way to solve this would be to write a program to decompose the hash into its prime factors, but since the point of the article is to discuss brute-force attacks, we will take that route (additionally, nearly every hashing algorithm is one-way, making decomposition of the hash into its original state impossible).
(It is important to note that the example that follows is NOT how you solve ExtBasic 11). For this example, the passphrase we are trying to find is "zzz". From our table, the letter "z" has a prime value of 101. The corresponding hash is:
CODE :
101*101*101 = 1030301 (hey, it's a palindrome!)
Assuming we know that the password has three letters, this gives us a keyspace of 17,576 (26^3). With this in mind, we will begin our brute-force attack, starting with the string "aaa".
CODE :
aaa = 2*2*2 = 8 != 1030301
aab = 2*2*3 = 12 != 1030301
aac = 2*2*5 = 20 ! = 1030301
.
.
.
aaz = 2*2*101 = 404 != 1030301
Having reached the end of the third column, we rollover the second column and begin again.
CODE :
aba = 2*3*2 = 12 !=1030301
Hey, wait a second…we've already tried the number 12! Looking at the password and the algorithm, it's pretty apparent why this happened. Even though the algorithm uses prime numbers, it also uses multiplication, which is commutative; that is, a*b*c = a*c*b = b*c*a and so on. So that means since we've already tried "aab", we don't have to try "aba" or "baa", since they will just give us the same hash again. This also applies to all the other passwords we've already tried, "aca" and "caa", all the way to "aza" and "zaa". So for the first column we did, for every password we tried, we were actually trying three. Therefore, without any additional computation, we just reduced our keyspace by two-thirds!
This is where "combinations" come in. A combination is basically the same as a permutation with one big difference; in a combination, order doesn't matter! While it may seem rather insignificant at first, the difference between a combination and a permutation is vast.
Take the lottery, for example. An oft-quoted statistic lists extremely lower odds of winning the lottery, usually on the order of 1 in several billion, sometimes even lower. If the lottery we play has 45 numeric balls and we are required to pick six, many people's first instinct is to assume the total number of sequences is 45^6 = 8.3 billion possible lottery numbers. But this assumption makes two important mistakes.
First, it doesn't take into account that once a number is drawn for our lottery, it cannot be drawn again (you can't have two 45's drawn, for example). In probabilistic theory, this is called a "permutation without replacement." So that means for each ball we pull, the next slot has a fewer pool of numbers to draw from; the first slot has 45 balls, the second slot has 44 balls, and so on. This reduces the number of possible sequences to 45*44*43*42*41*40 = 5.8 billion sequences. Though we've made a dent, it's still pretty long odds.
The second and more profound mistake made is that we calculated the lottery numbers as permutations and not combinations. If you've ever played the lottery, you know that order doesn't matter; 1-2-3-4-5-6 is the same as 6-5-4-3-2-1. So knowing that, we can greatly reduce the number possible lottery numbers. To calculate the number of combinations without replacement, we use the following equation:
CODE :
n!
---------
k!(n-k)!
Where "n" is the number of choices and "k" is the number of slots. Since there are 45 numbers and 6 slots, this comes out to be just over 8.1 million combinations. While the odds are still extremely long, we just improved our odds by over 1,000!
Applying this to our password example, we now realize that we don't have to test every permutation, just every combination. Since we can have more than one occurrence of the same letter, we have to figure out the combinations with replacement. The formula is a bit more complex, however:
CODE :
(n+k-1)!
---------
k!(n-1)!
Plugging in our numbers, we discover there are only 3,276 possible passwords, only 18% of our original keyspace! More importantly, this difference increases with the length of the password; to demonstrate, imagine if we had a password 15 letters long:
CODE :
Permutation:
26^15 = 1.67e21 permutations
This would take 8.9 million years to crack.
Combination:
(26 + 15 – 1)!
-------------- = 40.2 billion combinations
15! (26 – 1)!
This would take 1.86 hours to crack.
Conclusion
As you can see, reducing your keyspace can have a profound impact on your ability to crack hashes. Though ostensibly modern hash algorithms don't use such easily exploitable methods and will require you to test permutations instead of just combinations, the principle behind reducing the keyspace remains the same.
source : http://www.hackthissite.org
During several of the missions posted on the site here, you may be required to crack a password hash that was created using real-world algorithms such as MD5 and SHA1. There are, however, a few missions in which you are required to exploit a proprietary algorithm that was created by the devs of the mission. These algorithms are intentionally created with a weakness so that you can learn to exploit these weaknesses and later apply those skills to more complex algorithms.
Combinations vs. Permutations
The main focus of this article is based around brute-force cracking, though the principles here can be applied to more efficient methods such as birthday and collision attacks. As you probably already know, the basic idea of a brute-force attack is to try every possible password in order to find the desired key. Though the idea is simple enough, the implementation can be much trickier. While you are guaranteed to eventually get the right answer, brute-force is the most inefficient way to go about it.
For example, if you know that the password you are trying to crack has no more than 15 letters (lowercase only), this means that there are over 1.67 septillion different passwords. These passwords make up what is called the keyspace, or the total number of possible passwords. My laptop crunches about 5.5 to 6 million hashes per second per Cain and Abel. With the keyspace mentioned above, it will take just under 8.9 million years try every password, and that's just with lowercase letters! If you include capital letters and numbers, the computational time required skyrockets to over 4 trillion years, or 290 times the age of the universe. Clearly, we need to reduce the keyspace, but how?
This is where permutations and combinations come in. Though the two phrases are often used interchangeably, they actually have two very different meanings. A "permutation" is a list of every possible sequence of a given set where order matters. Basically, it is the basis of most brute-force attacks. If you think of a bike lock with 3 numbers from 0 to 9, you can easily figure out how many different numbers there are by raising 10 (the number of choices per slot) to the power of 3 (the number of slots), just as we got our keyspace above (26 letters per slot, 15 slots). This is what you usually assume you must do when brute-forcing a password.
Using an example from Extended Basic 11, a password is calculated by assigning each letter, a to z, a prime number. When the user inputs their password, each letter is replaced with the corresponding prime and then all the numbers are multiplied together to form the hash. Since the hash is comprised of prime numbers, the only possible solution is to multiply the correct prime factors together. The easiest way to solve this would be to write a program to decompose the hash into its prime factors, but since the point of the article is to discuss brute-force attacks, we will take that route (additionally, nearly every hashing algorithm is one-way, making decomposition of the hash into its original state impossible).
(It is important to note that the example that follows is NOT how you solve ExtBasic 11). For this example, the passphrase we are trying to find is "zzz". From our table, the letter "z" has a prime value of 101. The corresponding hash is:
CODE :
101*101*101 = 1030301 (hey, it's a palindrome!)
Assuming we know that the password has three letters, this gives us a keyspace of 17,576 (26^3). With this in mind, we will begin our brute-force attack, starting with the string "aaa".
CODE :
aaa = 2*2*2 = 8 != 1030301
aab = 2*2*3 = 12 != 1030301
aac = 2*2*5 = 20 ! = 1030301
.
.
.
aaz = 2*2*101 = 404 != 1030301
Having reached the end of the third column, we rollover the second column and begin again.
CODE :
aba = 2*3*2 = 12 !=1030301
Hey, wait a second…we've already tried the number 12! Looking at the password and the algorithm, it's pretty apparent why this happened. Even though the algorithm uses prime numbers, it also uses multiplication, which is commutative; that is, a*b*c = a*c*b = b*c*a and so on. So that means since we've already tried "aab", we don't have to try "aba" or "baa", since they will just give us the same hash again. This also applies to all the other passwords we've already tried, "aca" and "caa", all the way to "aza" and "zaa". So for the first column we did, for every password we tried, we were actually trying three. Therefore, without any additional computation, we just reduced our keyspace by two-thirds!
This is where "combinations" come in. A combination is basically the same as a permutation with one big difference; in a combination, order doesn't matter! While it may seem rather insignificant at first, the difference between a combination and a permutation is vast.
Take the lottery, for example. An oft-quoted statistic lists extremely lower odds of winning the lottery, usually on the order of 1 in several billion, sometimes even lower. If the lottery we play has 45 numeric balls and we are required to pick six, many people's first instinct is to assume the total number of sequences is 45^6 = 8.3 billion possible lottery numbers. But this assumption makes two important mistakes.
First, it doesn't take into account that once a number is drawn for our lottery, it cannot be drawn again (you can't have two 45's drawn, for example). In probabilistic theory, this is called a "permutation without replacement." So that means for each ball we pull, the next slot has a fewer pool of numbers to draw from; the first slot has 45 balls, the second slot has 44 balls, and so on. This reduces the number of possible sequences to 45*44*43*42*41*40 = 5.8 billion sequences. Though we've made a dent, it's still pretty long odds.
The second and more profound mistake made is that we calculated the lottery numbers as permutations and not combinations. If you've ever played the lottery, you know that order doesn't matter; 1-2-3-4-5-6 is the same as 6-5-4-3-2-1. So knowing that, we can greatly reduce the number possible lottery numbers. To calculate the number of combinations without replacement, we use the following equation:
CODE :
n!
---------
k!(n-k)!
Where "n" is the number of choices and "k" is the number of slots. Since there are 45 numbers and 6 slots, this comes out to be just over 8.1 million combinations. While the odds are still extremely long, we just improved our odds by over 1,000!
Applying this to our password example, we now realize that we don't have to test every permutation, just every combination. Since we can have more than one occurrence of the same letter, we have to figure out the combinations with replacement. The formula is a bit more complex, however:
CODE :
(n+k-1)!
---------
k!(n-1)!
Plugging in our numbers, we discover there are only 3,276 possible passwords, only 18% of our original keyspace! More importantly, this difference increases with the length of the password; to demonstrate, imagine if we had a password 15 letters long:
CODE :
Permutation:
26^15 = 1.67e21 permutations
This would take 8.9 million years to crack.
Combination:
(26 + 15 – 1)!
-------------- = 40.2 billion combinations
15! (26 – 1)!
This would take 1.86 hours to crack.
Conclusion
As you can see, reducing your keyspace can have a profound impact on your ability to crack hashes. Though ostensibly modern hash algorithms don't use such easily exploitable methods and will require you to test permutations instead of just combinations, the principle behind reducing the keyspace remains the same.
source : http://www.hackthissite.org
Monday, February 8, 2010
CIA, PayPal under bizarre SSL assault
The Central Intelligence Agency, PayPal, and hundreds of other organizations are under an unexplained assault that's bombarding their websites with millions of compute-intensive requests.
The "massive" flood of requests is made over the websites' SSL, or secure-sockets layer, port, causing them to consume more resources than normal connections, according to researchers at Shadowserver Foundation, a volunteer security collective. The torrent started about a week ago and appears to be caused by recent changes made to a botnet known as Pushdo.
"What do I mean by massive? I mean you are likely seeing an unexpected increase in traffic by several million hits spread out across several hundred thousand IP addresses," Shadowserver' Steven Adair wrote. "This might be a big deal if you're used to only getting a few hundred or thousands of hits a day or you don't have unlimited bandwidth."
Shadowserver has identified 315 websites that are the recipients of the SSL assault. In addition to cia.gov and paypal.com, other sites include yahoo.com, americanexpress.com, and sans.org.
It's not clear why Pushdo has unleashed the torrent. Infected PCs appear to initiate the SSL connections, along with a bit of junk, disconnect and then repeat the cycle. They don't request any resources from the website or do anything else.
"We find it hard to believe this much activity would be used to make the bots blend in with normal traffic, but at the same time it doesn't quite look like a DDoS either," Adair wrote.
Security mavens aren't sure what targeted sites can do to thwart the attacks. Changing IP addresses may provide a temporary reprieve. Adair asks those with better mitigation techniques to contact him. The Shadowserver advisory is here.
The "massive" flood of requests is made over the websites' SSL, or secure-sockets layer, port, causing them to consume more resources than normal connections, according to researchers at Shadowserver Foundation, a volunteer security collective. The torrent started about a week ago and appears to be caused by recent changes made to a botnet known as Pushdo.
"What do I mean by massive? I mean you are likely seeing an unexpected increase in traffic by several million hits spread out across several hundred thousand IP addresses," Shadowserver' Steven Adair wrote. "This might be a big deal if you're used to only getting a few hundred or thousands of hits a day or you don't have unlimited bandwidth."
Shadowserver has identified 315 websites that are the recipients of the SSL assault. In addition to cia.gov and paypal.com, other sites include yahoo.com, americanexpress.com, and sans.org.
It's not clear why Pushdo has unleashed the torrent. Infected PCs appear to initiate the SSL connections, along with a bit of junk, disconnect and then repeat the cycle. They don't request any resources from the website or do anything else.
"We find it hard to believe this much activity would be used to make the bots blend in with normal traffic, but at the same time it doesn't quite look like a DDoS either," Adair wrote.
Security mavens aren't sure what targeted sites can do to thwart the attacks. Changing IP addresses may provide a temporary reprieve. Adair asks those with better mitigation techniques to contact him. The Shadowserver advisory is here.
Most consumers reuse banking passwords
The majority of online banking customers reuse their online-banking login credentials on other websites, according to a new survey on password insecurity.
Online security firm Trusteer reports that 73 per cent of bank customers use their online account password to access at least one other, less sensitive website. Even worse, around half (47 per cent) use the same online banking username and password for other website logins.
This dismal password security practice means that if cybercrooks trick a user into giving away his login credentials for a social networking site, for example, they stand a very good chance of getting into webmail and online banking accounts for the same person, potentially bringing about crippling financial losses as a result.
Trusteer's findings are pulled from a sample of users of its Rapport browser security service. This is offered through online banks in Europe and North America to their customers as a defence against phishing attacks. Web users outfitted with Trusteer's Rapport browser security plug-in are prevented from sending login details to fraudsters, even if they visit and attempt to enter data into a known phishing site.
The survey (PDF) also found that when a bank permits users to pick their own user ID, 65 per cent will re-use this username with a non-financial website, a figure that drops to 45 per cent even if a bank chooses the user ID for its customers.
Trusteer expressed surprise that consumers were so lax on password security, even when it comes to online banking websites. Here at El Reg, we'd be surprised if anyone produced a survey or research indicating that password security among consumers and enterprise users was anything better than dreadful.
"Using stolen credentials remains the easiest way for criminals to bypass the security measures implemented by banks to protect their online applications, so we wanted to see how often users re-purpose their financial service usernames and passwords," explained Amit Klein, CTO of Trusteer. "Our findings were very surprising, and reveal that consumers are not aware, or are choosing to ignore, the security implications of reusing their banking credentials on multiple websites."
Trusteer advised consumers to keep at least three sets of credentials: one that's only used with financial websites, the second for websites that hold information about a user's identity, and the third set for other less sensitive websites. That's certainly a start, but web users also need to think about using hard-to-guess passwords able to withstand brute force dictionary password cracking attacks commonly used by even minimally-skilled cybercroooks.
Top tips from Microsoft and Sophos outline tactics for coming up with hard-to-break but straightforward enough to remember website login credentials.
from : security Focus
Online security firm Trusteer reports that 73 per cent of bank customers use their online account password to access at least one other, less sensitive website. Even worse, around half (47 per cent) use the same online banking username and password for other website logins.
This dismal password security practice means that if cybercrooks trick a user into giving away his login credentials for a social networking site, for example, they stand a very good chance of getting into webmail and online banking accounts for the same person, potentially bringing about crippling financial losses as a result.
Trusteer's findings are pulled from a sample of users of its Rapport browser security service. This is offered through online banks in Europe and North America to their customers as a defence against phishing attacks. Web users outfitted with Trusteer's Rapport browser security plug-in are prevented from sending login details to fraudsters, even if they visit and attempt to enter data into a known phishing site.
The survey (PDF) also found that when a bank permits users to pick their own user ID, 65 per cent will re-use this username with a non-financial website, a figure that drops to 45 per cent even if a bank chooses the user ID for its customers.
Trusteer expressed surprise that consumers were so lax on password security, even when it comes to online banking websites. Here at El Reg, we'd be surprised if anyone produced a survey or research indicating that password security among consumers and enterprise users was anything better than dreadful.
"Using stolen credentials remains the easiest way for criminals to bypass the security measures implemented by banks to protect their online applications, so we wanted to see how often users re-purpose their financial service usernames and passwords," explained Amit Klein, CTO of Trusteer. "Our findings were very surprising, and reveal that consumers are not aware, or are choosing to ignore, the security implications of reusing their banking credentials on multiple websites."
Trusteer advised consumers to keep at least three sets of credentials: one that's only used with financial websites, the second for websites that hold information about a user's identity, and the third set for other less sensitive websites. That's certainly a start, but web users also need to think about using hard-to-guess passwords able to withstand brute force dictionary password cracking attacks commonly used by even minimally-skilled cybercroooks.
Top tips from Microsoft and Sophos outline tactics for coming up with hard-to-break but straightforward enough to remember website login credentials.
from : security Focus
Sunday, February 7, 2010
Kaspersky Lab and BitDefender websites hit by hackers
The websites of two major providers of security products have been hit by hackers.
The website of Russian IT security provider Kaspersky Lab was hit at the weekend by a Romanian ‘white-hat’ hacker.
A group calling itself ‘the Romanian Security Team’ claimed that the hackers achieved full access to the database supporting the websites – which includes customer data – by simply altering a parameter in the URLs. They could also perform SQL injections to remotely introduce harmful code into the database.
The group also claimed to have hit the Portuguese site of US anti-virus provider BitDefender, with the personal details of thousands of users viewed. The hackers said that they alerted the two companies of the security flaw and did not expose any of the data they found.
Kaspersky Lab said in a statement: “On Saturday February 7 2009, a vulnerability was detected on a subsection of the usa.kaspersky.com domain when a hacker attempted an attack on the site.
“The site was only vulnerable for a very brief period, and upon detection of the vulnerability we immediately took action to roll back the subsection of the site and the vulnerability was eliminated within 30 minutes of detection. The vulnerability wasn’t critical and no data was compromised from the site.”
Gunter Ollmann, chief security strategist at IBM’s Internet Security Systems, said: “I hope that Kaspersky administrators fix this vulnerability rather quickly as they no doubt have a large customer base, and it would appear that all those customers are now exposed
“On top of that, this type of critical flaw can probably be used to usurp legitimate purchases and renewals of their products - which could include the linking to malicious and backdoored versions of their software - thereby infecting those very same customers that were seeking protection from malware in the first place.â€
The website of Russian IT security provider Kaspersky Lab was hit at the weekend by a Romanian ‘white-hat’ hacker.
A group calling itself ‘the Romanian Security Team’ claimed that the hackers achieved full access to the database supporting the websites – which includes customer data – by simply altering a parameter in the URLs. They could also perform SQL injections to remotely introduce harmful code into the database.
The group also claimed to have hit the Portuguese site of US anti-virus provider BitDefender, with the personal details of thousands of users viewed. The hackers said that they alerted the two companies of the security flaw and did not expose any of the data they found.
Kaspersky Lab said in a statement: “On Saturday February 7 2009, a vulnerability was detected on a subsection of the usa.kaspersky.com domain when a hacker attempted an attack on the site.
“The site was only vulnerable for a very brief period, and upon detection of the vulnerability we immediately took action to roll back the subsection of the site and the vulnerability was eliminated within 30 minutes of detection. The vulnerability wasn’t critical and no data was compromised from the site.”
Gunter Ollmann, chief security strategist at IBM’s Internet Security Systems, said: “I hope that Kaspersky administrators fix this vulnerability rather quickly as they no doubt have a large customer base, and it would appear that all those customers are now exposed
“On top of that, this type of critical flaw can probably be used to usurp legitimate purchases and renewals of their products - which could include the linking to malicious and backdoored versions of their software - thereby infecting those very same customers that were seeking protection from malware in the first place.â€
The websites of two major providers of security products have been hit by hackers.
A new Valentine’s Day spam email has been detected by Websense as containing a Waledac variant. Websense Security Labs has reported to have seen several fake Valentine’s Day sites serving up malware recently, with an increase in adult dating and ‘healthcare’ related email spam released to mark the occasion. Carl Leonard, Websense threat research manager, claimed that it works by the user opening the URL in the spammed message and being redirected to a site with two puppies and a love heart to give a Valentine’s theme. The user is then enticed to download a Valentine’s kit to prepare a present for a loved one, which is a new Waledac variant.
Leonard said: “The usual suspects have emerged as expected, with Valentine spam emails and Trojans. The public are becoming more aware of these and it is getting harder to trick people this way. Cybercriminals are also taking their efforts to social networks, given its rising popularity and potential to manipulate the user through ‘friend’ messages.
“Organised criminal units have a long history of timing their attacks to coincide with popular occasions in order to achieve maximum success. Valentine’s Day 2009 is a day that is similarly marked on the criminals’ calendar for targeted attacks.â€
Websense has warned of three key signs of fake sites: ‘Broken Hearts’ sites show colourful images such as puppy dogs or a picture of 12 pretty hearts and ask ‘Guess, which one is for you?’. The web page however is one big image and a single click from a tricked user commences the download of Trojans named “onlyyou.exe†or “youandme.exeâ€, which can connect to remote websites to receive commands and send information about the compromised system.
‘I am your friend’ uses social networking tricks to get users to visit fake sites, with Websense claiming that a popular technique at the moment is spam email pretending to originate from social networking sites – complete with love hearts and cartoon characters. Clicking through to the link would download a Trojan designed to steal log in credentials for banking sites.
Seventy per cent of the top 100 most popular websites either hosted malicious content or contained a masked redirect to lure unsuspecting victims from legitimate sites to malicious sites. Specially created malicious sites are in decline as cybercriminals switch to compromising ‘trusted’ websites. Websense claimed that as there is increased confidence in shopping and researching online - a lot of which happens whilst in the office – people are turning to the internet to order flowers, chocolates and other gifts and cybercriminals are compromising these sites and stealing data.
Leonard said: “The underground economy is positively flourishing as companies fail to keep up with security technology. Criminals are taking advantage of the growing number of Web 2.0 properties, which allows user generated content. More than ever we’re seeing websites injected with links to direct users to malicious and compromised sites.
“Since many email security systems lack web intelligence, spammers have also stepped up email campaigns which contain links to malicious web pages. It’s clear that businesses need security with real-time protection, but until this becomes the norm – cybercriminals will continue stealing data and breaking hearts.â€
source : http://www.hacking-news.com/
Leonard said: “The usual suspects have emerged as expected, with Valentine spam emails and Trojans. The public are becoming more aware of these and it is getting harder to trick people this way. Cybercriminals are also taking their efforts to social networks, given its rising popularity and potential to manipulate the user through ‘friend’ messages.
“Organised criminal units have a long history of timing their attacks to coincide with popular occasions in order to achieve maximum success. Valentine’s Day 2009 is a day that is similarly marked on the criminals’ calendar for targeted attacks.â€
Websense has warned of three key signs of fake sites: ‘Broken Hearts’ sites show colourful images such as puppy dogs or a picture of 12 pretty hearts and ask ‘Guess, which one is for you?’. The web page however is one big image and a single click from a tricked user commences the download of Trojans named “onlyyou.exe†or “youandme.exeâ€, which can connect to remote websites to receive commands and send information about the compromised system.
‘I am your friend’ uses social networking tricks to get users to visit fake sites, with Websense claiming that a popular technique at the moment is spam email pretending to originate from social networking sites – complete with love hearts and cartoon characters. Clicking through to the link would download a Trojan designed to steal log in credentials for banking sites.
Seventy per cent of the top 100 most popular websites either hosted malicious content or contained a masked redirect to lure unsuspecting victims from legitimate sites to malicious sites. Specially created malicious sites are in decline as cybercriminals switch to compromising ‘trusted’ websites. Websense claimed that as there is increased confidence in shopping and researching online - a lot of which happens whilst in the office – people are turning to the internet to order flowers, chocolates and other gifts and cybercriminals are compromising these sites and stealing data.
Leonard said: “The underground economy is positively flourishing as companies fail to keep up with security technology. Criminals are taking advantage of the growing number of Web 2.0 properties, which allows user generated content. More than ever we’re seeing websites injected with links to direct users to malicious and compromised sites.
“Since many email security systems lack web intelligence, spammers have also stepped up email campaigns which contain links to malicious web pages. It’s clear that businesses need security with real-time protection, but until this becomes the norm – cybercriminals will continue stealing data and breaking hearts.â€
source : http://www.hacking-news.com/
Subscribe to:
Posts (Atom)
