Well.. after spending 5 days in Barcelona with my mother, sister and girlfriend i feel like i've spent there just a couple of minutes.

 

We had such a great time that I would love to repeat it again very soon... Barcelona itself is one of the most beautiful cities I've ever been.. it has everything.. on one side you have the mountains, on the other side you have the beach.. you have exquisite food (have a look at the photos if you don't believe me), excellent weather (18~20 degrees and we are in November), and a really rich mix of cultures.

 

So, if you have the opportunity to go there for a weekend don't hesistate to do so.. you will not regret it!

 

You could find the photos here: http://fcerullo.spaces.live.com/photos

 

Apparently MSN Music is not compatible with MS Zune (yep, don't start laughing).

 

An article from the BBC states the following:

The problem has arisen because tracks from the MSN Music site are compatible with the specifications of the Plays For Sure initiative.

This was intended to re-assure consumers as it guaranteed that music bought from services backing it would work with players that supported it. MSN Music, Napster, AOL Music Now and Urge all backed Plays For Sure as did many players from hardware makers such as Archos, Creative, Dell and Iriver.

If you want to read the entire article please follow this link:

http://news.bbc.co.uk/1/hi/technology/6120272.stm

If you are interested in cybercrime and forensics i would recommend to have a look at this article (a bit old though) from CNN which interview two experts in the subject.

 

 

The competitor for Ipod Video has arrived and it's called Microsoft Zune... I will see if i could grab one and have my personal opinion

 

Based on the features sounds really promising:

 

Category	Zune	iPod 30GB
Price	$249	$249
Storage	30 GB	30 GB
Wi-Fi	YES	none
File Sharing	YES	none
Landscape Mode	YES	none
Portrait Mode	YES	YES
FM Tuner	YES	none
Preloaded Audio	YES	none
Preloaded Video	YES	none
Battery Life	14 hrs	14 hrs
Preloaded Virus	none	RavMonE.exe
Custom Background	YES	none
Gapless Playback	YES	YES
Manufacturer	Japanese	Chinese
Screen Size	3"	2.5"
USB	2.0	2.0
Colors	White, Black, Brown	White, Black
Scroll Wheel	none	YES
Tactile Control	YES	none
Online Service	Zune Marketplace	iTunes
Unlimited Downlaods	$14.99/month	none
Podcast Playback	YES	YES
Battery	Li-Ion	Li-Ion
XBOX Marketplace Integration	YES	none
Unique Online Tag	Zunetag	none
3rd Party Accessories	YES	YES
Social Networking	YES	none
Weight	5.6 ounces	4.8 ounces
Width	2.4"	2.4"
Height	4.4"	4.1"
Depth	0.58"	0.43"
Official Insider News Blog(s)	YES	none
User Forum	Zune Scene	iLounge
Compatibility	PC	Mac, PC
Replaceable Batteries	NO	NO
Semi-Transparent Case	YES	none
Special Edition	Union	U2
Vendor	Microsoft	Apple
Other "Brand Family" Products	none	Nano, Shuffle
Headphones	earbud	earbud

Web search leader Google Inc.'s chief executive, Eric Schmidt, sees a future where mobile phones are free to consumers who accept watching targeted forms of advertising.

 

This is an interesting concept to be watched very carefully... besides the fact that I would love to receive a fancy phone for free, there are severals questions that come to my mind:

 

- Who is going to be the provider of this service? Google?

- Are we going towards a monopolization of phone companies?

- Are there any risks that the advertisement model become invasive and "advertisers" could have a look at your bookmarks, frequently visited sites, etc to give you a "targeted" advertising?

 

If you want to read the whole story please click here: http://money.cnn.com/2006/11/11/technology/bc.tech.google2.reut/index.htm?postversion=2006111122

Hi,

 

Last weekend i spent sime time doing retro research at Youtube and i've found plenty of stuff from my childhood.

 

Here are some of the videos:

 

Heidi - http://www.youtube.com/watch?v=8XXwDMnD3iw

He-Man y She-Ra - Intro - http://www.youtube.com/watch?v=hSIayqK4mJU

She-Ra - http://www.youtube.com/watch?v=xBjlbtRKdvI&mode=related&search=

Gi-Joe http://www.youtube.com/watch?v=yYLO7GOR6uo&mode=related&search=

Kimba - http://www.youtube.com/watch?v=sKYgv2cpI1k&mode=related&search=

Jem and the Holograms - http://www.youtube.com/watch?v=q2ZwDr5P8hI&mode=related&search=

Speedracer - http://www.youtube.com/watch?v=n6_gLiQpHwM&mode=related&search=

Thundercats - http://www.youtube.com/watch?v=6rDLRsKDLAQ&mode=related&search=

Mazinger Z - http://www.youtube.com/watch?v=Eq-Qw6NJYK0&mode=related&search=

 

And finally Robotech - http://www.youtube.com/watch?v=P39cFXRU8uU

 

They made me feel younger again for a second... if you know more please post them!

 

Apparently someone made some posts at Google Video a couple of days ago which contained a mass-mailing worm called W32Kasper.A@mm.

 

It has impacted 50.000 users and nowadays the issue has been solved and a formal apologize to the users was made.

 

If by any chance you think you got infected please download Norton AntiVirus software for free from the Google pack,

http://pack.google.com/intl/en/pack_installer.html?nopers

This is the second big mistake made by Google in terms of security... let's hope it doesn;t happen again.

I've found in one of Symantec internal pages these 19 Sins that every developer should avoid when developing applications. It is an extract from a book called by the same name which you could buy at Amazon here:

 

 

Worth the reading if you are into Security...

 

Sin 1: Buffer Overruns

• DO carefully check your buffer accesses by using safe string and buffer handling functions.
• DO you compiler based defenses such as /GS or /Analyze.
• DO use operating system level buffer overrun defenses such as DEP and PaX.
• DO understand what data the attacker controls, and manage that data safely in your code.
• DO NOT think that compiler and O/S defenses are sufficient. They are not; they are simply extra defenses.
• DO NOT create new code that uses unsafe functions.
• CONSIDER updating your C/C++ complier since the compiler vendors add more defenses to the generated code.
• CONSIDER removing unsafe functions from old code over time.
• CONSIDER using C++ string and container classes rather than low level C string functions.

Sin 2: Format String Problems

• DO use fixed format strings, or format strings from a trusted source.
• DO check and limit locale requests to valid values.
• DO NOT pass user input directly as the format string to formating functions.
• CONSIDER using high level languages that tend to be less vulnerable to this issue.

Sin 3: Integer Overflows

• DO check all calculations used to determine memory allocations to check that the arithmetic cannot overflow.
• DO check all calculations used to determine array indexes to check that the arithmetic cannot overflow.
• DO use unsigned integers for array offsets and memory allocation sizes.
• DO NOT think languages other than C/C++ are immune to integer overflows.

Sin 4: SQL Injection

• DO understand the database you use. Does it support stored procedures? What is the comment operator? Does it allow the attacker to call extended functionality?
• DO check the input for validity and trustworthiness.
• DO use parameterized queries or prepared statements, placeholders or parameter binding to build SQL statements.
• DO store the database connection information in a location outside of the application, such as an appropriately protected configuration file or the Windows registry.
• DO NOT simply strip out 'bad words'. There are often a myriad or variants you will not detect.
• DO NOT use trusted input to build SQL statements.
• DO NOT use string concatenation to build SQL statements even when calling stored procedures. Stored procedures help, but they do not solve the entire problem.
• DO NOT use string concatenation to build SQL statements within stored procedures.
• DO NOT execute untrusted parameters within stored procedures.
• DO NOT simply double-up single and double quote characters.
• DO NOT connect to the database using a highly privileged account such as sa or root.
• DO NOT embed the database login password in the application or connection string.
• DO NOT store the database configuration information in the web root directory.
• CONSIDER removing all access to all user-defined tables in the database, and granting access only through stored procedures. Then build the query string using the store procedure and parameterized queries.

Sin 5: Command Injection

• DO perform input validation on all input before passing it to a command processor.
• DO handle the failure securely if an input validation check fails.
• DO NOT pass unvalidated input to any command processor, even if the intent is that the input will just be data.
• DO NOT use the deny list approach, unless you are 100 percent sure you are accounting for all possibilities.
• CONSIDER avoiding regular expressions for input validation; instead write simple and clear validators by hand.

Sin 6: Failing to Handle Errors

• DO check the return value of every security related function.
• DO check the return value of every function that changes a user setting or a machine wide setting.
• DO make every attempt to recover from error conditions gracefully, to help avoid denial of service problems.
• DO NOT catch all exceptions without a very good reason, as you may be masking errors in the code.
• DO NOT leak error information to untrusted users.

Sin 7: Cross Site Scripting

• DO check all web based input for validity and trustworthiness.
• DO HTML encode all output originating from user input.
• DO NOT echo web based input without checking for validity first.
• DO NOT store sensitive data in cookies.
• CONSIDER using as many extra defenses as possible.

Sin 8: Failing to Protect Network Traffic

• DO perform ongoing message authentication for all network traffic your application produces.
• DO use a strong initial authentication mechanism.
• DO encrypt all data for which privacy is a concern. Err on the side of privacy.
• DO use SSL/TLS for all your on-the-wire crypto needs, if at all possible. It works!
• DO NOT ignore the security of your data on the wire.
• DO NOT hardcode keys, and don't think that XORing with a fixed string is an encryption mechanism.
• **DO NOT **hesitate to encrypt data for efficiency reasons. Ongoing encryption is cheap.
• CONSIDER using network level technologies to further reduce exposure whenever is makes sense, such as firewalls, VPNs, and load balancers.

Sin 9: Use of Magic URLs and Hidden Form Fields

• DO test all web input, including forms with malicious input.
• DO understand the strengths and weaknesses of your approach if you're not using cryptographic primitives to solve some of these issues.
• DO NOT embed confidential data in any HTTP or HTML construct, such as the URL, cookie, or form, if the channel is not secured using an encryption technology such as SSL, TLS or IPSec, or it uses application level cryptographic defenses.
• DO NOT trust any data, confidential or not, in a web form, because malicious users can easily change the data to any value they like, regardless of SSL use or not.
• DO NOT think the application is safe just because you plan to use cryptography; attackers will attack the system in other ways. For example, attackers won't attempt to guess cryptographically random numbers; they'll try to view them.

Sin 10: Improper Use of SSL and TLS

• DO use the latest version of SSL/TLS available, in order of preference. TLS1.1, TLS1.0, and SSL3.
• DO use a certificate allow list, if appropriate.
• DO ensure that, before you send data, the peer certificate is traced back to a trusted CA and is within its validity period.
• DO check that the expected hostname appears in a proper field of the peer certificate.
• DO NOT use SSL2. It has serious cryptographic weaknesses.
• DO NOT rely on the underlying SSL/TLS library to properly validate a connection, unless you are using HTTPS.
• DO NOT //only// check the name (for example the DN) in a certificate. Anyone can create a certificate and add any name they wish to it.
• CONSIDER using an OCSP responder when validating certificates in a trust chain to ensure that the certificate hasn't been revoked.
• CONSIDER downloading CRLs once the present CRLs expire and using them to further validate certificates in a trust chain.

Sin 11: Use of Weak Password Based Systems

• DO ensure that passwords are not unnecessarily snoopable over the wire when authenticating (for instance, do this by tunneling the protocol over SSL/TLS).
• DO give only a single message for failed login attempts, even when there are different reasons for failure.
• DO log failed password attempts (but not the password).
• DO use strong, salted cryptographic one-way function based on a hash for password storage.
• DO provide a secure mechanism for people who know their passwords to change them.
• DO NOT make is easy for customer support to reset a password over the phone.
• DO NOT ship with default accounts and passwords. Instead, have an initialization procedure where default account passwords get set on install or the first time the application is run.
• DO NOT store plaintext passwords in your backend infrastructure.
• DO NOT store passwords in code.
• DO NOT log the failed password.
• DO NOT allow short passwords.
• CONSIDER using a storage algorithm like PBKDF2 that supports making the one way hash computationally expensive.
• CONSIDER multifactor authentication.
• CONSIDER strong 'zero-knowledge' password protocols that limit the attackers opportunity to perform brute force attacks.
• CONSIDER one time password protocols for access from untrustworthy systems.
• CONSIDER ensuring that passwords are strong progammatically.
• CONSIDER recommending strategies for coming up with strong passwords.
• CONSIDER providing automated ways of doing password resets, such as e-mailing a temporary password if a reset question is properly answered.

Sin 12: Failing to Store and Protect Data Securely

• DO think about the access controls your application explicitly places on objects, and the access controls objects inherit by default.
• DO realize that some data is so sensitive it should never be stored on a general purpose, production server. For example long lived X.509 private keys, which should be locked away in specific hardware designed to perform on signing.
• DO leverage the operating system capabilities to secure secret and sensitive data.
• DO use appropriate permissions, such as access control lists (ACLs) or Permissions if you must store sensitive data.
• DO remove the secret from memory once you have used it.
• DO scrub the memory before you free it.
• DO NOT create world writable objects in Linux, MacOS X, Unix.
• DO NOT create objects with Everyone (Full Control) or Everyone (Write) access control entries (ACEs).
• DO NOT store key material in a demilitarized zone (DMZ). Operations such as signing and encryption should be performed 'further back' than the DMZ.
• DO NOT embed secret data of any kind in your application. This includes passwords, keys and database connection strings.
• DO NOT embed secret data of any kind in sample applications, such as those found in documentation or SDKs.
• DO NOT create your own secret encryption algorithms.
• CONSIDER using encryption to store information that cannot be properly protected by an ACL, and signing to protect information from tampering.
• CONSIDER never storing secrets in the first place, can you get the secret from the user at run time instead?

Sin 13: Information Leakage

• DO define who should have access to what error and status information.
• DO use operating system defenses such as ACLs and Permissions.
• DO use cryptographic means to protect sensitive data.
• DO NOT disclose system status information to untrusted users.
• DO NOT provide high precision time stamps alongside encrypted data. If you need to provide them, remove precision and/or stick it in the encrypted payload (if possible).
• CONSIDER using other less commonly used operating system defenses such as file based encryption.
• CONSIDER cryptography implementations explicitly hardened against timing attacks.
• CONSIDER the Bell-LaPudula model, preferably through a preexisting mechanism.

Sin 14: Improper File Access

• DO be strict about what you will accept as a valid filename.
• DO NOT blindly accept a filename thinking it represents a valid file, especially on server platforms.
• CONSIDER storing temporary files in the users temporary directory, not in a shared location. This has an added benefit of making it easier to run your application in least privilege, because the user has full access to their private directory. However in many cases, only elevated accounts such as administrator and root can access system temporary directories.

Sin 15: Trusting Network Name Resolution

• DO use cryptography to establish the identity of your clients and servers. A cheap way to do this is through SSL.
• DO NOT trust DNS information, it isn't reliable.
• CONSIDER specifying IPSec for the systems your application has to run on.

Sin 16: Race Conditions

• DO write code that doesn't depend on side effects.
• DO be very careful when writing signal handlers.
• DO NOT modify global resources without locking.
• CONSIDER writing temporary files to a per user store instead of a world writable space.

Sin 17: Unauthenticated Key Exchange

• DO realize that key exchange alone is often secure. You must authenticate the other party or parties also.
• DO use off the shelf solutions for session establishment, such as SSL./TLS.
• DO ensure that you read all the fine print to make sure you have strongly authenticated every party.
• CONSIDER calling in a cryptographer if you insist on using custom solutions.

Sin 18: Cryptographically Strong Random Numbers

• DO use the system cryptographic pseudo random number generator (CRNGs) when at all possible.
• DO make sure that any other cryptographic generators are seeded with at least 64bits of entropy, preferably 128bits.
• DO NOT use a non-cryptographic pseudo random number generator (PRNG).
• CONSIDER using hardware random number generators (RNG) in high assurance situations.

Sin 19: Poor Usability

• DO understand your users security needs, and provide the appropriate information to help them get their jobs done.
• DO default to a secure configuration whenever possible.
• DO provide a simple and easy to understand message to allow for progressive disclosure if needed by more sophisticated administrators or users (IE, Firefox certificate browser for example).
• DO make security prompts actionable.
• DO NOT dump geek-speak in a big dialog box. No on will read it!
• DO NOT make it easy for users to shoot themselves in the foot. Hide options that can be dangerous.
• CONSIDER providing ways to relax policy selectively, but be explicit and clear about what the user is choosing to allow

Do you think fingerprint scanners or biometrics were "hacker-proof"??

 

Check this video from Adam and Jamie of Mythbusters... really astonishing!!

 

Today I was reading through a couple of IT security articles when I saw this one stating that HSBC bank is asking now customers to sign a letter of agreement that you have installed an antivirus and spyware program on your PC - only if you are not using IE as your browser.

It seems that users of Netsurf are being blocked from HSBC bank (see here) because this browser is a very easy target for spyware. Apparently letters from the bank were dropped on their doormats telling them they were banned from using their accounts. They were forced to turn up at their local branch with photo ID and sign a form promising to use Microsoft Windows XP with anti-virus software installed before they could access their money again.

In the letter, HSBC told Netsurf users: "An unauthorised person may have used your internet banking security number to log on to your Personal Internet banking. We believe that a PC that you use to log on to Internet banking may be infected with spyware. It is important that you do not use this computer until the problem has been identified and fixed. Some spyware programs can log your keystrokes, gathering personal data, then sending this to criminals."

In my opinion this is more like a countermeasure (a ridiculous one I must say) rather than a preventive one.

HSBC antifraud department should be starting to tackle the real issue rather than playing cat and mice.